如何招聘程式設計師，四步法則助你成功

　　怎樣招聘程式設計師

　　本文記錄了本人招聘程式設計師的方法，希望能幫助你建立一個出色的團隊。

 

　　一般來說招聘程式設計師不算難。但要總結出如何招聘程式設計師，特別是招聘優秀程式設計師還是比想象中要困難的。尤其是你要招聘一個全職的員工（無論是否遠端工作）。這裡面涉及到很多東西，比如文化背景，職業素養還有最重要的方面-技術領域（程式設計師是否知道如何實現他們口中宣稱的技術）。我們假設你只是在招聘一個外包人員來做一個小專案，如果要招優秀程式設計師仍然是不容易的。你如何考評應聘人員？你如何知道怎樣可行怎樣不行？你如何發現自己是在拿錢打水漂？答案是你根本就不知道。

　　你竭盡全力的面試候選人然後挑選最合格人的加入團隊。如果這個人不行你就換一個，直到找到那個能呆下來的。問題是沒人說非得要走這個流程。我下面將分享我在招聘程式設計師時採用的方法，通過這種方式在過去幾年裡我招到了最優質的遠端工作者，外包人員和全職員工。我招聘遠端程式設計師和現場程式設計師時也採用了同樣的方式。

　　在我找到了候選人後，我會讓他們經歷四輪面試：

　　四輪面試流程：

1. 非正式HR電話溝通（電話/Skype/Google Hangout)
2. 技術電話溝通 （電話/Skype/Google Hangout）
3. 程式設計測試篩選
4. 文化融合評估如果候選人通過了所有的四輪測試，那很可能你找對人了。上述流程找到的人具有下面的特點：

•  技術上能夠完成工作任務
• 能夠融入公司文化
• 善於有效溝通和發散思維

　　四輪流程的目標

　　可能你也注意到前兩輪篩選都是採用電話/Skype/Google Hangout作為溝通工具。為啥哩？答案非常簡單：時間寶貴啊。時間一去不復返…如果我能為團隊節省會議室，出差等我會很樂意去做。這就是電話面試的目的。通常候選人也會傾向於這種方式，畢竟這節省的是大家的時間啊。所以前幾步的目的就是為了節省公司和員工的時間。

　　我們的目標是：節約時間！

　　每一輪都是在不同時間完成的。一般來說最少也得間隔4到6個小時吧。留出時間間隔的目的是讓團隊有時間決定是否讓候選人進入下一個流程。例如：第一輪面試後團隊決定放棄後續的面試，那就可以通過電子（郵件或電話）方式通知候選人然後繼續自己愉快的一天。第二步第三步是一樣的道理。第四步就是要上手的了，後面會細說。這也可以說是“敏捷”式招聘。每一步都是迭代式的迴圈並建立於上一步的成功。也可以看著是一種測試驅動（TDD)式招聘流程。 第一步測試通過了嗎？通過了就進入第二步。第二步通過了嗎？通過了，太好了。進入第三步吧， 第三步通過了嗎？沒有。 好吧，GameOver了， 不用浪費後面的時間了。

　　步驟細說

　　下面就細說一下各個步驟，並提供了參考提問，外部資源的連結以及優化流程的建議。

　　第一輪：非正式HR篩選（10到30分鐘）

　　終極目標：基於基本對話和HR的經典必殺問題判斷候選人是否適合目標崗位

　　第一輪其實是很短的。 又想到了節約時間的問題—這是第一道關卡。你也可以把它變得更短。你需要確認這個人能有效的溝通，思路清晰沒有社交恐懼症啥的。比如有人滿嘴的”Cao” (原文是F開頭的四字單詞），那這種人就很可能不太適合團隊。

　　這一輪一般交給招聘經理（有時候就是你（HR), 有時候是別人）。這一輪經理應該描述工作性質並與候選人對話。下面是一些參考問題：

• 為什麼申請這個職位？
• 在X方面你有多少經驗？（X就是你們正在乾的事兒，或者是新技術等等）
• 談談你的上一份工作?

　　接下來還可以採用傳統的面試問題。例如下面這些：

• 你會如何處理X情況？（X就是HR的經典問題）
• 講講你遇到無法解決的問題時，後來是怎樣解決的？
• 跟同事有不同意見，你是如何處理的？
• 你對我們公司有了解嗎？
• 你對我們有問題要問嗎？

