對於程序員的招聘問題，做爲軟件人的一些吐槽和建議

做爲軟件人，找工做有時候彷佛挺苦逼的。

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

可是應聘的一方（我如今所在的一方）也很苦逼。招聘方遇到的困境，也偏偏是形成痛苦流程的緣由。

教育很爛

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

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

那仍然是編程教學處在的階段：咱們知道本身須要程序員，而咱們沒有足夠多的程序員來寫代碼，更別說教出更多的程序員，因此這種死記硬背的現象普遍存在，這是由於這已是咱們如今力所能及的範圍。咱們只是但願咱們「教」出來的學生，會跑去看 Ruby on Rails 的教程，而後無心中看見 GitHub 的文檔，而後從中神奇地學會真正的軟件開發、架構和最佳規範。由於你們都明白，他們不可能在學校裏學會這些。

與此同時另外一方面，在我合做過的技術牛人當中，大多數根本沒有軟件工程和計算機科學的大學背景；不少人直到快上完學才第一次寫代碼（ 不要臉的偏見：我直到快大學畢業纔開始一般意義上的「編程」，我也是在畢業幾年後纔開始以此謀生）。不少真正厲害的人會被「計算機科學本科」這一條件過濾掉，這是招聘方不謹慎定下職位要求時會遇到的問題。即便招聘方費心加上「或擁有至關的經驗」，他們甚至也仍是被過濾掉，由於履歷上的學位彷佛就是招聘者和 HR 篩選推送給實際技術人員的求職者的第一條依據。

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

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

編程面試很爛

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

還有一方面的建議，若是你想輕鬆應對招聘，那就是把你的技術作的很牛逼，說到這裏給你們推薦一個架構交流學習羣：650385180，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系。還能領取免費的學習資源以及面試資料，相信對於已經工做和遇到技術瓶頸的碼友，在這個羣裏必定有你須要的內容。

詳細一點來講：我認識多個頂級人才被他們絕對勝任的職位給拒了，就由於這種編程面試。我傾向於把它們看做「問個謎語」風潮的最新版，這個環節當年因爲微軟的實施而流行一時，由於每家公司都想像微軟同樣又大又成功。如今，人們據說谷歌會進行編程面試，而且看到 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® 等等的關鍵詞。代碼評估有開發者渴望的元素！

在全部這些之上最重要的是，請人性化一些。咱們不是機器；咱們只是讓機器作有趣的事情。有時候咱們甚至可讓它們作正確而有趣的事情。但咱們終究是人類，而如今的招聘流程存在鴻溝般嚴重的人性化缺失。對人類人性化一些吧，其餘全部事情都會輕鬆不少。