你們不能這樣招聘程式設計師

　　作為程式設計師，找工作有時候似乎挺苦逼的。

　　說真的，讓我去掉前面這句中“似乎”二字吧。就是苦逼！很多人都曾抱怨處在招聘的一方很糟糕——我們沒有任何可靠的方式來甄別會寫程式碼並且寫得好的人。這的確是真的，我們這行在這方面做得很糟糕。即使是在最常見的開發者群體（美國人、男性、白人、較為年輕和中產背景）當中，我們的甄別能力也絕對是一敗塗地，而當面對更廣泛的人群時，我們只會幹得更差。但我們不得不擴大範圍，因為就算我們沒有道德感，我們也面臨著數量的問題，職位崗位比上述“精英”多，總共只有那麼多美國中產二十多歲的白人男性，然後其中一半根本不會應聘你們只發股權的“支援Uber、23andme、推特、部落衝突的無人機運輸”公司，因為他們正在你創業的星巴克馬路對面的另一家星巴克成立自己的公司。另一方面稱職並且想要技術崗位卻沒得到的女性、非白人、外國人數量簡直太多了。

　　但是應聘的一方（我現在所在的一方）也很苦逼。招聘方遇到的困境，也恰恰是造成痛苦流程的原因。

　　教育很爛

　　我們嘗試過的其中一個方法是看學歷。但是我們根本不擅長在學校教人程式設計。涉及到計算機的課程，應該是數學系還是工程系的延伸，多數大學都決定不下來。結果他們最後弄出來的是詭異的融合，但其實兩者都不是；或者他們在教程式設計，但是語言和技術已經落後現有規範好多年；又或者他們讓學生死記演算法列表及其複雜度，這會讓學生誤以為程式設計不過是死記硬背，然後成為一個能輸出正確演算法名字和虛擬碼的自動機。因為公司真正想找的是就是復讀機，難道不是嗎？直接開發一個資料結構的復讀機，可能再加上一個排序演算法的復讀機，大概就能省下很多面試的時間。

　　我深信現有的教育方式及其缺陷，是造成我們聽到的軟體招聘恐怖故事的原因。擁有 CS 碩士學位，卻似乎不能從一張白紙開始寫程式碼的人，其實不差；更有可能是他們受到的教育輕視實際程式設計而注重理論。在郵件列表和論壇釋出“請給我寫好的程式碼”帖子的人，其實不差；更有可能他們受到的教育建基於背誦和應試。另外如果你從沒讀過著名物理學家費曼造訪一所採用這個方法的大學的故事，我強烈推薦它。

　　那仍然是程式設計教學處在的階段：我們知道自己需要程式設計師，而我們沒有足夠多的程式設計師來寫程式碼，更別說教出更多的程式設計師，所以這種死記硬背的現象廣泛存在，這是因為這已經是我們現在力所能及的範圍。我們只是希望我們“教”出來的學生，會跑去看 Ruby on Rails 的教程，然後無意中看見 GitHub 的文件，然後從中神奇地學會真正的軟體開發、架構和最佳規範。因為大家都明白，他們不可能在學校裡學會這些。

　　與此同時另一方面，在我合作過的技術牛人當中，大多數根本沒有軟體工程和電腦科學的大學背景；很多人直到快上完學才第一次寫程式碼（ 不要臉的偏見：我直到快大學畢業才開始通常意義上的“程式設計”，我也是在畢業幾年後才開始以此謀生）。很多真正厲害的人會被“電腦科學本科”這一條件過濾掉，這是招聘方不謹慎定下職位要求時會遇到的問題。即使招聘方費心加上“或擁有相當的經驗”，他們甚至也還是被過濾掉，因為履歷上的學位似乎就是招聘者和 HR 篩選推送給實際技術人員的求職者的第一條依據。

　　順帶一提，我有一個哲學學位。並不是炫耀，不過軟體領域很多我認識並尊敬的非常厲害的人都有著相同的背景。

　　所以將學歷作為篩選標準效果並不好；公司也很苦逼，因為擁有 CS 學位並不意味著一個人已經準備好坐下來寫程式碼；準備好寫程式碼的求職者也苦逼，因為沒有 CS 學位仍然是個短板，而且為了學位迴歸學校四年並不輕鬆。而且每一飛秒都有五萬個程式設計訓練營/培訓班被啟動，從中出來的人擁有哲學系、文學系、神學系、歷史系和現代 A 線詩歌符號學的學位，但是當他們經歷了訓練營後，他們大概至少能和計算機系的學生水平相當，因為 CS 的課程基本都很爛，而且主動加入程式設計訓練營的人通常很聰明而且充滿動力。而且如果他們能學會拆解 A 線詩歌，基本就能確認他們能用你的 JavaScript 框架寫出一個 CRUD 應用程式，因為那個 JavaScript 框架上週才釋出，所以根本沒有多少人擁有超過一兩天的 ReAngleBoneASS 實戰經驗。

