摘要： 招人也不容易啊。

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

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小時地工作，因此無論是公司還是應聘者都應該互相尊重，建立充分的信任，並充分判斷是否適合對方後，再確定是否僱用某人或接受一個公司的職位。你的目標不應該是簡單的獲得一份工作或者僱傭某個人，而應該以獲得更多的工作樂趣和建立更良好的工作關係為目的去看待招聘這件事，切忌不要急於求成，就像談戀愛一樣，當雙方都有感覺時，一切就水到渠成了。

關於Fundebug

Fundebug專注於JavaScript、微信小程式、微信小遊戲、支付寶小程式、React Native、Node.js和Java實時BUG監控。 自從2016年雙十一正式上線，Fundebug累計處理了8億+錯誤事件，得到了Google、360、金山軟體、百姓網等眾多知名使用者的認可。歡迎免費試用！

您的使用者遇到BUG了嗎？