用一個簡單問題，我就這樣改良了技術面試

招聘過程

我之前的主要工作是參與招聘並進行技術面試，招聘的總過程如下：
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個泛泛而談的問題涉及面太窄，我沒法通過其他方式判斷此人是否是優秀的程式設計師。

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

測試經理（Quiz manager）3000

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

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

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

只需編碼

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

示例：

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

起初，我對結果感到很振奮，並繼續執行了幾個月，然而再一次的，我意識到我遺漏了些什麼……好像有些事不對勁……事實上我確實可以依靠這種方式找出能解決演算法問題的人，但他們真的是我所要尋找的優秀程式設計師嗎？請你思考一下，一個程式設計師的水平是不是由他能否解決一個數學問題所定義的？是不是由他能否寫出複雜度為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或其它我們正在使用的指定框架，然而當他們一進入工作後，他們總是會成為金牌程式設計師。他們學習快速，能寫出更好的程式碼，他們用創造力和正能量激勵著其他人，他們是真正的程式設計師。

完。