　　程式設計面試很爛

　　由於學歷不靠譜，另一個甄別會程式設計的人的方式是程式設計面試。求職者和公司內部的某人交談（通常是電話或者視訊聊天），並被要求寫出解決問題的程式碼。如果你還保留著好奇心我就告訴你吧，我們不擅長用這個方式選出會程式設計的人。簡單來說，此類面試並不靠譜，因為它們太短、太做作、太壓迫。

　　詳細一點來說：我認識多個頂級人才被他們絕對勝任的職位給拒了，就因為這種程式設計面試。我傾向於把它們看作“問個謎語”風潮的最新版，這個環節當年由於微軟的實施而流行一時，因為每家公司都想像微軟一樣又大又成功。現在，人們聽說谷歌會進行程式設計面試，並且看到Jeff Atwood 的 FizzBuzz 測試，而每家公司都想像谷歌一樣又大又成功，並且與 Jeff Atwood 的招聘恐怖故事產生共鳴，所以現在所有人都在進行程式設計面試。但是這種面試依舊很爛。可能這是因為谷歌據說用的是白板，而其他公司用的是電話。

　　想不想看一個非常稱職卻因為程式設計面試而被拒絕的一個例子？他被拒是因為面試官在電話那頭筆錄錯了他念的 Bash 指令碼，這當然讓指令碼出了問題。我絕對沒有開玩笑或者誇張，而除了“神經病”我實在找不到其他形容。如果用的是白板，他就被錄取了。

　　事實上，我十分確定我搞砸過一次程式設計面試（至少我到現在還沒收到該公司的答覆）。要記住我並不是剛畢業入行的人。我已經有超過十年的 Web 應用開發經驗，處理過各種各樣的規模系統；我是一個非常重要的 Web 框架的核心團隊成員，並且可能是這方面的世界級專家；我真的寫了關於使用該框架的書（最早的幾本之一），有時會被聘請去教這個框架，以及被學術會議邀請去做關於這個框架的 keynote 演講。我曾經有一陣子沒怎麼睡覺，全程死死盯著一個正在執行的程式，想要理清 Django 的舊式系統，發現我的精神動物是一隻遲緩的懶猴，而過了一陣子當我的意識像甘道夫那樣重新塞進身體時，我提交了僅僅兩行程式碼進行反擊，解決了五個“深藏 Django 腹中”不同的 bug。我挺擅長這些的，如果你還沒注意到的話我希望你記住這點咯。

　　我希望你注意到，因為我基本確信我最近搞砸了一次程式設計面試。

　　我不會提那家公司的名字，因為這跟本文無關。我也不會公佈他們問的題目，因為那也同樣無關。那個題目並沒有 FizzBuzz 那麼簡單，但還是很簡單，是我下意識就能提出好幾種解決方式的那種問題。面試官否決了我偏好的方法（大概因為這個方法直接呼叫標準庫的函式而無法展示我能手動解決），於是我換了另一個方式。而我從記憶中重新構築這個方法的時候恰巧犯了一個小錯誤，因為我過於自信了並且想跟面試官聊其他的，於是我想著我都知道怎麼只靠記憶完成這個解決方案了，為啥不趕緊水過這個題目，然後談談我真正在乎的事呢。

　　順便一提，我出了一個小筆誤，就是我給錯誤的迴圈變數加了值。單字母的變數名很糟糕，即使是在你為了敷衍面試官而寫的傻瓜程式裡；再說白一點，程式碼能跑起來，但是結果是錯誤的。

　　而當程式跑完然後吐出錯誤的結果時，我全部的自信都蕩然無存，內心OS：“我的個天！為啥不對！我應該知道的呀”，然後我一邊瘋狂除錯，一邊嘗試向面試官解釋我的做法並且回答他們的問題，一邊讀程式碼、看結果、加 debug 語句來檢視中間值，然後整個氣氛是：「哦！提醒一下，這會決定你是否能得到心儀的工作，所以別有任何負擔哦」。所以雖然我修改好了，但是用了比正常更多的時間，這讓我想到我是不是可能會變成 Atwood 風格的失敗招聘故事的新事例。“沒錯，有個擁有十年經驗的人，所謂‘專家’，通過了前兩輪電面，結果他居然連這個超級簡單的函式都不會寫，還花了九牛二虎之力來找到自己的錯誤。用這題當過濾器真是爽歪歪！”

