技術面試是一個工程師成長到一定階段後必然要承擔的一項工作，優秀的技術面試官能幫助公司篩選出優秀的工程師，並且潛移默化的吸引候選人選擇加入公司。相反，糟糕的面試不僅會錯失優秀候選人，甚至還會給公司招來大麻煩。儘管技術面試如此重要，我還是瞭解到，很多公司的技術面試官都是“無證上崗”，hr 隨便抓壯丁去面試，面試質量參差不齊。本文就這個問題，根據我自己的面試經驗和思考，總結了一些面試技巧分享跟大家，希望有所幫助。

如何閱讀候選人簡歷

閱讀候選人的簡歷，這是招聘流程中擺在我們面前的第一項工作。候選人的簡歷各式各樣，我曾經見過很多人的簡歷寫超過 10 頁，專案零零總總羅列幾十個，也有見過個人評價可以像散文一樣寫半頁紙的，工程師們一般都比較忙，如何快速的閱讀簡歷又不失重點呢？我總結了兩點：忽略掉主觀性太強的描述，比如簡歷中的自我評價，重複性的專案經歷，一些熟悉某某技術，精通某某語言的主觀性很強的描述，這些都可以一眼帶過。另一方面，抓住候選人的亮點，亮點就是那些非常有力的能證明候選人能力的經歷，我根據自己的經驗羅列了一些，供大家參考：

首先，對於候選人來講，大公司的工作經歷是很重要的能力背書，而且級別越高可以粗略等同認為越優秀，雖然也會有個例，但一般情況下，阿里 P8 要比 P7 技術能力優秀，百度的 T7 要比 T6 優秀，騰訊的 T3.1 要比 T2.3 優秀。但是這種情況只針對大公司，對於一些創業公司，小公司來講，Title 並不與能力劃等號，小公司技術總監的技術能力不如大公司的一個普通的資深工程師的情況也是常有的事情。

其次，有很好的教育背景，GPA 高也是很大的加分項，比如清北復交畢業，雖然都說做技術學歷不重要，但好學校的學生對計算機基礎知識／通識知識掌握的更好，計算機思維，邏輯思維更強，相對要聰明一些，而且在工作中發現成績好的同學往往在工作中表現出很高的執行力和快速交付能力 / 溝通能力，工作中的表現更優秀。

再次，有比較有技術含量的專案經歷。為什麼強調是“有技術含量”的專案經歷呢？因為我發現，有很多工作年限比較長的候選人，簡歷十幾頁，專案大大小小几十個，而很多專案都是 3，5 個月就做完，用到的技術也比較重複／淺顯，對於候選人的技術積累來說，10 年的經驗跟一年的經驗差不多，所以專案不在多，而在於能提現候選人的技術能力。

還有，有高質量的開源專案；專案背景比較切合；有在技術網站發表過文章或高質量的技術部落格；做過一些業餘專案等，都可以作為加分項。

如何設計面試題目

一般來講，大部分的面試流程都會先安排一輪電話面試，通過之後再安排現場面試。電話面試的主要作用就是簡歷擠水分篩選掉特別差的候選人，因為電話面試畢竟不便於溝通，對於一些複雜問題也沒有其他輔助方式來幫助理解和表達，所以面試題目最好不要過於開放，能夠有標準答案的最好，類似筆試，也以基礎知識或過往專案的簡單詢問為主。而現場面試一般比電話面試在溝通上更有優勢，在題目設計上可以更靈活。

一般來講，公司裡面是沒有面試題庫的，一般都是面試官自己想的，來源有很多，網上看到的，專案裡面涉及到的，自己被面試時遇到的問題等。拿來主義得到的面試題最好要修改一下，特別是網上常見的，以免候選人也看到過。

面試題目的設計一定要有同理心，簡單的講就是要學會換位思考，要站在候選人的角度去看待面試題目是否合適，是不是難度太大？題目背景是否容易解釋的清楚？是否能讓候選人對題目的理解跟面試官一致等等。這一點聽起來比較簡單，但做好比較難。張小龍說過最牛逼的產品經理要有能瞬間把自己變成小白使用者來認識自己設計的產品的能力。我們在設計面試題目的時候，也要學會放空自己，努力做到忘記答案，再去考量這個問題的難度。不過我們還有一個側面的方法瞭解面試題目設計的是否得當：先把題目講給周圍的同事聽，看看他們是否能很容易的理解，能夠答出來。

