我的上一份工作是在一家世界500強金融集團擔任架構師，當時，公司的IT團隊規模將近2000人。與其他IT公司一樣，程序員的流動性也比較高，而作為架構師，我需要為所在的部門招聘各個層級的開發人員，當然也包括外包。在這長達5年時間里，我面試了大約400名程序員。我并沒有參加過任何人力資源方面的培訓，也沒有正式研究過如何面試程序員，但是我通過對大量程序員的面試，以及錄用后效果的觀察，得出了一套自己的面試策略，去找到那些真正靠譜的程序員。

　　1. 簡歷看人

　　閱讀簡歷永遠是面試的第一步。好的簡歷一定是正確、清晰并且能夠體現候選人最有價值一面的。我首先會過濾掉那些包含錯別字，文句不通或沒有邏輯性的簡歷，因為如果一個程序員連自己的簡歷都不愿意去仔細檢查并完善的話，很難想象他寫出來的代碼質量會如何。接著，我便會重點閱讀簡歷中的項目經驗部分，在這里我能夠看到面試者的開發經驗，技能棧，并且判斷他們熟悉的技術框架、工具是否與目前公司要求相匹配。

　　這里，我還會特別關注面試者是如何來寫這部分項目經驗的，你需要用盡可能簡練的文字來描述項目的背景，你在項目中承擔的角色、參與項目的時長，你用到的技術、以及你在項目中的亮點等信息。優秀的程序員們往往有一個共同的特質，那就是善于歸納，并能夠一針見血的發現問題或把一個問題說清楚。我經常看到面試者在簡歷中像寫故事一般地描述他們的項目經歷，光這一個章節就有好幾頁，其實這反而會給你減分，因為這會讓面試官判斷你缺乏必要的歸納能力。

　　最后你的一些與編程有關的社會化活動，如：你在GitHub上的開源項目，在知乎、V2EX中給他人的解答以及你的個人技術博客等等都會給你加分，因為這說明你對所從事的工作有著極大的熱情，并愿意在業余時間去學習和提高自己，就像在我之前的 “給職場新人的10點職業建議” 一文中提到的，如果你要成為一個領域的專家，那你必須花費超過1萬小時，而這光靠工作時間是遠遠不夠的。

　　2. 給面試者10分鐘介紹自己最擅長的

　　當面試者通過了筆試和HR面試之后，你就需要面對面地對候選人進行面試。我遠不是什么面試專家，但我有一些自己的獨特方法。我討厭問一些很個人的問題，比如你的職業規劃是什么？你為什么想換工作？等等。我更愿意給面試者10分鐘時間，讓他介紹自己最擅長和最感興趣的領域。這往往能幫助我很快作出下面的判斷：

• 這個人對他所做的事情是否充滿激情
• 他們是否能在團隊中很有效地進行溝通
• 他們是否在專業領域足夠擅長
• 你的團隊是否會樂于和這個人一起工作

　　這一招我在面試中用得很多，而實踐證明也確實非常有效。

　　3. 基礎打牢了嗎？

　　一般，有一定規模的公司都會為面試者安排機考或筆試，從而能首先篩掉一批未能通過的面試者。另一些規模較小的或初創公司則會讓面試官直接進行技術面試。其實，我覺得這兩者的差別不大，有經驗的面試官往往能夠通過幾個最簡單的技術問題，判斷出面試者的技術基礎是否牢固，這不是為了證明他有多優秀，而是用來判斷他是否是一名合格的程序員。對于我來說，并不看重機考的成績，因為機試的考題很多能夠在網上得到，特別對于一些外包公司，他們總是能夠通過各種途徑得到考題，從而使得他們推送的外包能夠順利通過筆試。

　　下面是我經常會問的幾個問題（JAVA）:

1. HashTable與HashMap有什么區別？
2. Servlet是線程安全的嗎？
3. JSP中@include跟jsp:include的區別
4. HTTP的response code 403和500分別代表什么
   ......

　　這些問題都很簡單，但一些基礎不牢的程序員往往會在這個時候露餡。當然，根據面試崗位的不同，你還可以有針對性地問一些問題，例如，你需要找一個能寫核心算法的程序員（比如，銀行的總賬計算，或者保險公司的保費計算），那么你可以問一些算法相關的問題。

　　4. 技術深度夠嗎?

　　具備牢固的技術基礎，一般就可以滿足項目中普通程序員的要求了，但如果你需要找的是一個資深程序員，那么你還需要對面試者的技術深度進行考察。我們現在做項目時都會大量使用框架，這能使我們的開發效率和質量都得到提升和保障，但同時也降低了對于程序員開發技能的要求。因此我一般會詢問面試者下面的問題，來考察他對所使用框架的掌握程度。

請你描述一下，在這個項目中，從一個HTTP請求發起，到最終的Response返回，它在你的系統和框架內部是如何流轉的？

