怎麼面試（社招）程式設計師？

最近雅虎北研解散的訊息觸動了各大網際網路公司 HR 的神經。公司裡一下子面試的任務多了起來。正好藉機會總結一下自己畢業後作面試官以來參與若干場技術面試的一點心得，分享一下。

當好一個面試官其實也很不容易，不但要練就一雙火眼金睛，把優秀的人才和水貨在短短的面試的幾十分鐘裡分辨出來，同時面試官本身就是候選人觀察公司的一個視窗。在面試中，面試官還要注意很多接人待物的細節，既能彰顯公司求賢若渴、對人才的尊重，又能將公司的技術水平和文化氛圍展露一二，以求給候選人留下良好的印象。

社招某種意義上比校園招聘更困難。面對形形色色的社招候選人，首先一個要想清楚的問題就是我們到底該招什麼樣的人？簡單的說就一句話，適合自己公司的人。每個公司都有獨特的文化和特定的業務需求，更有各自的業務發展階段。就算同樣是招程式設計師，也應該因地制宜，有所側重。拿我現在所在的公司（某大型外企駐華研發機構）、所在的行業（瞬息萬變的網際網路）來說，我覺得最重要的就是下面幾點：

第一，聰明。作為大公司，尤其是外企，總部的制約總是一定程度的存在，網際網路行業更是一個日新月異的行業。這時，專案背景和知識遠沒有能力靠譜。如果一個人的工作業績，是來自無數歲月一脈相承而延續下來的知識體系，是積累到某種程度的知識土壤上很自然的發芽、開花、結果，那麼在這種充滿未知、充滿變化的行業和工作中，一旦專案發生較大變化，那麼你在適應新任務、新角色、新挑戰時就會出現很大的落差甚至困難，最後的結果通常是工作效率顯著下降，嚴重的甚至只能一拍兩散。公司花這麼大的力氣招聘和培養人才，如果僅僅因為專案變化就發生大規模的離職，想來從公司角度是非常不划算的。所以，在我參與的面試中，我最提倡招聰明人，要招比自己聰明的人，招能適應各種新技術、新行業、接受新挑戰的人，招和自己不一樣的人。當然，這也是由公司的特點決定的。我們公司的特點是組織機構調整、專案變化頻繁，公司規模很大、業務範圍很寬，對正式員工相對較負責，內部培訓較完善，裁人比較慎重，發生各種變化時內部換崗機會多。其他公司未必可以參考，但可以結合自己的需求和特點對號入座。

為了測試一個人的聰明程度，我通常會給他一道演算法類的題目，讓候選人嘗試給出一個經過優化的解。選題時，我通常會選擇那些不同思路、不同水平的解非常多的題目。我一般並不指望候選人一下子把最優解做出來（實際上也有個別能做到的特別優秀的候選人，但同時也要小心他以前做過類似的題）。我會通過交流去嘗試理解他的優化思路，然後適時的沿著他的思路給點提示，看看他能不能有什麼進展。在交流中，我主要觀察一個人的邏輯思維的嚴密性、考慮問題是否全面，思考是否迅捷，能不能突破既有思路的框框。我還要觀察候選人能否在解題過程中很好的理解問題，對問題能否進行系統性的有條理的分析。俗話說文無第一、武無第二，其實任何最優解都有一些充分限定的條件或假設作為前提，除非用數學公式的風格嚴謹的出題，常規意義的完美解是很少存在的。一個人，如果能突破常規，能對問題有很好的分析，取得一定進展，我覺得在有限的時間和麵試的壓力下，能做到這些已經難能可貴了，面試官也並不一定有必要盲目的追求最優解。

在這裡，也要順道提醒參加面試的候選人。解題時，要留意麵試官的問題和提示（如果有的話）。我記得見過一些候選人在面試中完全封閉在自己的世界裡，從面試官的角度來說，他們完全沒有任何進展的憋在那裡，甚至在面試官主動幫助他的時候也沒有取得任何有意義的反饋。縱使候選人天賦異稟、聰明絕頂，但如果在面試中與面試官都無法順利協作，那麼實際工作中又會如何呢？面試官既然花費時間參加面試，從內心深處都是非常希望找到合適候選人的，面試官也希望被面試的你通過面試。所以，從心態上不要簡單的把面試當作一個非黑即白、相互對立的考試。從某種意義上說，我更不僅僅是一次考試，他更像相親，呵呵。

