在 DigitalOcean，我們正在對後端開發人員招聘流程做出一些改變，簡化了崗位描述與面試流程，但是額外增加了一個環節：請候選人寫點程式碼。 這是基於我對招聘流程的經驗和他們對程式碼評審的使用來考慮的。
大概在2005年，我為拉丁美洲最大的媒體集團的網際網路部門Globo.com面試管理崗候選人，那時候，我剛剛做完幾年諮詢工作，重新回到產品開發崗位，這個機會讓我感到格外興奮。
開始工作前一週，我的新老闆給我發了封郵件，安排了我的第一份工作——為我的團隊再招募4名成員。當時的情形略顯尷尬，我完全不知道我需要什麼樣的人，因為我還沒有開始幹活呢。
我開始思考，在我認識的人中，哪些人會是幾乎所有工程崗位的完美人選，哪些是我會去挖的。然後又思考這些人都共同具有哪些別具一格的特徵或習慣。很快，我發現了一個共同的模式：那些我認為適合幾乎所有工程崗位的人，都經常讀書。不僅僅是他們日常工作中的參考書，他們還閱讀關於軟體架構，關於物件導向設計，關於晦澀的程式語言以及能夠指點他們在專業上更加優秀的書籍。
在巴西，我有個稍微有點人氣的程式設計部落格，所以就在上面發了篇招聘博文，我盡我所能描述了這個崗位，邀請候選人把他們的簡歷和最近閱讀的三本書名傳送給我。
迴應非常熱烈，我新申請的臨時郵箱裡塞滿了簡歷，並且證實了我的假設：最有趣的的簡歷，總是與來自前面提到類別中的書籍列表關連在一起。
在Globo，我們使用這個流程已經招募了一隻龐大的隊伍，我們的一些校友在新的組織中也在使用類似的方法。
幾年後，我到ThoughtWorks公司求職。過去幾年我已經歷了幾個國際性公司，在這些公司和其他辦事處交流時我不得不使用英語，但這次我連續一個多小時都在說英語。嗯，ThoughtWorks的面試官通過Skype，評估我的程式設計能力！！！當時我的內心是崩潰的。
幸運的是，ThoughtWorks後續還有一套與一般公司有點不一樣的面試流程。對候選人快速初步篩選後，他們發給我三個題目，讓我選擇其一進行挑戰，我可以使用任何一種我喜歡的語言解決的小問題。我提交的程式碼將會在後續的面試過程中使用，包括一次結對程式設計體驗——我將會和一個ThoughtWorker一起擴充套件我的程式碼，新增新的特性。
我在ThoughtWorks工作了四年，見證這個招聘流程一次又一次獲得了持續性的好結果。不指定候選人使用哪一種語言或哪一種工具是很重要的。我在ThoughtWorks的經歷是這樣的：要麼選擇感興趣的專案，要麼選擇感興趣的語言（我使用Drupal語言寫了網際網路級別的網頁爬蟲，使用F#寫了日程表軟體），所以我們真正實踐了因態度而聘用，而不是技能。
這幾年之後，是時候換個環境了。在ThoughtWorks就職期間所有經歷近乎滿意，除了最後一個專案，可能是我最差的一個。當我四處尋求新職位的時候，我害怕不得不經歷網際網路大公司讓我的朋友經歷的那類事情——在白板程式設計環節與無用的智力題較勁。
最終，幸運再一次降臨到我的頭上，我向SoundCloud公司申請了工作崗位。當時只有幾個工程師申請，SoundCloud公司的招聘流程與ThoughtWorks相似，先是候選人初步篩選，然後編碼挑戰。與ThoughtWorks不同的是，SoundCloud公司的編碼挑戰不再是智力題，而是接近公司實際工作中可能會遇到的問題。SoundCloud讓我從使用者介面層到所有我能想到的後端層構建一個上傳工具。
有一部分比較具有挑戰性： 怎樣實現一個實時更新的進度條。在這個專案上工作了八個小時之後，腦袋就像當機了一樣，但是我發現自己在從東克里登返回倫敦的火車上依然在思考著可能的解決方案，一下車我馬上走進七寶老街上那個我最喜歡的咖啡店裡繼續工作。解決這個問題非常有意思，如果你想知道2011年Clojure語言最流行什麼，一個人如何利用帶著波形括號的Scheme假裝知道JavaScript，你可以看看這裡的程式碼。
幾個星期之後，我獲得了這份工作並前往柏林。和其他小公司一樣，我的試用期還沒結束就已經開始評審新的候選者的程式碼了。不幸的是，那裡的經歷十分令我失望。
事實證明，大部分人的Rails應用的Gemfile裡的程式碼行比他們真正編寫的程式碼行還要多，更糟糕的是，更多人只是隨機從一個Flash元件網站找了個Adobe Flash上傳工具，一行程式碼也沒寫。簡化到就是一個外掛加上最少的膠水程式碼，對候選人或我的時間來講，這都不是有效的利用方式——在邀請他們進行後續的面試環節之前，我需要他們寫點我們可以閱讀的程式碼呀。
然後，我們想出另一個挑戰。這一次，我們更嚴格一點。仍然不限制候選人使用的語言（就像ThoughtWorks一樣，像SoundCloud一樣從一個小任務開始，當時我們需要T型人，而不是其他的），但要求只能使用候選者選擇的語言的標準庫，不能使用第三方庫或框架。為了更具有可行性，我們不要求做成一個web應用，而是每個平臺都能提供的——一個套接字伺服器介面和一個簡單的文字協議。為了讓這個挑戰更接近一個公司一年內使用者量從1000萬增長到1億的需求，我們還包含了客戶端能夠同時處理數百個使用者的需求。
但是我們還做了些其他的。這些事情能夠確保候選者的程式碼呈現給我們之前就確保滿足功能性需求，避免明顯不能執行的程式碼進入評審階段，這不僅提升了候選者的體驗，也為為我們節省了大把時間。
和問題描述一起，我們還給候選人傳送了一個測試套件：一個執行起來就會嘗試連線到候選人開發的伺服器上的二進位制檔案。當套件執行起來的時候，它會開啟很多套接字，傳送大量的訊息，然後與問題描述提供的測試樣例進行對比驗證。候選人只有在他們自己的機器上通過了功能測試才能提交他們的程式碼。
最好的提交非 Flávio Brasil莫屬——他現在在Twitter工作—— Flávio Brasil不僅發現了那個測試套件裡的一個bug，還對套件進行了反編譯，在他的程式碼挑戰提交裡附上了一份補丁。我們收到了來自世界各地的程式碼。我們擁有如此多的量化資料，我甚至針對在使用Node.js編寫的程式碼中發現的某些問題發表了演講。
DigitalOcean新一輪招聘中，我試著儘量綜合使用以往的經驗。總體上，程式碼挑戰題目與在SoundCloud開發的類似，但也有些明顯不同的地方。
第一個主要的變化是我們嘗試使用一個簡化的更接近ThoughtWorks的面試過程，之前我們會有專門的白板程式設計環節或者是結對程式設計環節。但是這一次，我們將會給候選人一個機會，讓他們聊聊他們寫的程式碼，而不是問些已經在暢銷書裡分門別類列出來的大眾化的問題。
另一個變化是我們更加註重開發產品的流程，或者怎樣測試、構建、執行應用。不管我們多麼以產品為中心，DigitalOcean都是一家基礎平臺公司，我們總是在開發過程中打破第四堵牆。對構建和執行時工具表現出興趣很好地暗示了我們文化上的契合。
但是最重要的變化是候選者提交程式碼給我們評審的方式。在之前的工作中，作為評審者，我會收到候選人的程式碼和簡歷。過去幾年裡，工業界和學界已經強有力地證明了，當我們判斷一段程式碼是好是壞時，偏見會影響我們的結論。為了儘量減小主觀偏差，我們要求候選人不得在提交的程式碼新增任何標識候選人身份的資訊。我們讓評審者大概知道候選人水平屬於那個級別，擁有幾年工作經驗，但不會暴露候選人的性別，名字，國籍，地理位置或者經歷過哪些學校或公司。這些會讓我們超讚的招聘團隊付出很多很多，要求程式碼評審人極具耐心，但是最終結果非常棒。
新一輪的招聘流程讓我超級興奮，不僅僅是因為它能找到正確的人壯大我們的團隊，我還希望在將來的某個時間點，我們擁有足夠多的資料能夠與業界分享。