測定程序員的代碼基因
上個月，在負(fù)責(zé)技術(shù)晉升評審的過程中，有人認(rèn)為在評審過程中以述職講述為主，可能對某些比較擅長寫代碼而不擅于演講的同學(xué)不公平。而對于中級別的程序員技術(shù)晉升我們更傾向于篩選出擅長編程，而非僅僅是說得好的同學(xué)。
這個過程里面，存在四種情形：
- 代碼寫得好，也說得好
- 代碼寫得好，但說不出
- 代碼寫得不太行，但說得很好
- 兩者都不行
晉升篩選的目標(biāo)是選出 1 和 2 兩種，篩掉 3 和 4。這里面的挑戰(zhàn)在于，在采用述職答辯這種形式下，1 和 3 這兩種很難分辨，同時 2 和 4 也很難分辨。關(guān)鍵就在于如何識別并判斷代碼寫得好還是不好的問題，區(qū)分度的標(biāo)尺怎么定的問題。這個判斷問題在面試程序員時也存在，要不就先從「代碼面試」說起吧。
1
在我過去十年多一些的從業(yè)經(jīng)歷中，倒是面試過很多次，其中不乏面試寫代碼的。
剛畢業(yè)那年***次去面試，聊了沒幾句面試官就給了一張白紙和鉛筆，要求在紙上用 C 語言寫一個快速排序算法的實(shí)現(xiàn)。這次經(jīng)歷我記憶猶新，差不多半小時，我磕磕碰碰的寫了一個實(shí)現(xiàn)。在和面試官討論時，被指出了不少沒考慮到的情形和漏洞，后來的結(jié)果自然是沒能通過。
現(xiàn)在回想起來，在紙上編程真是一件很難受的事情。雖然五十年代的程序員基本都在紙上編程，那是因?yàn)槟菚r計(jì)算機(jī)的運(yùn)行成本很高。但面試時的紙上編程，一方面時間很有限，另一方面環(huán)境和氛圍比真正的編程要緊張不少。所以，我是不支持紙上編程這種形式的，它既不能讓候選人很好的發(fā)揮，另外一方面也可能沒有足夠的區(qū)分度。比如，像上面那樣寫一個著名的算法實(shí)現(xiàn)，背過和沒背過差別可以很大，但對真正的編程能力卻不足以區(qū)分。
后來，再有一次面試，被要求在白板上編程，我是拒絕的。只在白板上寫了思路，并沒有去寫細(xì)節(jié)的代碼實(shí)現(xiàn)，不過這次倒是通過了。
2
除了要求在紙上寫代碼的，也有公司會要求上機(jī)編程，我在工作一年多以后的***次跳槽就經(jīng)歷過這么一次。
***輪的面試以問答為主，但第二輪就直接給了一個題目，并分配了一臺電腦要求直接編程實(shí)現(xiàn)。題目并不算大，題目細(xì)節(jié)記不清了，大概記得是搭建一個 Web 應(yīng)用之類的，考察的更多是工程應(yīng)用能力，而非算法。
如今回想起來，其實(shí)就是判斷下實(shí)際的動手能力，看能不能干活。既不用和當(dāng)時一些外企偏愛的邏輯智力題較勁，也沒有讓人尷尬的紙上或白板編程環(huán)節(jié)。當(dāng)時面試的一家國企的軟件部門，還算比較務(wù)實(shí)，但對候選人的編程潛力和能力的要求真不高。
3
十多年前，大家都看那些跨國巨頭的軟件外企是怎么玩的，而今天，大家都看互聯(lián)網(wǎng)的巨頭是怎么玩的。
互聯(lián)網(wǎng)的巨頭標(biāo)桿當(dāng)然是 Google，但 Google 式的代碼能力面試槽點(diǎn)也是在網(wǎng)上被人噴的不行。比如，***的一條，Max Howell(Mac 下的著名軟件 Homebrew 的作者)在面試 Google 被拒后發(fā)過一條推文：
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% 的工程師都用你寫的軟件，但你不能在白板上翻轉(zhuǎn)二叉樹，所以滾蛋吧。)
正因如此，有人對 Google 面試的吐槽像下面這樣：
“谷歌式” 的面試真心是讓人又愛又恨，它糟糕透了：好的應(yīng)聘者落選，壞的應(yīng)聘者背背答案就能通過，呵呵。
好吧，上面這句吐槽，我就看到了恨，倒沒看到愛在哪里。《Coders at Works》一書(中文翻譯版叫《編程人生：15位軟件先驅(qū)訪談錄》)作者 Peter Seibel 曾采訪 Ken Thompson，一位傳奇程序員，C 語言和 Unix 的***、圖靈獎得主，他后來加入了 Google。
Peter Seibel: 我知道 Google 有一個規(guī)定，每個新員工都要在接受編程語言測試之后，才允許提交代碼。那就是說你也得考(你自己發(fā)明的)C 啰?
Thompson: 是啊，我還沒考呢。
Seibel: 你還沒考? 難道你還不能提交代碼嗎?
Thompson: 是啊，我不能提交代碼，不行...我只是還沒有去考試，還沒覺得有必要去考。
我猜這可能就是 Google 讓人“愛”的地方，Google 堅(jiān)持了一個對所有人一視同仁的標(biāo)準(zhǔn)和規(guī)則，即使這個標(biāo)準(zhǔn)有時執(zhí)行起來得出的結(jié)果讓人覺得非常不合理。
之前看過一個 Google 官方的代碼面試視頻，還考察寫代碼的過程。不用紙筆，而是請面試者打開一個協(xié)同工作的窗口，兩個人開同一個頁面。你改了什么，對方那邊是實(shí)時反應(yīng)的。這意味著你的面試官可以在另一端看到你是怎樣完成的這段代碼，你先寫了哪個變量，后寫了哪個方法，中途覺得哪里不對，做了怎樣的刪除，做了怎樣的修改...從開始到最終完成，面試官一清二楚。
這個過程其實(shí)比看最終的代碼更能直接反應(yīng)編程能力和思考過程，當(dāng)然這對候選人也會帶來一定的心理壓力。我覺著完全讓候選人不知情的情況去觀察可能更有利于真實(shí)水平的發(fā)揮，否則觀測本身就有可能影響結(jié)果。
4
另外，還有一家面試代碼能力很有特色的公司：ThoughtWorks。
它有一套與一般公司有點(diǎn)不一樣的面試流程。對候選人快速初步篩選后，會發(fā)給候選人一些題目，讓候選人選用其喜歡的任何語言來編程解決。候選人會提交代碼用于后續(xù)的面試過程使用，在后續(xù)面試過程中將與一位 ThoughtWorker 一起結(jié)對編程，擴(kuò)展最初的代碼，添加新的特性，在這個過程中來判斷候選人的代碼能力。
對，這的確是一個獨(dú)具特色的篩選程序員代碼能力的過程，比 Google 式的實(shí)時觀察更進(jìn)一步。但這種小眾的篩選過程都面臨一個問題：可操作性比較復(fù)雜，而且成本高。在面臨需要大規(guī)模的招聘和篩選(晉升)時，可操作性和成本就是一個繞不過的檻。
5
我大概就知道上面這些代碼面試方式，似乎沒有哪種讓人感覺特別***。
我們考察算法和數(shù)據(jù)結(jié)構(gòu)，是希望候選人能夠具備某些關(guān)于算法和數(shù)據(jù)結(jié)構(gòu)的知識，雖然這些知識很可能在實(shí)際工作中并不常用到。候選人也許會去提前學(xué)習(xí)和記住一些面經(jīng)中的內(nèi)容，這樣你就評估不了真實(shí)的解決問題的能力，而僅僅是看到了他重復(fù)回放算法的過程。一些開發(fā)人員可能會過于緊張，所以在面試或述職時失敗，但也許他們真得具備獨(dú)立解決問題的能力。而紙上或白板編程是不太好的，這種方式會導(dǎo)致代碼人員犯一些在工作中不一定會發(fā)生的錯誤。而且，這種方式又慢又痛苦。
我在想，理想情況下候選人應(yīng)該有一個全面的 GitHub “簡歷”。一份好的 GitHub “簡歷” 包括了你的代碼作品以及形成這個作品的過程記錄。而 GitHub commit log 天然具有這樣的過程跟蹤能力，所以我們就能從中看到很多東西。而一份不好的 GitHub “簡歷” 就是一次性的把作品提交上去后再也沒有變化，而不是借助 GitHub 的過程記錄來完成這個作品。
有了 GitHub 這個代碼簡歷，就能分析出一個程序員的「代碼基因」。代碼基因是我臨時聯(lián)想到的一個概念，因?yàn)樵谧x《信息簡史》這本書時，里面仔細(xì)分析了基因的本質(zhì)，在這里我覺得二者(代碼與基因)有相似點(diǎn)可以結(jié)合。
基因定義為一種遺傳的基本單位，是某種表現(xiàn)型差異的根源。在生物學(xué)里，它存在于一種物質(zhì)中，這種物質(zhì)是一種核酸，更具體點(diǎn)，就是脫氧核糖核酸(DNA)。薛定諤曾經(jīng)把基因想象為：某種遺傳特征的假想的物質(zhì)載體。一種微小的實(shí)體，卻包含了生物體的全部模式，并且這個模式還必須是個四維對象 —— 生物體本身是三維結(jié)構(gòu)，再加上從胚胎到成年的每個發(fā)育階段演變的時間維度。
所以，這就是為什么要具有過程記錄能力的 GitHub “簡歷”，它才擁有時間這個維度，一個代碼作品從無到有的演變過程全部記錄了下來。通過這樣的“簡歷”，我們就可以針對一些代碼的設(shè)計(jì)演變?nèi)枂栴}，去測定程序員的代碼基因。如果我們大量去讀過一些著名開源軟件的代碼，就會發(fā)現(xiàn)一些好代碼中不僅僅體現(xiàn)了規(guī)范性，還體現(xiàn)了特有程序員的「代碼基因」所形成的根本性的表現(xiàn)差異。
可惜的是，測定「代碼基因」依然是無法規(guī)?；姆绞?，更何況很多程序員根本沒有一份合格的 Github “簡歷”。
【本文是51CTO專欄作者胡峰的原創(chuàng)文章，轉(zhuǎn)載請聯(lián)系作者本人獲取授權(quán)】