　　此時此刻，你就可也判斷候選人是不是思路清晰，或者是跟你在扯八卦。也就可以判斷是否進入下一步：技術篩選

　　第二輪： 技術篩選（10到30分鐘）

　　終極目標：採用問答形式判斷候選人是否具有所需的技術（Skype/Hangout/電話形式)

　　技術篩選是第二道關卡。這一輪應該持續10到30分鐘取決於問題的難度。如果候選人答不上的問題太多，可以隨意縮短時間。所提的問題根據招聘的程式設計師型別有所區別。但應該覆蓋正在使用的一些程式語言基礎，框架基礎，伺服器。可以提一些開放式的問題讓候選人自己解釋。儘量避免問一些是/非問題。下面是一些參考問題：

　　NodeJS 參考提問：

• 請解釋NodeJS裡ExpressJS的作用以及你為什麼會使用它
• Sync和Async call的區別以及你更傾向於採用哪種方式，為什麼？
• 你使用哪個測試框架？
• 知道V8是什麼嗎？

　　Android 參考提問：

• 什麼是AsyncTask，什麼時候你會使用它？
• 什麼是ActionBar
• 什麼是Gradle以及使用場景
• 如何在Android上做單元測試

　　Rails 參考提問：

• 什麼是asset管道
• 什麼是控制器(controller)?
• 什麼是RSpec以及使用場景？
• 什麼是路由？

　　通常這類面試由團隊成員進行。有時候是兩個程式設計師。如果是兩個面試官，相互間要有個暗號告訴對方候選人不合適以節省時間。我之前就採用了下面的方式：

　　“提醒我跟你講早上我在加油站的遭遇”

　　“面試結束後提醒我給我表弟打電話”

　　道理你應該已經懂了。自己編一個吧。至少有50%的時間你希望儘快結束面試因為候選人不靠譜。記住，目標是：節約時間。

　　第三輪： 程式設計測試（2-4個小時/夜間）

　　終極目標：判斷候選人擁有通過程式碼解決問題的能力。瞭解程式碼質量。

　　面試過程中，要求候選人採用指定的語言解決實際問題。一個有經驗的程式設計師應該在一個小時之內解決問題。我會給出2-4小時的範圍以便候選人有足夠的時間完成任務。為了公平公正我一般會允許候選人在家裡舒適的環境下接受面試，以排除壓力並瞭解他們實際如何解決問題。有些公司更喜歡在現場給候選人提供電腦和網路。不管哪種方式，目標很簡單：瞭解候選人能否寫出正確的程式碼。

　　程式設計測試是很好的調節閥。不是說問題有多難（恰恰相反，問題很簡單），而是因為你可以瞭解對方的程式碼質量，同時也能找到以下問題的答案：

• 候選人的溝通能力
• 候選人是否知道服從指示？
• 候選人知道如何使用git和GitHub嗎（後面會細說）
• 候選人知道最佳程式碼實踐嗎？
• 候選人知道如何寫程式碼嗎？
• 候選人能通過測試嗎？

　　如果我讓候選人在空閒時間裡在家面試，我一般會告訴他們我會在下午5點通過郵件告訴他們題目以及解決問題的提示。我告訴他們最遲在明天中午12點前得完成。問題會發布到GitHub/BitBucket的repo裡，這個repo會為每個候選人建立一個。repo包含了所有關於問題的描述。候選人需要做的就是跟隨指示並將結果發給我。下面是一些我建立的例子：

　　NodeJS 例子

　　Android 例子

　　Rails 例子

　　你可以fork這些例子並儲存。如果你訪問過這些網站中的任何一個你就會發現這裡面的每一個例子都要求候選人經歷一系列步驟。如果候選人不清楚幹什麼，他們可以跟我確認或者直接在Goolge上找答案。候選人完成後需要提交一個pull 請求給我，然後我可以進行評審。我知道不是所有人都用Git來管理原始碼，所以你可以進行修改，以便採用mercurial或者SVN來管理。