　　如果你曾經在一輪技術面試之後感覺糟糕，如果你曾經感覺你徹底失敗，是個廢物，不該獲得任何職位，只想住到遠離計算機、技術和那些讓你產生這種情緒的招聘流程的話：我真希望我能說一切正在好轉。我能說的是，你並不是一個人。我自身的傲慢和想要趕緊完事然後往下繼續的不耐煩，是我在那次面試失敗的主因。

　　但是那並不會讓最終的結果容易接受，也大概不會讓這種面試變成公司有力的工具；這些面試似乎就是因為它們自身的屬性而無法避免地會擠走合格的候選人。也就是說：缺乏經驗的應聘者更有可能缺乏自信而大腦一片空白；或者花費太多力氣來想出驚豔面試官的奇招，以至於最終垂死掙扎，看著無能；而有經驗的應聘者很可能（我就是）把這種面試看成煩人的形式主義，只想越快搞定越好（約時間進行程式設計面試的時候，我甚至還跟招聘方開玩笑說我至少能用六種語言寫 FizzBuzz，所以他們就直接告訴我想要哪種吧），面試結果只會符合古希臘人教育我們對於過分自信的期望。

　　而作為應聘者/候選人，這種面試更是爛。壓力太大和缺乏容錯空間，總是會讓人感覺身體不適。程式設計面試對精神的虐待也同樣糟糕。這真的是一個簡單的“來證明你會寫 for 迴圈吧”的題目嗎？還是說這是一道藏著面試官想讓你發現並闡述的深層問題的陷阱題？這真的只是在考察基本的程式設計技巧嗎？會不會有一些知名的演算法或技巧，而你沒有的 CS 學位早就會讓你滾瓜爛熟，甚至能作為軟體共濟會的接頭暗號？你是不是應該展示你精通這個語言和工具，還是說他們想你開口說出心中所想，來展示你可以好好分析這個問題？如果你能在 A 線詩歌裡面藏頭打出“FizzBuzz”，面試官會不會對你印象更好？

　　這些念頭會全程縈繞在你的腦海。他們會使你麻痺，抽空你的自信和思考能力，然後讓你看上去完全不勝任。但是 $大公司 就是這麼幹的，他們又大又有錢又成功，所以其他人也會跟著做，留下一片大腦麻痺、毫無自信、猶豫再三再四再七十四的殭屍程式設計師，他們只會語氣平平大聲喊“超出遞迴最大深度”，而那些公司只會全程抱怨為什麼就是找不到人才，然後麻煩誰能清理一下這些殭屍嗎？

　　一切都很爛

　　我曾多次處在招聘雙方的處境，我也經歷過這個欣欣向榮的軟體行業的各個階段的面試（我似乎平均每五年就要找一輪工作，這讓我對各個階段都有一些有趣的印象）。而我從中學到的只是我們幹得太糟糕了。科學哲學（我在學校學過一點）有個很有名的“劃界問題”：如何區分真正的科學，和那些用 看起來是正經科學的字眼 包裝起來的偽科學。這個問題，至今仍沒有什麼靈丹妙藥。

　　軟體開發也面臨著劃界問題，但我們的問題有點不同：我們需要知道的不僅僅是誰已經會寫程式碼，還要知道寫得多好，而在那些還不會寫的有志之士當中，他們還差多少，還需要多少幫助才能做到（換言之，不僅僅是“我們可以聘用誰”，還有“高低職位分別可以聘用誰”，以及“我們可以招哪個實習生然後給他推薦好的培訓日後再聘用他”）。這邊也沒有靈丹妙藥；如果存在的話，我們早就找到了，因為很多天才都花了大量的時間在尋找它。

　　至今為止，我發現有用的做法總會在其他時候失靈。那包含了審查 GitHub 或其他類似的東西來評估能力；用人際關係和介紹信來找出已經證明自己的人；用對話形式、交換人生故事的面試（也就是面試官和應聘者聊一些看過做過的事，還有他們解決問題的方式）；程式設計面試；“關鍵詞”面試（我參加過一次面試，目標真的就只是看應聘者有沒有“說出關鍵詞”，來看他們是不是真的熟悉這個領域）；高壓面試；低壓面試；短合同觀察期；實習生返聘計劃；團隊融入面試；結對程式設計；黑客馬拉松；一對一面試；多對一面試；你再隨便想一個吧，肯定被使用過了而且成功率最高只有一半。

