前言 (贊完再看養成習慣)
每逢金九銀十 , 像作者這樣的IT碼農, 會按奈住內心對 996 和 產品經理 的一萬種髒話, 偷偷將手中的簡歷更新, 投往互聯網各公司的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 的致命缺點
- 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。
關注 20K+ 訂閱號即可助力月入 20K+ , 相關文章.