　　這種方式可以說是神來之筆，因為它能全方面瞭解候選人。比如候選人是否能按時寫出程式碼完成工作。同時也能讓我審查程式碼來判斷到底是好還是壞。基於我的經驗，平均60%的候選人不能完成任務，因為他們不知道如何解決問題。這也是我讓他們在家面試的原因。從第一步到第三步都可以遠端進行。這為公司節約了時間。在這完成了任務的40%的人中，只有20%的人做對了，並且到這個時候基本上只剩下一兩個候選人看起來不錯。如果你有更多的選擇當然更好。

　　對於這種方式有一個很正常的顧慮：萬一他們作弊怎麼辦？如果他們叫朋友或者其他人當槍手怎麼辦？是有這種可能，但我認為現實中也存在這個問題。有時候程式設計師不知道如何解決問題就會尋求幫助。他們通過QQ向朋友求助，或者是在網上搜或者是找一些滿足要求的開源專案來修改。這就是程式設計師的作風，管你是在家還是在公司誰關心。如果對方真是在欺騙，我想很快我也能發現。就算是對方被招進來了，團隊也能很快發現問題。這時候你就需要需要決定是否要留下這個人了。

　　如果候選人沒能完成測試，這就直接是紅牌了。當然出的問題也應該足夠簡單讓有經驗的程式設計師能在一個小時內完成。如果不能完成，要麼是題目太難了要麼是候選人不合適。如果你用的是我上面提到的連結（或者類似的），那就不存在這個問題。對於那些沒通過測試的，我建議放棄後面的面試直接換下一個人。

　　對那些完成題目的我會審查程式碼。如果沒問題我會繼續面試。這種情況其實很少。一般我會問候選人為什麼會用他的方式去寫程式碼。比如我會問一個做Android題目的人為什麼會用HttpGet而不是類似OkHttp或http-request的庫。對於做NodeJS題目的人我會問為什麼會採用原生的http請求而不是restler或rest。問這些問題的目的是考察候選人的思維方式，也能更多的瞭解他們的性格。有時你也能從他們身上學到一些東西。

　　如果沒人解決問題，那就繼續釋出職位需求。有時候我要發好幾遍才能找到合適的人。

　　第四輪：文化融合評估（2-4小時）

　　目標：考察候選人是否能融入公司文化

　　到這一步，候選人通過了HR和技術的電話面試，以及程式設計測試。或許你認為應該聘用這個人了。但注意不要被激動衝昏頭腦—你需要了解這個人是不是能夠和你以及團隊一起和諧共事。這時候我會把候選人帶到辦公室和團隊見面並共用午餐。我一般叫他們在指定的時間來公司（上午11點到12點）並安排團隊午飯。我們會去一個常去的地方吃飯。不要去一個高檔的或者團隊不熟悉的地方吃飯。否則團隊不會全部參加或則氣氛變味。我們需要的是平常和正常，就是一個每天工作狀態的展示。這樣我們能評估他的個性並試圖發現一些影響團隊和諧的因素。如果我們發現有人感覺不對，我們就不會聘用候選人。因為以後的路還長，如果一見不能鍾情，日久就要生恨，工作也不會出色。

　　情景再現： 有個人前幾輪結果都恨優秀。我有點小激動。我帶他們出去吃午飯才發現他們非常沒素質，極端的具有消極進攻性（passive aggressive)而且有時非常計較。我們都應該有過這種感受：不要惹桌子對面的那個人。後來我就認為這人不適合團隊也沒有發offer。

　　你還應該帶新人在辦公室/園區等轉一轉。跟他們講講職位以瞭解他們的興趣。問他們一些針對公司的寬泛問題，看他們是否對公司進行過了解。總之就是要了解這個人。你要問自己這樣一個問題：要是這個人在下班後跟你一起吃飯喝東西你願意嗎？如果你的回答是不，那又是紅牌需要商榷了。

　　候選人走後，和團隊的人聊一聊他們的看法（如果這個人是招進來的第一個人，只有靠直覺）。如果候選人還靠譜那就發offer，否則—下一位。

　　總結：

　　好馬不好找，找好馬還要省錢就更難。上面的四輪法則將幫你節省時間並找到最佳人選。不要怕嘗試下一個人選。與其招庸人不如耐心等。記住，第三輪是調節閥。這裡是“行”與“不行”的分水嶺。如此多的人卡在這一關讓我有點驚訝。祝大家找馬順利。

　　原文連結： Donn Felker   翻譯： 伯樂線上 - 梧桐