　　這個問題往往能夠判斷出面試者對于相關技術掌握的深度。較初級的開發人員描述的層級往往比較淺，比如使用Spring MVC框架的，只能說到實現一個Controller繼承BaseCommandController（甚至很多開發人員只知道繼承了一個公司內部框架的基類），至于再往下Spring框架是如何進行內部流轉的，就再也說不清楚了。而更資深的開發人員，往往能說出框架內部的實現機制，以及如何調用和處理的。在面試者描述的過程中，你還可以穿插詢問一些比較有深度的問題，比如框架中某個類這樣設計是哪一種設計模式的體現，采用這樣的設計有什么好處等等。這比讓面試者默寫一個設計模式代碼要有效、自然得多。

　　除了技術層面上的考察之外，對于資深開發人員，還需要考察他們的設計能力。說到軟件設計，大部分面試者都能熟練地背出面向對象的三個基本特性：繼承、封裝、多態，也能把它們的概念描述清楚。但我一般會問下面的這個問題來考察他們的面向對象設計能力。

請用一段程序代碼描述我們所在的這間房間。

　　我驚訝地發現至少有一半的面試者都很難準確使用Interface和Class來給房間建模，也有一些人會將最基本的代碼語法或關鍵字寫錯。

　　5. 選擇適合所在企業文化的人

　　這一點也曾是我經歷的一個誤區，我總是希望能為團隊招到技術能力最強的人，而忽略了他是否與整個公司和團隊的文化相匹配。這往往會造成，雖然招到了人，但沒過多久就因為理念不同不歡而散的結果，反而給公司帶來了損失。讓我們看看GitHub的負責人是怎么說的。

我們很嚴肅地看待我們自己關于招聘流程的哲學。我們希望每一個GitHub員工都了解他們所要面對的環境，并保證他們是能夠很好適應的。這包括我們所創造的文化、哲學、計劃、錯誤甚至是晚餐。比起他們的技能是否滿足要求，我們更看重他們的潛力以及是否能夠適應我們的企業文化。

　　我曾在具有鮮明文化差異的不同公司或團隊工作，看到許多崇尚開放、開源的程序員在一個相對封閉，具有很多流程以及規范限制的公司中很難發揮，最終選擇離開。因此在招聘程序員時，選擇合適的往往比選擇最優秀的更重要。

　　6. 行為面試法

　　行為面試法可能是我在整個面試過程中唯一用到的教科書面試方法。一個程序員是否能夠很好地工作，不僅取決于他能否順利地完成開發任務，更重要的是在遇到一些特殊場景或問題時，他能否合理有效地處理和解決。行為面試法能夠幫助我們從面試者描述的過去某一具體事件中，預測未來他在工作中可能的表現。下面便是一個我經常用到的問題。

請談談你在這個項目中遇到的最大困難或挑戰是什么，你是如何解決的。

　　從面試者對上面這個問題的回答中，我能夠很好地判斷他是否有較強的獨立解決問題的能力，而我認為這是除技術能力之外，程序員最應具備的能力。

　　7. 給他們一個虛擬任務

　　經過上面的這些環節，你可能對面試者的整體情況已經比較滿意，但先別急著下結論。我曾見過能夠順利通過上面所有面試步驟，并且被雇傭的程序員，當他們進入實際工作后卻沒能把事情做好。

　　在你確定是否錄用他們之前，可以給他們一個虛擬任務。我不是說一個抽象的程序問題，而是指一個真實的，可能就存在于你當前項目中，并且需要在一兩個小時之內完成的一個開發任務。我曾經出過這樣的考題：

寫一個小程序將一個以特定格式（如CSV）存儲的文本文件轉換為XML格式，并存儲為另一個文件。

　　你可以給他一臺已經配置好開發環境以及IDE的電腦，讓他當場編寫代碼。當然如果時間有限，你也可以直接詢問面試者的實現思路，并簡單用偽代碼來描述處理過程。通過這個測試，你能夠看到很多細節，比如面試者是否有良好的編碼習慣，異常處理是否規范，代碼邏輯是否縝密高效，以及他的開發效率是否足夠高。如果面試者給出了非常優秀的解答，那么你就應該能夠判斷他確實是一個優秀的候選人了，因為我從沒碰到過能夠通過上面的測試，卻在實際工作中無法做好的人。

　　8. 以上絕不能保證你招到合適的程序員

　　你可以在面試程序員時參考上面的這些步驟，對于我來說大多數情況下它們都是有效的，但偶爾也會出錯。你需要結合你所在公司和團隊的實際情況，提煉你覺得有用的面試步驟，并忽略其他的，最終形成屬于你自己的面試策略。另外，你還需要根據面試時的實際情況，隨機應變，因為人是最復雜的動物，而面試過程卻是需要雙方互動的。

　　想象一下，在你退休之前的未來幾十年時間里，你都需要每周40小時地工作，因此無論是公司還是應聘者都應該互相尊重，建立充分的信任，并充分判斷是否適合對方后，再確定是否雇用某人或接受一個公司的職位。你的目標不應該是簡單的獲得一份工作或者雇傭某個人，而應該以獲得更多的工作樂趣和建立更良好的工作關系為目的去看待招聘這件事，切忌不要急于求成，就像談戀愛一樣，當雙方都有感覺時，一切就水到渠成了。

　　又到了一年中的招聘熱季了，希望每一位年輕的程序員朋友都能找到一份讓自己快樂的工作 ~