面試題目最好能層層遞進，先從簡單的問起，如果候選人能很好的回答，再繼續深挖，逐級遞進，當面試者無法繼續回答出來時，大體上就能知道面試者對此方面知識掌握的深度了。

舉一個我經常用的面試題: “有一個數組，陣列中儲存的是 Cat 物件，每個 Cat 物件有多個成員變數，其中一個代表顏色 color，有兩個值白色和黑色，要求編寫一個函式將陣列中所有的白貓都放到黑貓前面。”

如果候選人能夠順利解答，我會繼續加大難度：“如果貓的顏色有三種，白色、黑色、灰色，編寫一個函式將陣列中白貓放到最前面，灰貓放到中間，黑貓放到最後面，比如：原來陣列為 黑白灰白白黑灰灰，經過排序之後白白白灰灰黑黑”。

還可以繼續加大難度：“不僅白灰黑之間按順序排列，而且白貓，灰貓，黑貓各自內部原來的先後順序也不能變。” 雖然解題思路差不多，但顯然需要處理的細節變多了，難度比之前兩個都要大了。

這樣一層一層遞進，難度逐漸加大, 這樣的面試題一方面有區分度，另一方面不至於太難導致候選人完全答不上來。

少問記憶性問題和太理論性問題

有些 JAVA 面試官逢人便問 JVM 幾種垃圾回收演算法優劣對比，這種文科題目在我看來是沒有太大意義的，一方面沒有區分度，另一方便容易突擊準備，往往考察不出候選人的真實能力，所以我面試有個原則，不直接問記憶性問題，也不直接問理論性問題，比如 Spring AOP，IOC 的實現原理，Spring Transaction 有哪幾種事務傳播方法，分散式一致性的解決方法有哪些啊？JVM 垃圾回收演算法？Zookeeper 的應用場景有哪些啊？

並不是說這些技術不重要不需要考察，而是換個問法，將這些記憶性的、理論性的知識融入實踐，比如考察剛剛提到的 Spring 中的 AOP, IOC 原理概念，我一般會這樣子設計面試題目: 給一些包含 Spring 功能特性的程式碼片段，讓候選人闡述一下從應用啟動到程式碼執行都經過了哪些主要的操作？當然還會告訴候選人主要考察 spring 的 AOP/IOC 特性，並且提示候選人越詳細越好，以免候選人不能理解面試官的意圖，答非所問。這樣的問法讓候選人言之有物，而且避免機械記憶性的背誦，更能測試出候選人是否真正的理解。

再比如，有些面試官為了考察候選人多執行緒方面的知識，經常會問到的題目比如 ConcurrentHashMap 的實現原理，volatile 關鍵詞的作用等，我之前也多次拿這些題目當做過面試題，但總結下來發現，大部分候選人都能答得七七八八，區分度很低。我之後換了一種問法，要求候選人將一個執行緒不安全的類改寫成執行緒安全的類，這期間涉及到 volatile,lock, 併發容器，Atomic 原子操作，CAS 無鎖程式設計等，發現只有極少部分候選人給出鎖粒度小，併發度高的程式碼，部分候選人在提示下可以解決，一些候選人則僅能寫出一把 synchorinzed 大鎖的併發度很低的程式碼。事實很明顯，那些能夠給出優秀答案的候選人，必定是有著實踐經驗，並且深入思考過，真正理解的人，而相反，其他人可能只是臨時看了幾篇技術部落格而已。

白板程式設計真的有必要嗎

白板程式設計就是在面試現場讓候選人在白板上寫一段程式碼，當然白板只是一個代指說法，也可能是白紙上，也有可能是 Google Doc 共享文件裡。白板程式設計外企面試比較流行，國內有些候選人不怎麼接受，特別是工作年限較長的，一說要寫個程式碼，求職者就覺得是在“羞辱”他，覺得不應該從這麼基礎的問起。不過根據我的面試經驗發現，這種拒絕寫程式碼的大齡碼農，滿嘴架構，高可用，高效能，分散式，往往一寫程式碼就抓瞎，程式碼寫的慘不忍睹。所以只要是面試一線技術研發崗位，不管是資深工程師，架構師，還是開發 leader，我都會要求候選人現場至少寫一段程式碼。

哪種型別的題目適合白板程式設計呢？舉一個我之前經常用的例子：

“寫一個函式將 ipv4 地址字串 (僅包含數字，點，空格) 轉化成 32 位整數，另外，數字和點之間的空格是合法的，其他情況均為非法地址，要求輸出合法地址的 32 位整型結果。”

