大公司是如何評定程序員的能力的

上個月，在負責技術晉陞評審的過程中，有人認為在評審過程中以述職講述為主，可能對某些比較擅長寫代碼而不擅於演講的同學不公平。而對於中級別的程序員技術晉陞我們更傾向於篩選出擅長編程，而非僅僅是說得好的同學。

這個過程裡面，存在四種情形：

代碼寫得好，也說得好

代碼寫得好，但說不出

代碼寫得不太行，但說得很好

兩者都不行

晉陞篩選的目標是選出 1 和 2 兩種，篩掉 3 和 4。這裡面的挑戰在於，在採用述職答辯這種形式下，1 和 3 這兩種很難分辨，同時 2 和 4 也很難分辨。關鍵就在於如何識別並判斷代碼寫得好還是不好的問題，區分度的標尺怎麼定的問題。這個判斷問題在面試程序員時也存在，要不就先從「代碼面試」說起吧。

1

在我過去十年多一些的從業經歷中，倒是面試過很多次，其中不乏面試寫代碼的。

剛畢業那年第一次去面試，聊了沒幾句面試官就給了一張白紙和鉛筆，要求在紙上用 C 語言寫一個快速排序演算法的實現。這次經歷我記憶猶新，差不多半小時，我磕磕碰碰的寫了一個實現。在和面試官討論時，被指出了不少沒考慮到的情形和漏洞，後來的結果自然是沒能通過。

現在回想起來，在紙上編程真是一件很難受的事情。雖然五十年代的程序員基本都在紙上編程，那是因為那時計算機的運行成本很高。但面試時的紙上編程，一方面時間很有限，另一方面環境和氛圍比真正的編程要緊張不少。所以，我是不支持紙上編程這種形式的，它既不能讓候選人很好的發揮，另外一方面也可能沒有足夠的區分度。比如，像上面那樣寫一個著名的演算法實現，背過和沒背過差別可以很大，但對真正的編程能力卻不足以區分。

後來，再有一次面試，被要求在白板上編程，我是拒絕的。只在白板上寫了思路，並沒有去寫細節的代碼實現，不過這次倒是通過了。

2

除了要求在紙上寫代碼的，也有公司會要求上機編程，我在工作一年多以後的第一次跳槽就經歷過這麼一次。

第一輪的面試以問答為主，但第二輪就直接給了一個題目，並分配了一台電腦要求直接編程實現。題目並不算大，題目細節記不清了，大概記得是搭建一個 Web 應用之類的，考察的更多是工程應用能力，而非演算法。

如今回想起來，其實就是判斷下實際的動手能力，看能不能幹活。既不用和當時一些外企偏愛的邏輯智力題較勁，也沒有讓人尷尬的紙上或白板編程環節。當時面試的一家國企的軟體部門，還算比較務實，但對候選人的編程潛力和能力的要求真不高。

3

十多年前，大家都看那些跨國巨頭的軟體外企是怎麼玩的，而今天，大家都看互聯網的巨頭是怎麼玩的。

互聯網的巨頭標杆當然是 Google，但 Google 式的代碼能力面試槽點也是在網上被人噴的不行。比如，最著名的一條，Max Howell（Mac 下的著名軟體 Homebrew 的作者）在面試 Google 被拒后發過一條推文：

Google: 90% of our engineers use the software you wrote(Homebrew), but you can』t invert a binary tree on a whiteboard so fuck off.（我們 90% 的工程師都用你寫的軟體，但你不能在白板上翻轉二叉樹，所以滾蛋吧。）

正因如此，有人對 Google 面試的吐槽像下面這樣：

「谷歌式」 的面試真心是讓人又愛又恨，它糟糕透了：好的應聘者落選，壞的應聘者背背答案就能通過，呵呵。

好吧，上面這句吐槽，我就看到了恨，倒沒看到愛在哪裡。《Coders at Works》一書（中文翻譯版叫《編程人生：15位軟體先驅訪談錄》）作者 Peter Seibel 曾採訪 Ken Thompson，一位傳奇程序員，C 語言和 Unix 的發明者、圖靈獎得主，他後來加入了 Google。

Peter Seibel: 我知道 Google 有一個規定，每個新員工都要在接受編程語言測試之後，才允許提交代碼。那就是說你也得考（你自己發明的）C 啰？

Thompson: 是啊，我還沒考呢。

Seibel: 你還沒考？ 難道你還不能提交代碼嗎？

Thompson: 是啊，我不能提交代碼，不行…我只是還沒有去考試，還沒覺得有必要去考。

