金三銀四，銅五鐵六，今年快過去一半了，團隊的動盪也接近了尾聲，這半年的時間裡我面試了大資料方向上百位候選人（主要負責二面或三面），包括實習生、中級工程師、高階工程師、架構師，最大的感受是做大資料這一行的人真的是越來越多了，五六年前大資料招人還得從 Java 開發工程師裡面撈人，苦口婆心地勸候選人轉方向，現在一個崗位就有上百人號人競爭，我本以為這樣的大環境下候選人會準備地更充分，質量會更高，但是我還是花了半年時間，面試了上百人才撈到合適的候選人。
招人的標準這些年一直沒變，目標就是找到一個能幹活的人，那麼怎麼判斷候選人能否幹活，就大體上衍生出了以下這些維度：
- 程式碼能力
- 底層原理（技術深度）
- 問題定位（實踐能力）
- 系統優化（實踐能力）
- 架構設計（大局觀）
- 理解表達（溝通能力）
- 專案複雜度、參與度、業務理解（綜合能力）
根據不同的職級，會有不同的要求，比如實習生重點考察基礎，包括原理和程式碼能力等，對於專案或者系統設計方面要求可以降低；高階工程師在上述某一兩項上可以有些取捨，但是對於架構師來說則必須每一項都得達到80分以上。
程式碼能力是最最基礎的，畢竟招聘的是一個程式設計師，所以很多大廠面試二話不說先來幾道 leecode 把場子熱起來，力扣是最省事，最容易考察到候選人編碼能力的一種方式，所以建議想要進大廠的小夥伴有事沒事刷幾道力扣，保持一下狀態，不要等到真的要跳槽了才匆匆忙忙開始刷。
底層原理就是大傢俬底下常吐槽的“八股文”，比如：HBase 的讀寫流程、Spark 的記憶體管理機制、 Flink 的一致性原理 等等等等，吐槽歸吐槽，背還是得背的，邊理解邊背誦可以事半功倍。也可以關注一下我去年寫的專欄《詳解大資料面試核心知識》，可能是最全的大資料面試“八股文”了，有興趣可以去訂閱下。
問題定位和系統優化能力考察的是實踐能力，光會吹原理還不夠，還得會動手，比如線上 Spark 跑得慢了得知道怎麼去定位問題，怎麼分析日誌或者dump檔案，定位到問題之後還得知道怎麼去優化，得有一套自己總結的問題定位和解決優化方法論，防止人招進來之後遇到問題像無頭蒼蠅一樣。
系統設計能力考察的是候選人的大局觀，比如設計一個資料治理平臺，需要考慮這個平臺是解決哪些問題的，開發需要多少人力成本，如何管理功能的版本迭代，還有對於平臺本身的功能來說，如何管理後設資料，如何制定資料質量標準，如何定義指標，如何做前端展示，以及這個平臺可能對數倉 ETL 造成的影響等等，對於這些問題都要能夠把握住。
專案是重中之重，上面所說的所有的能力其實都是為專案服務的，如果在一個專案中，候選人從業務的調研、架構的設計，到技術的選型、核心程式碼的研發，再到後期線上問題的定位、系統的優化迭代等完整的流程都深度參與，且每個步驟都踏踏實實地完成，瞭解每一個細節，有自己的思考，並形成了一套自己的方法論，那麼這樣的候選人誰會拒絕呢？
上面所說的這些維度一輪問下來就造成了“半年面試上百人，通過者寥寥無幾”的場面。寫上面的內容不是想要吐槽什麼，而是希望能夠給需要面試的小夥伴一些啟發，少走一些彎路，更好地應對面試。
另外，這半年的面試經歷也遇到了不少讓人哭笑不得的事件，比如：
- 被候選人反問 ：“知道原理有什麼用？網上一堆答案我為什麼要硬背下來？”（因為你在面試啊）
- “這個問題我之前知道的，但是我忘了。”（。。。）
- “做大資料為什麼要問Java？”（。。。）
- 當我問到如何優化時，答到：“我做優化都是直接百度的，然後一個一個試的”（可不可以不要那麼誠實）
- 面試前和HR溝通要漲薪30%，面試後：“稍微有一些漲幅就可以了”。
- 候選人反問環節：“如果大資料方向在未來消失了，我們該怎麼辦”（小夥操心的東西還不少）
關於面試如果有其他疑問可以在後臺留言，關注公眾號：老懞大資料，歡迎持續關注後面的文章更新。