這個題目不需要任何的演算法背景和技巧，純粹考察候選人的基本程式設計素質：邏輯思維是否清晰，細節是否考慮全面，是否能寫出 bug free 的程式碼，是否有計算機思維能關注時間空間複雜度等。而且在候選人完成程式碼之後，我還會要求候選人將程式碼講給我聽，當然不是因為我看不懂，而是這樣還能順帶考察候選人的表達能力，溝通能力，畢竟講給別人聽讓別人理解要比單純自己理解難很多。

除此之外，我個人也不建議程式設計題目涉及需要記憶的演算法，比如被很多人詬病的面試題：寫個快排，沒有人會天天背誦快排演算法，寫不出來也理所應當，如果換個問法，比如給候選人講一下快排的思想，然後讓候選人程式碼實現，測試候選人是否能寫出 bug free 的程式碼，我覺得這反倒是一個比較好的程式設計題目。

還有，我也不建議面試需要特殊解題方法或技巧的程式設計題目，比如需要用到動態規劃，線段樹，Trie 樹等高階一點的解題思路，畢竟大家工作中不常用到。

智力問題為什麼會收到青睞

我們經常在網上看到說谷歌，微軟等大外企經常會面試智力題目，面試智力問題到底有沒有意義呢？答案是肯定的，我認為智力問題不在於候選人最終是否能提出標準答案，而在於提供一個話題跟面試者討論，考察候選人是否是一個有想法的人，是否跟面試官在一個思維層次上，溝通流暢；更重要的是考察候選人思路是否清晰，邏輯推理能力是否夠強，資訊挖掘能力是否強，總結能力是否夠強等等基本素質。

舉一個我之前曾經用的面試題目，也是我面試谷歌時被問到的一個問題：新建了一棟 100 層的辦公樓，設計一個電梯排程系統，能讓大家上下樓都節省時間，這個問題沒有標準答案，你會發現不同的候選人回答相差很大，優秀的候選人會不停的挖掘背景資訊，定義清晰需求，理清楚思路，通過一步一步嚴密的邏輯推理計算，合理的假設，讓問題變得清晰可解，而有些候選人則無從下手。

我個人認為智力問題最好是比較開放性的問題，一定不要太難的問題，也不要是抖機靈的問題。有很多面試官拿數學難題考候選人，希望 45 分鐘答出來標準答案，這本身就是不可能，除非之前候選人已經看過，這樣的問題也就沒有意義了。比如網上比較流行的“扔雞蛋測樓高的問題”“沙漠如何背最多水問題”。

當然，智力問題也並不是適合所有的公司。一般成熟型的大公司，對候選人可以接受比較長的培養時間，而且預設聰明的人學習能力都很強，所以對過往技術經驗並非特別的看中，所以一般喜歡面試演算法，智力問題。對於一些創業型公司，更看重候選人的工作經驗，青睞技術多面手，來了就能產出，所以就不適合在智力問題上浪費太多的面試時間。

把面試當做一場技術討論

篩選候選人就是篩選將來與你共事的人，所以為了更準確的反應候選人在以後的工作中的表現，不妨把面試當做一場與未來同事的技術討論，在討論的過程中感受候選人的技術能力。

技術面試就好比打乒乓球，一來一往中感受彼此的技術實力，面試的過程切忌類似與筆試一樣的一問一答單向溝通。特別是一些開放性問題，架構設計的問題，本身就沒有標準答案，背景又過於複雜開放，如果只是丟給候選人回答，中間沒有任何溝通交流和引導，候選人是很難抓住重點展現出面試官心裡期望的表現。

比如我們面試過程中經常會讓候選人介紹某個專案的架構設計，當候選人講解完專案的架構設計，如果面試官一個問題都不提然後就跳到其他問題，這種體驗對不管是候選人來說還是面試官來說都不是很好的。而相反，如果面試官能一語中的的提出設計中的缺陷，或者追問架構中的技術難點，深入的跟候選人討論，這樣一方面能給候選人充分發揮的機會，另一方面，也會贏來候選人對公司技術的認可。

最後，總結

相信很多工程師隨著面試經驗的積累，即便沒有經過培訓，面試工作也可以做的非常好，因為畢竟優秀的工程師都邏輯清晰思維敏銳，也希望本文能給大家在成長的過程提供一點幫助。

作者介紹

王爭，前 Google 工程師，現某互金獨角獸公司資深系統架構師，核心業務介面平臺負責人，畢業於西安交通大學計算機本碩連讀專業，關注高效能高可用系統架構，對微服務、分散式系統開發有比較多的專案經驗和研究。