是時候給糟糕的技術面試來場革命了
英文原文：The Terrible Technical Interview
傳統的技術面試對所有人來說都很糟糕，既不利于公司評估應聘者，也不利于應聘者評估公司，不僅浪費時間，還對雙方產生了壓力。幾乎所有面試過的人都同意這些。可他們依舊繼續這樣面試。
我在此謹建議那些有頗多選擇的工程師們干脆地拒絕這些面試。
不要緊張，下面我要介紹更好的面試方法。
上個月，丹尼·克萊頓（Danny Crichton）寫了 幾篇 關于技術面試的文章。這幾篇文章 寫得很不錯 ，我推薦大家讀一讀，在這里我只摘取文章中的一些要點：
沒有什么行業像軟件工程一樣如此公開地敵視其從業者……我們讓應聘者在壓力很大的面試環境下在白板上現場編程，只因為這是我們這行的慣例……我們實在不該在工程師緊缺的時候錯失如此多的人才。
他受到了 Thomas Ptacek 的文章的啟發：
現在這種軟件開發人員的面試行不通。公司不應該再用這種方法招人。聰明的團隊將通過設計新的招聘方案戰勝競爭對手。
的確如此。而且，在我的印象中，情況終于開始改變了。更多的公司開始讓應聘者做測試項目，而不是只做白板面試。其他公司也不那么熱衷于在面試階段剔除那些看起來合適的應聘者（而是在幾個月后更加無情地開除他們）。這些改變產生了效果，谷歌的人力資源主管幾年前也 承認 ：“腦筋急轉彎純粹是浪費時間”以及“測試分數沒有任何價值”。
然而技術面試還沒消失。我本可以再早幾年寫出這篇“ 技術面試已死 ”（這里有 中文版），可我沒有。至少技術面試現在還沒死。它已垂死，但死得過于緩慢。
我們這些痛恨技術面試的人不得不承認的是，即使公司知道白板型面試遠非完善，他們還是堅持使用，這是有原因的，其中一些算得上有部分正當性。這些原因包括：
- 面試從公司的角度講是一個相對可測量、可重復的過程。人人都知道面試的流程是怎樣的。不過是出幾個題目，設定一些考量答案的標準。甚至在必要的時候，（絕大多數）技術員工都能當面試官。
- 公司想盡早剔除明顯不合適的應聘者，因此很難不在面試中多問技術問題，就算我們這些人做面試官時也會如此……在特別傳統的面試中尤其如此。
- 你當然想選出有才能的人，剔除那些沒什么才能的人。傳統技術面試被認為更喜歡在面試中看起來沒什么才能的人，而不是看起來有才能其實沒有的人。看 起來有才能過去被視作災難性的狀況；雇用一個差工程師被視作比沒雇到兩個好工程師更糟。可在好工程師如此稀缺的今天，這樣的觀點已經過時了。
- 目前代替技術面試的方法是布置一個測試項目給應聘者，可這種方法充其量也仍舊不完美。事實上很難找到既有意義又不會占用應聘者太多時間的小項目。 同時，應聘者希望這個項目是有償的，他們也可能會說他們還沒辭職，不能花這么多功夫在一個考察性的項目上，而公司也會擔心項目會抄襲，甚至外包出去。
- 這就是為什么個人推薦依然是所有人最喜歡的招聘方法……
- ……反過來說明了為什么技術行業的如此缺乏多樣性。
因此，我們想找到一種代替傳統技術面試的可靠方法，這種方法既對公司有利，又對應聘者有利，還能幫助那些被現在這種推薦過程默默忽略掉的人。這個三贏的任務實在太艱巨了。
我當然不會忘記有很多致力于解決所有問題的創業公司。但我有個不一樣的想法。這種方法可以說是給應聘者增加了一項義務，不過我認為對應聘者還是有好處的。我的提議是：
- 工程師，尤其是那些炙手可熱的優秀工程師，應該開始干脆地拒絕參加白板型面試。
- 的確，只有在面試前就失去優秀的應聘者，才能更快迫使公司尋找更好的面試方法。
- 但是，拒絕的同時必須提出條件：用討論或演示應聘者自己在業余時間開發的一個小項目來代替面試。
這是我設想的應聘流程：
- 面試官用 30 到 60 分鐘熟悉應聘者開發的項目。
- 然后雙方花一到兩小時討論這一項目，包括應聘者做出的架構和實現決策、本可選擇的其他方案、他們希望添加的功能、代碼結構和每一行代碼的質量、環境和配置問題等等。
- 討論中經常涉及的主題應固定下來，這樣這些主題就能在其他面試中重復出現，應聘者和面試官可被互相比較，結果也能夠被測量。這些主題可以是：它們使用全局變量嗎？代碼遵循的是 MVC 框架還是別的架構模式？方法是合理結構化的還是封裝的？用戶界面能顯示出對可用性問題的了解嗎？有測試代碼嗎？等等。這些主題一半是為了綜合考察代碼，一半是為了考察應聘者“對他們（聲稱）自己寫的代碼理解了多少”。
- 接下來面試官讓應聘者現場給他們的項目添加一個小功能。
- 此時面試官應該很確定這個項目做得好不好，應聘者是不是真的肚子完成了這個項目。
- 如果答案是肯定的，那么雙方可以繼續約定一個時間，讓應聘者參與開發公司事先定好的測試項目。測試項目可以是一個長期項目，也可以是每幾個月做一 個新項目。（開發新項目很適合新雇員。）之后讓應聘者為新功能提交拉拽請求，這應該需要工作 4 到 8 小時。測試項目可以是任何類型的，但必須要小，足夠檢驗應聘者能正常工作且能保持合理的進度即可。
- 讓另一名面試官評估拉拽請求，看其他人對應聘者的看法如何。
- 或者也可以讓應聘者用一到兩小時給另一名面試官開發一個更小的功能，這樣更有說服力，也更高效。
- 最后決定是否雇用。
看，這不是有了代替技術面試的方法嗎？這個方法里不需要在白板上寫代碼，不需要回答腦筋急轉彎，也不需要應聘者寫出以后再也不用寫一遍的詳細算 法實現細節。我不會把這個方法吹噓成對所有問題的最終完美解決方案，但我相信對大多數還在固守白板面試的公司來說，這個方法或類似的方法是可行的，而且比 現狀好得多。
不過，這樣就需要一個比原來復雜得多的前提條件：每個應聘者都要有一個獨立完成的小項目作他們的名片。
我不覺得這是不合理的。事實上，我認為你可以開心地剔除所有沒有這張名片的人。（為了避免有人說我夸夸其談：我 自己就是一名 全職軟件工程師，我經常旅行， 寫過書 ，每周還給 TechCrunch 撰寫這個專欄，可我依然有空開發我自己的小軟件項目。 這是我最近開發的項目，是 開源 的。）
四年前，當我第一次在這里批評傳統技術面試無效的逆生產性時，我 寫到 ：” 不要面試任何毫無建樹的人。絕對不要。證書和學位不是成績，有真正用戶的真正項目才是。在一個 Google App Engine 和 Amazon Web Services 都有免費服務層、注冊為安卓開發者并在安卓市場中發布應用只需 25 美元的世界里，軟件開發者沒有理由沒做過一個他能自豪地拿給別人看的網站、應用或服務。”
我想，這些話放在今天更是如此。而另一方面，如果你真有成績，有一個值得夸耀的個人項目，那你不該再跳進白板編程面試這種毫無意義的怪圈中。你可以做得更好。我們都可以做得更好。