上個月愉老，在負責技術晉升評審的過程中，有人認為在評審過程中以述職講述為主，可能對某些比較擅長寫代碼而不擅于演講的同學不公平珊蟀。而對于中級別的程序員技術晉升我們更傾向于篩選出擅長編程，而非僅僅是說得好的同學外驱。
這個過程里面育灸，存在四種情形：
代碼寫得好，也說得好
代碼寫得好昵宇，但說不出
代碼寫得不太行磅崭，但說得很好
兩者都不行
晉升篩選的目標是選出 1 和 2 兩種，篩掉 3 和 4瓦哎。這里面的挑戰(zhàn)在于砸喻，在采用述職答辯這種形式下，1 和 3 這兩種很難分辨蒋譬，同時 2 和 4 也很難分辨割岛。關鍵就在于如何識別并判斷代碼寫得好還是不好的問題，區(qū)分度的標尺怎么定的問題犯助。這個判斷問題在面試程序員時也存在癣漆，要不就先從「代碼面試」說起吧。
1
在我過去十年多一些的從業(yè)經歷中剂买，倒是面試過很多次惠爽，其中不乏面試寫代碼的。
剛畢業(yè)那年第一次去面試瞬哼，聊了沒幾句面試官就給了一張白紙和鉛筆婚肆，要求在紙上用 C 語言寫一個快速排序算法的實現(xiàn)。這次經歷我記憶猶新坐慰，差不多半小時旬痹，我磕磕碰碰的寫了一個實現(xiàn)。在和面試官討論時，被指出了不少沒考慮到的情形和漏洞两残，后來的結果自然是沒能通過永毅。
現(xiàn)在回想起來，在紙上編程真是一件很難受的事情人弓。雖然五十年代的程序員基本都在紙上編程沼死，那是因為那時計算機的運行成本很高。但面試時的紙上編程崔赌，一方面時間很有限意蛀，另一方面環(huán)境和氛圍比真正的編程要緊張不少。所以健芭，我是不支持紙上編程這種形式的县钥，它既不能讓候選人很好的發(fā)揮，另外一方面也可能沒有足夠的區(qū)分度慈迈。比如若贮，像上面那樣寫一個著名的算法實現(xiàn)，背過和沒背過差別可以很大痒留，但對真正的編程能力卻不足以區(qū)分谴麦。
后來，再有一次面試伸头，被要求在白板上編程匾效，我是拒絕的。只在白板上寫了思路恤磷，并沒有去寫細節(jié)的代碼實現(xiàn)面哼，不過這次倒是通過了。
2
除了要求在紙上寫代碼的扫步，也有公司會要求上機編程精绎，我在工作一年多以后的第一次跳槽就經歷過這么一次。
第一輪的面試以問答為主锌妻，但第二輪就直接給了一個題目代乃，并分配了一臺電腦要求直接編程實現(xiàn)。題目并不算大仿粹，題目細節(jié)記不清了搁吓，大概記得是搭建一個 Web 應用之類的，考察的更多是工程應用能力吭历，而非算法堕仔。
如今回想起來，其實就是判斷下實際的動手能力晌区，看能不能干活摩骨。既不用和當時一些外企偏愛的邏輯智力題較勁通贞，也沒有讓人尷尬的紙上或白板編程環(huán)節(jié)。當時面試的一家國企的軟件部門恼五，還算比較務實昌罩，但對候選人的編程潛力和能力的要求真不高。
3
十多年前灾馒，大家都看那些跨國巨頭的軟件外企是怎么玩的茎用，而今天，大家都看互聯(lián)網的巨頭是怎么玩的睬罗。
互聯(lián)網的巨頭標桿當然是 Google轨功，但 Google 式的代碼能力面試槽點也是在網上被人噴的不行。比如容达，最著名的一條古涧，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% 的工程師都用你寫的軟件，但你不能在白板上翻轉二叉樹花盐，所以滾蛋吧羡滑。）
正因如此，有人對 Google 面試的吐槽像下面這樣：
“谷歌式” 的面試真心是讓人又愛又恨卒暂，它糟糕透了：好的應聘者落選啄栓，壞的應聘者背背答案就能通過娄帖，呵呵也祠。
好吧，上面這句吐槽近速，我就看到了恨诈嘿，倒沒看到愛在哪里∠鞔校《Coders at Works》一書（中文翻譯版叫《編程人生：15位軟件先驅訪談錄》）作者 Peter Seibel 曾采訪 Ken Thompson奖亚，一位傳奇程序員，C 語言和 Unix 的發(fā)明者析砸、圖靈獎得主昔字，他后來加入了 Google。
Peter Seibel: 我知道 Google 有一個規(guī)定首繁，每個新員工都要在接受編程語言測試之后，才允許提交代碼。那就是說你也得考（你自己發(fā)明的）C 啰镊绪？
Thompson: 是啊寒亥，我還沒考呢。
Seibel: 你還沒考胁塞？ 難道你還不能提交代碼嗎咏尝？
Thompson: 是啊压语，我不能提交代碼，不行…我只是還沒有去考試编检，還沒覺得有必要去考胎食。
我猜這可能就是 Google 讓人“愛”的地方，Google 堅持了一個對所有人一視同仁的標準和規(guī)則蒙谓，即使這個標準有時執(zhí)行起來得出的結果讓人覺得非常不合理斥季。
之前看過一個 Google 官方的代碼面試視頻，還考察寫代碼的過程累驮。不用紙筆酣倾，而是請面試者打開一個協(xié)同工作的窗口，兩個人開同一個頁面谤专。你改了什么躁锡，對方那邊是實時反應的。這意味著你的面試官可以在另一端看到你是怎樣完成的這段代碼置侍，你先寫了哪個變量映之，后寫了哪個方法，中途覺得哪里不對蜡坊，做了怎樣的刪除杠输，做了怎樣的修改…從開始到最終完成，面試官一清二楚秕衙。
這個過程其實比看最終的代碼更能直接反應編程能力和思考過程蠢甲，當然這對候選人也會帶來一定的心理壓力。我覺著完全讓候選人不知情的情況去觀察可能更有利于真實水平的發(fā)揮据忘，否則觀測本身就有可能影響結果鹦牛。
4
另外，還有一家面試代碼能力很有特色的公司：ThoughtWorks勇吊。
它有一套與一般公司有點不一樣的面試流程曼追。對候選人快速初步篩選后，會發(fā)給候選人一些題目汉规，讓候選人選用其喜歡的任何語言來編程解決礼殊。候選人會提交代碼用于后續(xù)的面試過程使用，在后續(xù)面試過程中將與一位 ThoughtWorker 一起結對編程针史，擴展最初的代碼晶伦，添加新的特性，在這個過程中來判斷候選人的代碼能力悟民。
對坝辫，這的確是一個獨具特色的篩選程序員代碼能力的過程，比 Google 式的實時觀察更進一步射亏。但這種小眾的篩選過程都面臨一個問題：可操作性比較復雜近忙，而且成本高竭业。在面臨需要大規(guī)模的招聘和篩選（晉升）時，可操作性和成本就是一個繞不過的檻及舍。
5
我大概就知道上面這些代碼面試方式未辆，似乎沒有哪種讓人感覺特別完美。
我們考察算法和數據結構锯玛，是希望候選人能夠具備某些關于算法和數據結構的知識咐柜，雖然這些知識很可能在實際工作中并不常用到。候選人也許會去提前學習和記住一些面經中的內容攘残，這樣你就評估不了真實的解決問題的能力拙友，而僅僅是看到了他重復回放算法的過程。一些開發(fā)人員可能會過于緊張歼郭，所以在面試或述職時失敗遗契，但也許他們真得具備獨立解決問題的能力。而紙上或白板編程是不太好的病曾，這種方式會導致代碼人員犯一些在工作中不一定會發(fā)生的錯誤牍蜂。而且，這種方式又慢又痛苦泰涂。
我在想鲫竞，理想情況下候選人應該有一個全面的 GitHub “簡歷”。一份好的 GitHub “簡歷” 包括了你的代碼作品以及形成這個作品的過程記錄逼蒙。而 GitHub commit log 天然具有這樣的過程跟蹤能力从绘，所以我們就能從中看到很多東西。而一份不好的 GitHub “簡歷” 就是一次性的把作品提交上去后再也沒有變化其做，而不是借助 GitHub 的過程記錄來完成這個作品顶考。
有了 GitHub 這個代碼簡歷赁还，就能分析出一個程序員的「代碼基因」妖泄。代碼基因是我臨時聯(lián)想到的一個概念，因為在讀《信息簡史》這本書時艘策，里面仔細分析了基因的本質蹈胡，在這里我覺得二者（代碼與基因）有相似點可以結合。
基因定義為一種遺傳的基本單位朋蔫，是某種表現(xiàn)型差異的根源罚渐。在生物學里，它存在于一種物質中驯妄，這種物質是一種核酸荷并，更具體點，就是脫氧核糖核酸（DNA）青扔。薛定諤曾經把基因想象為：某種遺傳特征的假想的物質載體源织。一種微小的實體翩伪，卻包含了生物體的全部模式，并且這個模式還必須是個四維對象 —— 生物體本身是三維結構谈息，再加上從胚胎到成年的每個發(fā)育階段演變的時間維度缘屹。
所以，這就是為什么要具有過程記錄能力的 GitHub “簡歷”侠仇，它才擁有時間這個維度轻姿，一個代碼作品從無到有的演變過程全部記錄了下來。通過這樣的“簡歷”逻炊，我們就可以針對一些代碼的設計演變去問問題互亮，去測定程序員的代碼基因。如果我們大量去讀過一些著名開源軟件的代碼余素，就會發(fā)現(xiàn)一些好代碼中不僅僅體現(xiàn)了規(guī)范性胳挎，還體現(xiàn)了特有程序員的「代碼基因」所形成的根本性的表現(xiàn)差異。
可惜的是溺森，測定「代碼基因」依然是無法規(guī)哪脚溃化的方式，更何況很多程序員根本沒有一份合格的 Github “簡歷”屏积。
…
如果用像《中國好聲音》這樣的唱歌比賽來做個類比医窿，一份合格的 Github “簡歷” 達成了基本的技能要求。高辨識度的「代碼基因」達成了音色的要求炊林，而實際在《好聲音》中評委大部分的轉身都是因為音色而轉的姥卢。
兩個同樣品質的東西，識別成本低的渣聚，通常會勝出独榴。
