[[119175]]

常見的招聘過程

我之前的主要工作是參與招聘并進行技術面試，招聘的總過程如下：

1. HR所進行的面試：判斷候選人是不是一個連環殺手或精神病。

2. 技術專家進行的面試：判斷候選人是不是一個優秀的程序員。

3. 大老板進行的面試：判斷候選人愿意接受多少報酬。

我面試過兩種類型的人：實習生和準員工。實習生只需要經歷以上第二條步驟即可，其他人則需要經歷所有的步驟。在那個公司工作的兩年多時間里，我進行 了超過200次技術面試，這對我來說是一種豐富的學習經歷，我逐步弄清了這一過程的實質。這里有一個很重要的前提，請你記住，在法國你不能輕易解雇一個 人，雇傭了一個錯誤的家伙，你就等著抱憾終身吧。找出最好的候選人極為關鍵，不能犯任何錯誤，這是一個繁瑣的過程，但我樂在其中。

特別專業的中彩票式技術問題

在2008年，我進行了我的第一次技術面試，當時，公司已經有了一套工作流程供我參照：面試時間1小時，候選人有30分鐘時間回答15個測試問題， 之后我們會花15分鐘時間討論他們的回答，外加15分鐘時間回答關于工作方面的問題。我很快就意識到這樣的問卷是多么的糟糕，我的意思是，你竭盡全力也找 不出比它更坑爹的東西了。我們公司里大概有50%的項目都是使用Java編寫的，所以測試題就非常專注于Java，其中包含了5個瑣碎的問題，緊接著是 10個關于特定Java框架的極難問題，比如我們經常使用的問題有：

類和對象的區別。

或

Struts 2中的execAndwait攔截器的用途是什么？

見鬼的是，甚至是我自己都無法解釋這些問題或再補充點什么，每一次面試我都祈禱候選人不會用這些問題來反問我！對一個面試官來說，這很諷刺，不是 嗎？無論如何我還是會快速瀏覽一下他們的回答（2-5分鐘），之后將時間放在討論他們的簡歷上，這浪費了很多時間，于是我決定改進一下。我上網比較了成百 上千個面試問題，那時我相信我們必須在測試中放置正確的問題，才能展示一個人才的真正優秀之處，正所謂“好馬配好鞍”。

寬泛的、怎么回答都對的技術問題

經過大約一個月的研究，我已經在網上找遍了各種問題，提煉出最好的50個問題，我認為它們都是好問題，因為用任何語言都能回答它們，同時難度也是平穩提升的。我將這50個問題打散，組成5套10大題，隨機分發。

示例：

單例是什么？你什么時候會用它/不用它？

這問題好多了吧，我覺得顯而易見的，一個給力的問題通常會得到一個給力的回答作為回報，我實踐了幾個星期，但是不知何故這并不完全奏效，我覺得我已 經做的很好了，但結果卻并不怎么好。是的，這些問題能夠測試出一個人是否熟悉編程理論，然而最終我對此人能否編程依然一無所知，直到最后我也不確定用這種 方法招聘員工能比用以前那種粗糙的struts 2問卷好多少。我想了很多，我意識到這其中有兩個巨大的問題：

1. 問題太泛了，如果不專注于某一種語言，我無法討論諸如SQL，前端細節等話題。

2. 問題太短了，10個泛泛而談的問題涉及面太窄，我沒法通過其他方式判斷此人是否是優秀的程序員。

我需要的是更多的問題，并且這些問題必須針對候選人所申請的工作內容。

面試問題寶典：10萬個為什么

事情逐漸有點失控了，當時我繼續深入研究，并創建了一個全自動化的測試工具（在一個實習生的幫助下）：測試經理（QM）。這個工具使招聘過程變得完 美：在初次面試后，HR會選擇三個與工作描述相關的話題，之后工具會自動生成一組多項選擇題，其中包含3*20=60個隨機但具體的問題，其難度符合測試 者的經驗水準。

示例：

(javascript)
var i = 0;
function a(){
  var i = 2; 
  i++;
} 
a(); 
alert(i);    =>    0 ? 2 ? 3 ?

之后，工具會繪制一個小圖表，產生并發送郵件給HR，直接顯示結果，而不是一堆無用的指標。這是我多么為之驕傲的工具！我急切盼望著有候選人能夠測 試這套系統！我坐在HR旁邊，在內部系統上觀察候選人選擇某些答案后的實時分數。QM使我們所有的工作都變得更容易了，看上去非常完美，直到在我們自己的 開發人員上測試它時……

好吧，情況比我們想象中的更為離奇，我們之中許多優秀的開發人員會獲得和被我拒絕的那些人一樣的分數，這才是正解，QM被證明是無效的！我花費了很 多時間建立這個工具，同時也花費了很多時間認識到我犯了一個巨大的錯誤：我們希望對結果進行自動化處理，這迫使我們只能設置選擇題。用戶只需要選擇一個答 案，因而問題最后大多演變成了技巧性問題，最終的結果是我們根本沒有測試軟件開發的技能！要面對這副窘境非常艱難，但最后我還是承認這個工具產生了反作 用，展示了錯誤的印象。