我猜這可能就是 Google 讓人「愛」的地方，Google 堅持了一個對所有人一視同仁的標準和規則，即使這個標準有時執行起來得出的結果讓人覺得非常不合理。

之前看過一個 Google 官方的代碼面試視頻，還考察寫代碼的過程。不用紙筆，而是請面試者打開一個協同工作的窗口，兩個人開同一個頁面。你改了什麼，對方那邊是實時反應的。這意味著你的面試官可以在另一端看到你是怎樣完成的這段代碼，你先寫了哪個變數，后寫了哪個方法，中途覺得哪裡不對，做了怎樣的刪除，做了怎樣的修改…從開始到最終完成，面試官一清二楚。

這個過程其實比看最終的代碼更能直接反應編程能力和思考過程，當然這對候選人也會帶來一定的心理壓力。我覺著完全讓候選人不知情的情況去觀察可能更有利於真實水平的發揮，否則觀測本身就有可能影響結果。

4

另外，還有一家面試代碼能力很有特色的公司：ThoughtWorks。

它有一套與一般公司有點不一樣的面試流程。對候選人快速初步篩選后，會發給候選人一些題目，讓候選人選用其喜歡的任何語言來編程解決。候選人會提交代碼用於後續的面試過程使用，在後續面試過程中將與一位 ThoughtWorker 一起結對編程，擴展最初的代碼，添加新的特性，在這個過程中來判斷候選人的代碼能力。

對，這的確是一個獨具特色的篩選程序員代碼能力的過程，比 Google 式的實時觀察更進一步。但這種小眾的篩選過程都面臨一個問題：可操作性比較複雜，而且成本高。在面臨需要大規模的招聘和篩選（晉陞）時，可操作性和成本就是一個繞不過的檻。

5

我大概就知道上面這些代碼面試方式，似乎沒有哪種讓人感覺特別完美。

我們考察演算法和數據結構，是希望候選人能夠具備某些關於演算法和數據結構的知識，雖然這些知識很可能在實際工作中並不常用到。候選人也許會去提前學習和記住一些面經中的內容，這樣你就評估不了真實的解決問題的能力，而僅僅是看到了他重複回放演算法的過程。一些開發人員可能會過於緊張，所以在面試或述職時失敗，但也許他們真得具備獨立解決問題的能力。而紙上或白板編程是不太好的，這種方式會導致代碼人員犯一些在工作中不一定會發生的錯誤。而且，這種方式又慢又痛苦。

我在想，理想情況下候選人應該有一個全面的 GitHub 「簡歷」。一份好的 GitHub 「簡歷」 包括了你的代碼作品以及形成這個作品的過程記錄。而 GitHub commit log 天然具有這樣的過程跟蹤能力，所以我們就能從中看到很多東西。而一份不好的 GitHub 「簡歷」 就是一次性的把作品提交上去后再也沒有變化，而不是藉助 GitHub 的過程記錄來完成這個作品。

有了 GitHub 這個代碼簡歷，就能分析出一個程序員的「代碼基因」。代碼基因是我臨時聯想到的一個概念，因為在讀《信息簡史》這本書時，裡面仔細分析了基因的本質，在這裡我覺得二者（代碼與基因）有相似點可以結合。

基因定義為一種遺傳的基本單位，是某種表現型差異的根源。在生物學里，它存在於一種物質中，這種物質是一種核酸，更具體點，就是脫氧核糖核酸（DNA）。薛定諤曾經把基因想象為：某種遺傳特徵的假想的物質載體。一種微小的實體，卻包含了生物體的全部模式，並且這個模式還必須是個四維對象 —— 生物體本身是三維結構，再加上從胚胎到成年的每個發育階段演變的時間維度。

所以，這就是為什麼要具有過程記錄能力的 GitHub 「簡歷」，它才擁有時間這個維度，一個代碼作品從無到有的演變過程全部記錄了下來。通過這樣的「簡歷」，我們就可以針對一些代碼的設計演變去問問題，去測定程序員的代碼基因。如果我們大量去讀過一些著名開源軟體的代碼，就會發現一些好代碼中不僅僅體現了規範性，還體現了特有程序員的「代碼基因」所形成的根本性的表現差異。

可惜的是，測定「代碼基因」依然是無法規模化的方式，更何況很多程序員根本沒有一份合格的 Github 「簡歷」。

…

如果用像《好聲音》這樣的唱歌比賽來做個類比，一份合格的 Github 「簡歷」 達成了基本的技能要求。高辨識度的「代碼基因」達成了音色的要求，而實際在《好聲音》中評委大部分的轉身都是因為音色而轉的。

兩個同樣品質的東西，識別成本低的，通常會勝出。