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