是時候給糟糕的技術面試來場革命了

傳統的技術面試對全部人來講都很糟糕，既不利於公司評估應聘者，也不利於應聘者評估公司，不只浪費時間，還對雙方產生了壓力。幾乎全部面試過的人都贊成這些。可他們依舊繼續這樣面試。

我在此謹建議那些有頗多選擇的工程師們乾脆地拒絕這些面試。

沒關係張，下面我要介紹更好的面試方法。

上個月，丹尼·克萊頓（Danny Crichton）寫了 幾篇 關於技術面試的文章。這幾篇文章 寫得很不錯 ，我推薦你們讀一讀，在這裏我只摘取文章中的一些要點：

沒有什麼行業像軟件工程同樣如此公開地敵視其從業者……咱們讓應聘者在壓力很大的面試環境下在白板上現場編程，只由於這是咱們這行的慣例……咱們實在不應在工程師緊缺的時候錯失如此多的人才。

他受到了 Thomas Ptacek 的文章的啓發：

如今這種軟件開發人員的面試行不通。公司不該該再用這種方法招人。聰明的團隊將經過設計新的招聘方案打敗競爭對手。

的確如此。並且，在個人印象中，狀況終於開始改變了。更多的公司開始讓應聘者作測試項目，而不是隻作白板面試。其餘公司也不那麼熱衷於在面試階段剔除那些看起來合適的應聘者（而是在幾個月後更加無情地開除他們）。這些改變產生了效果，谷歌的人力資源主管幾年前也 認可 ：「腦筋急轉彎純粹是浪費時間」以及「測試分數沒有任何價值」。

然而技術面試還沒消失。我本能夠再早幾年寫出這篇「 技術面試已死 」（這裏有 中文版），可我沒有。至少技術面試如今還沒死。它已垂死，但死得過於緩慢。

咱們這些痛恨技術面試的人不得不認可的是，即便公司知道白板型面試遠非完善，他們仍是堅持使用，這是有緣由的，其中一些算得上有部分正當性。這些緣由包括：

• 面試從公司的角度講是一個相對可測量、可重複的過程。人人都知道面試的流程是怎樣的。不過是出幾個題目，設定一些考量答案的標準。甚至在必要的時候，（絕大多數）技術員工都能當面試官。

• 公司想盡早剔除明顯不合適的應聘者，所以很難不在面試中多問技術問題，就算咱們這些人作面試官時也會如此……在特別傳統的面試中尤爲如此。

• 你固然想選出有才能的人，剔除那些沒什麼才能的人。傳統技術面試被認爲更喜歡在面試中看起來沒什麼才能的人，而不是看起來有才能其實沒有的人。看起來有才能過去被視做災難性的情況；僱用一個差工程師被視做比沒僱到兩個好工程師更糟。可在好工程師如此稀缺的今天，這樣的觀點已通過時了。

• 目前代替技術面試的方法是佈置一個測試項目給應聘者，可這種方法充其量也仍舊不完美。事實上很難找到既有意義又不會佔用應聘者太多時間的小項目。同時，應聘者但願這個項目是有償的，他們也可能會說他們還沒辭職，不能花這麼多功夫在一個考察性的項目上，而公司也會擔憂項目會抄襲，甚至外包出去。

• 這就是爲何我的推薦依然是全部人最喜歡的招聘方法……

• ……反過來講明瞭爲何技術行業的如此缺少多樣性。

所以，咱們想找到一種代替傳統技術面試的可靠方法，這種方法既對公司有利，又對應聘者有利，還能幫助那些被如今這種推薦過程默默忽略掉的人。這個三贏的任務實在太艱鉅了。

我固然不會忘記有不少致力於解決全部問題的創業公司。但我有個不同的想法。這種方法能夠說是給應聘者增長了一項義務，不過我認爲對應聘者仍是有好處的。個人提議是：

• 工程師，尤爲是那些煊赫一時的優秀工程師，應該開始乾脆地拒絕參加白板型面試。

• 的確，只有在面試前就失去優秀的應聘者，才能更快迫使公司尋找更好的面試方法。

• 可是，拒絕的同時必須提出條件：用討論或演示應聘者本身在業餘時間開發的一個小項目來代替面試。

這是我設想的應聘流程：

1. 面試官用 30 到 60 分鐘熟悉應聘者開發的項目。

2. 而後雙方花一到兩小時討論這一項目，包括應聘者作出的架構和實現決策、本可選擇的其餘方案、他們但願添加的功能、代碼結構和每一行代碼的質量、環境和配置問題等等。

3. 討論中常常涉及的主題應固定下來，這樣這些主題就能在其餘面試中重複出現，應聘者和麪試官可被互相比較，結果也可以被測量。這些主題能夠是：它們使用全局變量嗎？代碼遵循的是 MVC 框架仍是別的架構模式？方法是合理結構化的仍是封裝的？用戶界面能顯示出對可用性問題的瞭解嗎？有測試代碼嗎？等等。這些主題一半是爲了綜合考察代碼，一半是爲了考察應聘者「對他們（聲稱）本身寫的代碼理解了多少」。

4. 接下來面試官讓應聘者現場給他們的項目添加一個小功能。

5. 此時面試官應該很肯定這個項目作得好很差，應聘者是否是真的肚子完成了這個項目。

6. 若是答案是確定的，那麼雙方能夠繼續約定一個時間，讓應聘者參與開發公司事先定好的測試項目。測試項目能夠是一個長期項目，也能夠是每幾個月作一個新項目。（開發新項目很適合新僱員。）以後讓應聘者爲新功能提交拉拽請求，這應該須要工做 4 到 8 小時。測試項目能夠是任何類型的，但必需要小，足夠檢驗應聘者能正常工做且能保持合理的進度便可。

7. 讓另外一名面試官評估拉拽請求，看其餘人對應聘者的見解如何。

8. 或者也可讓應聘者用一到兩小時給另外一名面試官開發一個更小的功能，這樣更有說服力，也更高效。

9. 最後決定是否僱用。

看，這不是有了代替技術面試的方法嗎？這個方法裏不須要在白板上寫代碼，不須要回答腦筋急轉彎，也不須要應聘者寫出之後不再用寫一遍的詳細算法實現細節。我不會把這個方法吹噓成對全部問題的最終完美解決方案，但我相信對大多數還在固守白板面試的公司來講，這個方法或相似的方法是可行的，並且比現狀好得多。

不過，這樣就須要一個比原來複雜得多的前提條件：每一個應聘者都要有一個獨立完成的小項目做他們的名片。

我不以爲這是不合理的。事實上，我認爲你能夠開心地剔除全部沒有這張名片的人。（爲了不有人說我誇誇其談：我 本身就是一名 全職軟件工程師，我常常旅行， 寫過書 ，每週還給 TechCrunch 撰寫這個專欄，可我依然有空開發我本身的小軟件項目。 這是我最近開發的項目，是 開源 的。）

四年前，當我第一次在這裏批評傳統技術面試無效的逆生產性時，我 寫到 ：」 不要面試任何毫無建樹的人。絕對不要。證書和學位不是成績，有真正用戶的真正項目纔是。在一個 Google App Engine 和 Amazon Web Services 都有免費服務層、註冊爲安卓開發者並在安卓市場中發佈應用只需 25 美圓的世界裏，軟件開發者沒有理由沒作過一個他能自豪地拿給別人看的網站、應用或服務。」

我想，這些話放在今天更是如此。而另外一方面，若是你真有成績，有一個值得誇耀的我的項目，那你不應再跳進白板編程面試這種毫無心義的怪圈中。你能夠作得更好。咱們均可以作得更好。