第二，技術深度。作為軟體工程師，畢竟還是一個技術性崗位。不管你有多聰明，如果你的個性和主觀意願上決定了，你並沒有在技術上鑽研到一定深度的意願或能力，那麼公司派你衝鋒陷陣的時候就要考慮一下了。畢竟就算對你來說是新領域，從網際網路公司的需求來說，公司通常要你在最短的時間幫助他們提高產品技術水平，以便有機會能在殘酷的市場上取得有利的競爭地位。並非公司沒有耐心等你慢慢成長，而是外部環境、那些虎視眈眈的競爭者不允許。如果你個人沒有追求卓越的習慣，不能在有限時間將你學習和掌握的技術鑽研到足夠的深度，那麼公司將無法在殘酷的市場競爭中生存，公司僱傭你、留住你的意義又何在？所以，我覺得公司需要的人才是這樣的，他們有追求卓越的意願，有獨立探索、不斷學習和自我進步的能力，他們哪怕從事的是全新的領域，只要給他一點合理的適應和探索的時間，他都可以做的比很多人、比其他公司更好。

在技術深度的面試中，我通常會通過候選人以前做的專案、讀過的書或者熟悉的程式語言，圍繞著這些話題來出題。面試官當然不可能什麼都懂得很深，所以面試題也不需要過於刁鑽、古怪。拿以專案背景為主的話題為例，可以通過不斷深入的去了解對方的角色和職責，看看他對專案中的各種技術、架構和具體實現是否熟悉。如果發現系統設計上的瑕疵或挑戰，還可以更深入的探討，看看候選人的反應。有些候選人號稱是核心開發人員或者專案主管，但實際上問他很多細節問題根本回答不出來，這種候選人或許浮在上面做管理工作太多、技術上不是特別擅長，要麼就是簡歷中水分太大並沒有多少真金白銀。談談熟悉的程式語言或技術書籍也是不錯的選擇，但要注意別考很偏的問題，因為那是在考知識，不是考能力。知識對於聰明人來說是可以學習的，面試中要側重對知識的運用。很多技術涉獵不深的程式設計師，常常是知其然不知其所以然，更談不上活學活用。當然實際上知其然恐怕有不少候選人都做不到，這類人特別是工作年限很長的就算了，說明他缺少對技術的理解還是很淺，難以承擔重任。很遺憾在這裡不能通過面試題舉例一二，以後方便的時候再跟大家交流吧。

第三，技術溝通能力。排除個性和常規的溝通技巧等因素，很好的技術溝通能力實際上在日常工作中非常重要。我們需要優秀的工程師不但能孤軍奮戰，也能團隊協作。這就要求大家能抓住問題要旨，在交流和對話中完全沒有溝通障礙的可以並肩戰鬥的夥伴。而良好的技術溝通能力，實際上需要很多素質，包括即時反應能力、很強的技術理解力、系統性的思考和分析能力、總結和概括能力以及具象化的展示和表達能力，實際上當真是很難得的。在面試中要格外關注候選人在交流中所表現出來的種種行為特徵和模式，比如木訥、囉嗦、跑題、搶話、傲慢等等。對有比較嚴重的溝通缺陷的候選人，縱使其它各項面試表現良好，也要格外慎重，否則極有可能會拖累團隊的效率。

第四，程式碼。歸根到底，程式設計師特別是基層是用程式碼說話的職業。我很難想象一個事業上成功的優秀的程式設計師，居然不能再面試中寫出清晰、嚴謹、高效的程式碼。我個人是建議演算法題和程式碼題分開，最好混在一起。我的程式碼題一般重點考察兩點：候選人的程式碼風格如何，包括函式和變數的命名，包括程式邏輯是否存在大量的冗餘，包括一些個人的程式設計習慣如何；此外，還會考察候選人的程式邏輯上是否嚴密，對輸入有無斷言或正確性驗證，對各種邏輯上的邊界條件能否正確處理，特別是寫好程式後有沒有自我測試的過程，通過合適的測試用例驗證程式的正確性。即便對於那些面向基層管理職位和架構師職位的人我也是一視同仁的，在我看來沒能力用程式碼說話的技術人員，是很難做好基層的專案管理、研發管理等職位的，除個別妖孽外我也很難想象一個沒能力寫好程式碼的人能做好架構層面的設計。歸根到底，這一切都是相通的，是程式設計師的基本功，說的或許不貼切，但至少我沒見過初等數學一團糟但微積分非常出色的人。

第五，品味和興趣。通常我開始瞭解一個候選人的技術品味的時候，他已經通過了面試，而且我對他的面試成績一定是非常滿意的。在這個層面，我會問問他最近在業餘時間讀了什麼技術書籍，探索了什麼有趣的新技術，或者經常去什麼網站學習。一方面，一個人的技術水平的提高除了來自工作時間公司專案裡身邊的這些同事，也來自他業餘時間自己的個人涉獵，這時候他的興趣和品味會為他選擇最適合他的渠道。如果一個候選人足夠優秀，我常常會問他這方面的問題，一方面我可以藉機學習，多多參考他公司之外的學習之道；另一方面，也可以更全面掌握他的知識結構和興趣愛好，看看有沒有給面試加分的或者適配於工作需要的地方。

好了，今天先分享到這。有什麼不當和疏漏在所難免，歡迎業界朋友多多指教！