　　因此這對僱主很不利。我應該提到過對應聘者來說也很爛了吧？太多流程都嚴重有失公允，然後由於面試官和應聘者立場上的鴻溝，這些流程更加糟糕。有時候你甚至不知道有人在評估你（特別是當流程第一環節就是 GitHub 主頁篩選的時候），而且被找來主管技術/程式設計面試的人，經常把這看作一件浪費時間的苦差事，他們不會花時間準備，甚至不會了解一下應聘者，甚至不知道他們來面試什麼崗位（我遭遇過好幾次這樣的情況，我敢說一個連應聘者的簡歷都懶得看的面試官，是不會讓應聘者想要加入他們的）。除此之外，就算是最好的技術面試，也有很強的對抗性因素，這也特別讓人不舒服。

　　但是作為應聘者，不在面試前惡補公司的技術結構，可能加上一些技術面經，包含排序、搜搜演算法和怎麼計算費米對芝加哥鋼琴調音師人數的估計演算法的複雜度。應聘者事先不做準備，那就太離譜了。因為就算面試官可以完全不瞭解應聘者和那個職位，應聘者必須做足功夫，說不定面試官真的會問調音師那道題。

　　我知道理論上這種非人性化和脫節，是太多人申請技術崗位的副作用；讓流程人性化和處理所有申請，這兩者不可兼得。但這肯定會讓求職者充滿苦澀。我真希望，我能感覺我是作為一個將要成為同事的人在接受面試，而不是由可替換齒輪 #7365 作為可替換齒輪 #9540 崗位的面試官，然後由於更多的可替換齒輪在排隊面試而時間有限。而且如果你是最早的五千個齒輪，你只能獲得股權。

　　這完全沒考慮到人與人的差別，有些人擅長應對形式化的面試，而有些人並不擅長。（這兩點都看不出，這個人會在真正的工作環境做得如何；如果看得出的話，那某種程度上，這些面試技巧可以用來申請我並不想要的那種職位。）

　　那我們該怎麼做?

　　老實說，我根本不知道。技術招聘對各方來說都很爛，而且沒有簡單的解決方式。甚至都沒有能讓我們撐到解決方式出爐的權宜之計。不過我還是會提一些東西，只因為洋洋灑灑寫 3,000 字吐槽卻不提出建議，看上去太糟糕了。

　　一旦一家公司大到分離出專門的招聘團隊或部門時，HR 就會變成應聘者和現有員工雙方的痛點。我的意思是應聘者面對的很多招聘者，他們自己都只是剛剛找到工作。這就降低了他們的反應能力以及說服其他人這家公司值得加入的能力，拖慢了整個招聘流程。如果你的招聘團隊像旋轉門一樣很多人進進出出，你就該找出原因並解決問題，保證你放在那裡的人真的瞭解公司，瞭解你在找的人才，別讓任何一方（應聘者或需要信任的團隊）空等。說的就是你，上次電話一個禮拜了都還沒傳送“招聘進度”郵件的某某公司。

　　當你依靠開發者進行面試時，請負責任地排好班。你已經在佔用他們的時間，而且強迫他們切換注意力了；確保他們有足夠的時間來不僅僅是打一個 30 分鐘的電話，還要瀏覽應聘者的簡歷、GitHub 等，瞭解他們主管的職位的細節。跟一個能說出“我發現你做了/貢獻了（專案）”並且能把這個專案跟公司和職位扯上關係的人交談雖然只是一個小美好，但是小美好可以產生深遠的影響。還有要確保面試官想要當面試官；我能判斷出對方很明顯只想面試趕緊結束然後回到“巨集圖大計”，這很糟糕。

　　別搞程式設計面試，如果可以的話，看看應聘者寫過的程式碼，或者向他們描述你最近遇到的一個小 bug，然後問他們會怎麼解決。如果你能相處跟職位相關的問題那就更好了。讓應聘者選擇在電話上解釋，或者寫下來發郵件給你。我認識一些能寫出神級程式碼卻沒辦法開口好好解釋的人，我也認識擅長開口解釋卻害怕寫哪怕只是零散程式碼的人；除非你的職位要求特別的演說/寫作能力，不然就別偏向任何一邊。如果你必須進行程式設計面試，把用時和壓力控制在合理的範圍——你家的開發者都未必能在 30 分鐘內在面對陌生人電話聽寫軟體輸出的情況下解決 bug，那就彆強迫應聘者了。還有，你可以讓討厭面試的開發者改變心態：“這不是面試，是程式碼評估”。所有人都能把程式碼評估“電解”成 Agile™ 和 Lean® 等等的關鍵詞。程式碼評估有開發者渴望的元素！

　　在所有這些之上最重要的是，請人性化一些。我們不是機器；我們只是讓機器做有趣的事情。有時候我們甚至可以讓它們做正確而有趣的事情。但我們終究是人類，而現在的招聘流程存在鴻溝般嚴重的人性化缺失。對人類人性化一些吧，其他所有事情都會輕鬆很多。