面試時讓程序員去編碼

8個月過去了，我做了更多的研究，視察了一些美國公司篩選候選人的過程，這時候我決定去追求另一種方法：只需編碼。這是程序員得到報酬的原因啊，所 以為什么不直接展示給我看他們是怎樣寫代碼的呢？你會覺得這很合乎邏輯……在經歷了前幾個月的教訓后，現在測試變得很簡單：我會給出三個算法題，你需要在 30分鐘內解決它們。候選人可以任意選擇語言，并使用一臺電腦作答（無法連接網絡）。這些都是網上能找到的經典問題：其中一個算法題通常涉及字符串操作 （比如在一句句子中逆置單詞），另一個問題涉及循環（比如計算斐波那契數列），最后一個問題涉及集合（比如列表排序）。

示例：

print out digits 1-100.
for multiples of 3, print out foo.
for multiples of 5, print out bar.
for multiples of both 3 and 5, print out foobar.

所有事情都變得更清晰，更美好了。我可以很直觀地看到誰在代碼中縮進、注釋、遵循約定、尋找解決方案，等等。我可以據此判斷這個人在過去的編程量， 此外，通過與他們討論問題的答案也能獲得很多信息。我覺得候選人對這些測試題應該會感覺良好，因為我已經試圖解除他們所有的壓力，他們可以從容作答，選擇 他們想用的任何一門語言，征求建議，等等。

起初，我對結果感到很振奮，并繼續執行了幾個月，然而再一次的，我意識到我遺漏了些什么……好像有些事不對勁……事實上我確實可以依靠這種方式找出 能解決算法問題的人，但他們真的是我所要尋找的優秀程序員嗎？請你思考一下，一個程序員的水平是不是由他能否解決一個數學問題所定義的？是不是由他能否寫 出復雜度為O(n log n) 而非 O(n^2)的排序所決定的?

能夠一網打盡的面試問題

我很清楚的記得，當我初學編程時，windows 3.1還未問世，QBasic語言是搭載在MSDOS 5.0上的，它包含自帶的幫助信息，其中有所有的函數和關鍵字，像一本完美的離線手冊。至今我還記得那時候編程的獨特感受，縈繞在我心頭，每一次我敲擊 F5，看到我寫的程序在我眼前執行，每一行代碼，每一個提示，甚至是顏色，或難以解決的問題……我簡直是在天堂。我記得我在每一條命令前添加行號，用可怕 的GOTO填滿我的代碼，同時每天又能學到很多令人振奮的新東西。我熱愛編程，我會夜以繼日地編寫游戲、解決問題，并展示給我父母和朋友。時光飛逝，我從 QBasic到pascal到vb，通過2400bps的調制解調器和家庭電話線路，為我們的BBS（Atomic BBS）編寫游戲。我并不優秀，好吧事實上我的代碼相當糟糕！但我熱愛它！！我不能失去它……我猜有些人在他們第一次駕駛飛機、駕駛船只、吸食大麻、吃 in n out（譯注：美國一家漢堡快餐店）時會感受到他們的腎上腺素涌出的感覺，對我來說，那就是編程、編譯和運行。25年前我獲得了這種感受，至今它從未離我 而去，我為編程而生，我永遠都是程序員。

我始終相信，一個熱愛編程的人不會只在工作中編程，在家中他們也會繼續創造樂趣，這是一種愛好。多少次，我在工作中因為蛋疼的Eclipse而感到失望，只能在我回家后，寫Ruby on Rails代碼尋找快樂，放松身心！

回到上一個話題，在一年的嘗試和失敗后，我完全放棄了技術測試。我會坐在候選人身邊，花5到10分鐘閱讀和點評他的簡歷，不問任何問題，之后我會翻過簡歷，看著候選人的眼睛問道：“我們剩下大概30分鐘時間，你能告訴我你所編寫過的最成功的項目的情況嗎？”

這個簡單、獨特和客觀的問題是關鍵。一些人會含糊地回答他們之前的工作或學校的項目，而另一些人會突然變得生龍活虎，盡管一開始他們還有點放不開， 他們會熱情激昂的談論他們編寫的游戲、制作的站點、貢獻的開源項目、開發的工具，他們會很驕傲的展示給我看。我時常會被他們的侃侃而談吸引和著迷，繼而詢 問他們這些喜愛的項目的所有細節，他們的話匣子打開了，講述了他們所攻克的技術難題，加上一些小小的個人情懷，仿佛這就是他們的孩子。還有一點無法令人忘 懷：我仿佛可以看到他們眼中的光芒，仿佛可以看到他們小時候編譯和運行第一個hello world程序的情景，很快，我意識到了我們的共同點，我們都是程序員。

他們中的絕大多數人沒有接觸過struts或其它我們正在使用的指定框架，然而當他們一進入工作后，他們總是會成為金牌程序員。他們學習快速，能寫出更好的代碼，他們用創造力和正能量激勵著其他人，他們是真正的程序員。