前言
每逢金九銀十 , 像作者這樣的IT碼農, 會按捺住內心對 996 和 SB產品經理 的一萬種髒話, 偷偷將手中的簡歷更新, 投往互聯網各公司的HR手中 , 這時IT論壇裏也熱鬧起來了, 各種大廠內推和求內推的帖子被頂的火熱. 有些幸運的 碼農拿到了些大廠的 面試邀請, 想着大廠入職後誘人的福利, 翻倍的薪資, 不少年輕的碼農不知不覺流下了口水, 興奮的徹夜難眠…
講個事, 我有個哥們叫張大胖也是 Java碼農, 上個月去某大廠面完試 , 去之前神采奕奕 的和我說 “這個崗位的最低薪資就是他現在薪水的兩倍 , 笑着說: 等着哥們到時候進某廠了, 給你內推, 一起寫Bug.” 這個星期五 張大胖喊我下班來他家喫羊肉火鍋, 一上桌看着大胖整個人垂頭喪氣的, 臉上寫滿了惆悵, 我趕緊給他把酒滿上, 招呼他喫菜, 酒過三巡, 我問張大胖 “上個月面的咋樣啊 ?” 他這時面露說道: “我TM就面箇中級工程師,去了先讓我做一堆看不懂的算法題, 然後來一個禿頭老大哥來面我, 據說都工作十多年了, 沒等我把項目邏輯講完就拿着簡歷追問我技術棧底層實現, 用了什麼設計思想 balabala, 我硬撐着把肚子裏的那點貨倒騰出來, 又被連環追問,感覺人都傻了, 哥們最近真倒黴能力被碾壓了!” 我說: “你在簡歷中專業技能欄裏寫的啥?” 大胖用手機把他的簡歷發給我了, 專業技能欄足足寫了 10行, 前面都寫着精通. 我說 "這麼多技術你都懂原理嗎? " 張大胖擺了擺手, “都是項目裏用過的,用完早就忘了, 嘆了口氣又說 我啥時候才能和你一樣吊打面試官, 薪資翻倍啊!” 我喝了口酒笑着說 “我也就比你多做了點功課,來大胖我幫你分析分析!”
看看張大胖的技術棧.
- 精通Java基礎知識以及設計模式 , 熟練應用阿里官方Java代碼規範標準編寫優質Java代碼。
- 精通微信小程序項目, 以及微信公衆號等相關微信生態開發集成。
- 精通JavaScript編程、Vue.js框架以及WebPack等前端技術,掌握iView, Vue-Route, TypeScript,ECharts。
- 深入研究Spring相關源碼, 業餘擁抱開源社區貢獻代碼, 並長期保持刷LeetCode的習慣。
- 精通Elastic Stack (ELK) 大數據生態 中的Elasticsearch, Logstash, Kibana, Filebeat進行數據挖掘。
- 精通SpringBoot, Spring, Mybatis, Hibernate, OSGI等框架的核心思想及開發JavaEE項目流程。
- 精通Oracle , MySQL的數據庫的設計維護。非關係型的數據庫中，對於Neo4j的使用較爲熟練。
- 精通Dubbo RPC遠程通信技術, Kafka消息隊列, Guava本地緩存, 瞭解SpringCloud微服務等。
- 精通爬蟲技術(HttpClient Jsoup), 瞭解反爬與反反爬技術。
- 精通Intellij IDEA , VS Code開發工具，熟悉Git/SVN 版本控制工具, Maven依賴管理工具。
大胖被面試官KO的真相
我曾經也是作爲過面試官,親歷過從約面試到發Offer的全過程, 負責任的講, 公司給你發麪試邀請的這個環節, 其實是因爲你的簡歷得到了HR 你未來上司的初步認同, 認爲你的簡歷技能與當前職位匹配, 面試這個環節本質則是考察面試者與職位匹配度的高低, 基本的框架 CRUD 搬磚問題誰都會回答, 怎麼能考察出面試者的真實水平, 從而優中選優呢?
大廠考察研發工程師都需要寫算法題, 考察面試者的基礎編程能力.
關於你的項目是什麼個業務邏輯, 面試官一點都不關心, 面試官關注的是你對技術的追求, 是否深入瞭解項目中的技術原理, 是否有自學能力.
不要順着面試官的意思來, 在自己深入的技術上, 要主動講源碼, 講思想, 挑逗面試官的好奇心, 從而抱得Offer歸.
一切的一切, 都說明一個問題, 面試前一定要做好秀面試官一臉的功課, 讓他抓着你的手求你明天來上班 , 而不是最後被面試官吊一頓,回家等通知, 面試的過程, 要變被動爲主動, 是你選擇Offer而不是Offer選擇你.
如何幫助張大胖反秀面試官一臉
日常刷LeetCode, 如果想進大廠, 算法與數據結構不能丟.
必須將寫在簡歷上的技術棧底層搞懂個七七八八,能住唬人.
儘量聊面試官感興趣的話題, 將自身經歷與職位要求上靠, 提高匹配度,
將面試時被問到回答的不滿意的問題,記錄成下面的問答式面試題集.
日常必須閱讀源碼, 比如 Spring IOC 理解等 (面試必問) , 面試問到 IOC, 就是你反殺面試官的開始 , 23333.
講講張大胖被問倒的面試底層面試題集
1.ES的倒排索引的底層?
ElasticSearch引擎把文檔數據寫入到倒排索引（Inverted Index）的數據結構中，倒排索引建立的是分詞（Term）和文檔（Document）之間的映射關係，在倒排索引中，數據是面向詞（Term）而不是面向文檔的。
一個倒排索引由文檔中所有不重複詞的列表構成，對於其中每個詞，有一個包含它的文檔列表
示例：
對以下三個文檔去除停用詞後構造倒排索引
倒排索引-查詢過程
查詢包含“搜索引擎”的文檔
通過倒排索引獲得“搜索引擎”對應的文檔id列表，有1，3
通過正排索引查詢1和3的完整內容
返回最終結果
倒排索引-組成單詞詞典（Term Dictionary）
倒排列表（Posting List）
單詞詞典（Term Dictionary）
單詞詞典的實現一般用B 樹，B 樹構造的可視化過程網址:B Tree Visualization
倒排列表（Posting List）
倒排列表記錄了單詞對應的文檔集合，有倒排索引項（Posting）組成
倒排索引項主要包含如下信息：
1.文檔id用於獲取原始信息
2.單詞頻率（TF，Term Frequency），記錄該單詞在該文檔中出現的次數，用於後續相關性算分
3.位置（Posting），記錄單詞在文檔中的分詞位置（多個），用於做詞語搜索（Phrase Query）
4.偏移（Offset），記錄單詞在文檔的開始和結束位置，用於高亮顯示
B 樹內部結點存索引，葉子結點存數據，這裏的 單詞詞典就是B 樹索引，倒排列表就是數據，整合在一起後如下所示
ES存儲的是一個JSON格式的文檔，其中包含多個字段，每個字段會有自己的倒排索引
倒排索引的結構
包含這個關鍵詞的document list
包含這個關鍵詞的所有document的數量：IDF（inverse document frequency）
這個關鍵詞在每個document中出現的次數：TF（term frequency）
這個關鍵詞在這個document中的次序
每個document的長度：length norm
包含這個關鍵詞的所有document的平均長度倒排索引不可變的好處
- 不需要鎖，提升併發能力，避免鎖的問題
- 數據不變，一直保存在OS Cache中，只要Cache內存足夠
- filter cache一直駐留在內存，因爲數據不變
- 可以壓縮，節省CPU和Io開銷
2.Dubbo和SpringCloud的區別, Dubbo 有什麼致命缺點 ?
通訊協議上的區分
Dubbo由於是二進制的傳輸，佔用帶寬會更少.
SpringCloud是http協議傳輸，帶寬會比較多，同時使用http協議一般會使用JSON報文，消耗會更大.
註冊中心上的區分
SpringCloud的接口協議約定比較自由且鬆散，需要有強有力的行政措施來限制接口無序升級.
Dubbo的註冊中心可以選擇ZK,Redis等多種，springcloud的註冊中心只能用Eureka或者自研.
Dubbo 的致命缺點
Dubbo的開發難度較大，原因是Dubbo的jar包依賴問題很多大型工程無法解決.
Dubbo 僅僅是微服務的一種框架,不是一套技術棧.
SpringCould-JHipster 微服務架構
Dubbo 微服務架構
3.Kafaka隊列底層原理
Kafka 是一個高吞吐量,分佈式的發佈-訂閱消息系統;
- 生產者
Producer將消息發佈到它指定的topic中,並負責決定發佈到哪個分區。通常簡單的由負載均衡機制隨機選擇分區，但也可以通過特定的分區函數選擇分區。使用的更多的是第二種。
- 消費者
發佈消息通常有兩種模式：隊列模式（queuing）和發佈-訂閱模式(publish-subscribe)。隊列模式中，consumers可以同時從服務端讀取消息，每個消息只被其中一個consumer讀到；發佈-訂閱模式中消息被廣播到所有的consumer中。Consumers可以加入一個consumer 組，共同競爭一個topic，topic中的消息將被分發到組中的一個成員中。同一組中的consumer可以在不同的程序中，也可以在不同的機器上。如果所有的consumer都在一個組中，這就成爲了傳統的隊列模式，在各consumer中實現負載均衡。如果所有的consumer都不在不同的組中，這就成爲了發佈-訂閱模式，所有的消息都被分發到所有的consumer中。更常見的是，每個topic都有若干數量的consumer組，每個組都是一個邏輯上的“訂閱者”，爲了容錯和更好的穩定性，每個組由若干consumer組成。這其實就是一個發佈-訂閱模式，只不過訂閱者是個組而不是單個consumer。
**微信掃描二維碼，關注我的公衆號
**
專注分享Java乾貨, 提高編碼實力 , 助力讀者月入20K , 點擊在看即可幫助更多人.