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