本文來自于微信公眾號 InfoQ(ID:infoqchina)，作者:核子可樂、Tina。

　　隨著軟件開發(fā)行業(yè)正發(fā)生整體轉(zhuǎn)變，我們越來越依賴 Copilot 和 GPT 等 AI 工具來生成代碼、提高生產(chǎn)力，所以必然要據(jù)此調(diào)整對人才的甄選思路。

　　經(jīng)驗豐富的工程師也會過不了“編程面試”，特別是在沒有花時間去復(fù)習(xí)Leetcode習(xí)題的情況下�，F(xiàn)在很多人已經(jīng)忘記了最初為什么面試時要做 Leetcode 題。實際上，Leetcode 來源于谷歌的一項面試研究，最初谷歌想確定最聰明的候選人通常也是最擅長算法的。谷歌聘用的重點是智商而非純粹的編程技能，因此這導(dǎo)致他們的面試主要側(cè)重于算法問題。后來，其他公司也效仿了谷歌的招聘模式，普遍開始問算法編程問題，逐漸整個行業(yè)的面試都圍繞算法編程，而谷歌最初的研究目的逐漸被大家忽視。

　　算法雖然重要，但在面試場景下卻是可以通過死記硬背的刷題方式來解決的，而且對于大多數(shù)軟件公司來說，工作很大程度上是寫在 CRUD 業(yè)務(wù)。特別到了現(xiàn)在，Copilot 和其他一些 GPT 編程工具已經(jīng)被開發(fā)者們納入到日常工作中，過分強調(diào)“Leetcode 能力”似乎也有一些不合時宜了。

　　花時間在 Leetcode 上練習(xí)一下常見的面試問題，然后依靠刷題進(jìn)入大廠，這就是企業(yè)在為工程團(tuán)隊招聘新成員時想看到的效果嗎?這事也要從正反兩面來看:

　　雖然解決這些復(fù)雜的算法問題確實既有益、又有趣，但現(xiàn)實情況是，對于大多數(shù)高效開發(fā)者來說，我們的大部分編程工作跟這些毫不相干。也就是所謂“面試造火箭，上班打螺絲”。

　　大多數(shù)人在日常解決比較困難的編碼問題時，主要會參考 Stack Overflow、技術(shù)文檔和其他在線資源。我們會跟同行聊天，并將不同的思路寫在白板上。而隨著 AI 編碼工具的爆發(fā)式增長，許多開發(fā)者已經(jīng)開始將 Copilot 和 ChatGPT 納入自己的工作流程。

　　對于大部分復(fù)雜問題，我們可能只需要處理一到兩次，之后就能反復(fù)使用。所以說編寫這種高度抽象的復(fù)雜代碼不能說沒有意義，只能說意義有限。

　　現(xiàn)在的面試習(xí)慣會創(chuàng)造出一種人為的情境，給開發(fā)者增添了壓力。其實很多朋友都不喜歡在他人的注視下寫代碼。在現(xiàn)實生活中，也很少有人會給自己的編碼任務(wù)設(shè)置固定的時間。面對難題，我們可能去散會步、跟同事交流、研究算法、先構(gòu)建個小型實驗代碼庫等。老實說，“心流”狀態(tài)下的開發(fā)工作才是最富成效的，而壓力面試顯然跟這種狀態(tài)沒有一毛錢關(guān)系。

　　開發(fā)者會在自己熟悉的環(huán)境中使用自己喜愛的工具進(jìn)行編碼。使用不熟悉的工具反而讓人迷失方向，并進(jìn)一步增加他人注入下做開發(fā)的壓力和焦慮。

　　總而言之，這種面試方法可能是在衡量錯誤的指標(biāo)，所關(guān)注的東西對于候選人有效融入團(tuán)隊基本沒什么幫助。

　　不僅如此，隨著團(tuán)隊越來越依賴 AI 生成的代碼(無論是 Copilot 還是 GPT)來提高生產(chǎn)力，如今快速理解代碼并在更廣泛的應(yīng)用 / 場景上下文中識別細(xì)微缺陷，才是最具價值的關(guān)鍵能力。

　　GPT 為 Leetcode 中常見的 N-Queens 問題生成的答案。

　　因此現(xiàn)在已經(jīng)有面試改換了重點，轉(zhuǎn)向了審查代碼、而非編寫代碼。這無疑是個重要啟示，讓我們意識到代碼審查開始成為評估軟件工程師的更好方法，而不再是專注于編碼練習(xí)。

　　在面試中強調(diào)代碼審查的八大理由

　　代碼審查之所以能夠在本質(zhì)上提高面試效果，主要基于以下幾個原因:

　　在 AI 時代，由 AI 生成的代碼往往難以適應(yīng)性能、安全性和內(nèi)部最佳實踐等實際要求(在受監(jiān)管的行業(yè)中尤其突出)。在依賴這些零散生成的代碼時，開發(fā)者必須有能力在整體項目上下文內(nèi)有效評估代碼質(zhì)量、把握潛在風(fēng)險。

　　這種方式能更好地反映工程師——特別是高級職務(wù)——所從事的日常工作。從長遠(yuǎn)來看，向同事、特別是初級團(tuán)隊成員提供有效的指導(dǎo)和意見反饋，更有助于提升整體生產(chǎn)力與代碼編寫質(zhì)量。

　　這樣可以更好地反映受試者是否具備全面的推理、思考和溝通視角。換句話說，更好地把握受試者加入團(tuán)隊后的整體表現(xiàn)，對其技術(shù)經(jīng)驗進(jìn)行深入剖析。

　　代碼審查在本質(zhì)上更具協(xié)作性，而編寫代碼則往往是項比較孤立的工作(相信有不少開發(fā)者更傾向于在晚間一個人靜靜編寫代碼)。代碼審查也許更能反映受試者在團(tuán)隊中的工作狀態(tài)，所以效果可能優(yōu)于讓受試者直接解決技術(shù)難題。

　　代碼審查中包含更多主觀性因素，很多問題絕不是非黑即白。這就自然提供了更大的討論和解釋空間。由于不存在單一最優(yōu)解，代碼審查還讓我們有機會面對更多異常情況。面對5位受試者，我們可以獲得5種獨特的觀點;相比之下，以往的算法問題可能只對應(yīng)少數(shù)幾種最佳答案。

　　這種方式，也讓受試者更難通過生成式 AI 或者 Leetcode 刷題的方式作弊。

　　這種方式更適合評估那些負(fù)責(zé)理解代碼、而非直接編寫代碼的技術(shù)角色，包括工程經(jīng)理、架構(gòu)師和技術(shù)支持人員等。

　　這種方式能更好地反映受試者在初入團(tuán)隊后的表現(xiàn):通過閱讀代碼來學(xué)習(xí)現(xiàn)有系統(tǒng)。很明顯，考察這方面能力比衡量他們能否解決 N-Queens 問題更有實際意義。

　　具體策略

　　在代碼審查中，我們還可以將以下幾種策略搭配起來，借此衡量受試者的實際水平。這些策略的共同點在于，都更強調(diào)代碼審查能力、而非代碼編寫能力。換言之，重要的不是能否在特定時間之內(nèi)解決問題，而是能否適應(yīng)現(xiàn)有代碼庫中的零散內(nèi)容和團(tuán)隊遇到的實際挑戰(zhàn)。

　　“道法自然”

　　從實際代碼庫中提取那些有意義、重要且有趣的部分，將它們作為審查工作的具體場景。比如說數(shù)據(jù)訪問、異常處理、輸入處理等等，這些都是審查受試者能否適應(yīng)現(xiàn)有代碼庫，以及能否看懂、理解實際代碼資產(chǎn)的好辦法。

　　找出 Bug

　　故意引入一些邏輯缺陷或問題，看看受試者能不能順利發(fā)現(xiàn)。比如說要求他們找到并處理最近公司里剛剛修復(fù)掉的 bug，看他們能否發(fā)現(xiàn)根本原因、打算如何解決該缺陷，他們的方案跟實際修復(fù)之間有何不同等。

　　重構(gòu)與重新設(shè)計

　　可能公司剛剛對某些代碼進(jìn)行了重構(gòu)，或者正打算進(jìn)行重構(gòu)，這時候就可以將重構(gòu)前的代碼作為素材，考察受試者如何看待原有代碼、打算用什么策略規(guī)劃和實施重構(gòu)。另外，也可以詢問受試者能否確定為什么有必要進(jìn)行重構(gòu)，并評估他們所提出方法的復(fù)雜性。大家可能會驚訝地發(fā)現(xiàn)，這絕對是種考察技術(shù)能力的全新途徑、而且相當(dāng)有效!

　　如果受試者表現(xiàn)良好，就基本可以認(rèn)定他們能夠快速融入現(xiàn)有工作流程。

　　以性能為導(dǎo)向

　　找點最近剛剛做過性能修復(fù)的代碼，看看受試者能否發(fā)現(xiàn)導(dǎo)致一段代碼運行緩慢的原因，包括他們能否提出算法、替代設(shè)計或修復(fù)思路以提高代碼性能。

　　具體包括應(yīng)用程序所需執(zhí)行的現(xiàn)有 SQL DDL 架構(gòu)及常見自然語言查詢�；蛘邉h除索引定義，看看受試者能否提出索引或替代設(shè)計來提高性能。

　　不要詢問什么 Big-O 表示法的原理，而應(yīng)考察受試者能否真正發(fā)現(xiàn)數(shù)據(jù)訪問代碼中的那些 O(n^2) 代碼或 N+1問題!

　　關(guān)注測試

　　選擇一段代碼并匹配一組代碼單元測試，詢問這是否涵蓋了所有情況?還有哪些情況未能涵蓋?如何對單元測試做改進(jìn)?在即將到來的 AI 生成代碼時代，這種判斷力往往更加重要:理解領(lǐng)域空間和用例，以及如何編寫高覆蓋率單元測試(或者評估 AI 生成的單元測試的完整性)將成為一項關(guān)鍵技能。

　　安全嗅覺

　　選擇包含微妙安全缺陷的代碼，看看受試者能不能發(fā)現(xiàn)這些問題。不要單純詢問什么是 XSS 或者 SQL 注入攻擊，而是要看他們能否意識到當(dāng)前代碼缺乏對此類攻擊的保護(hù)機制。同樣的，隨著團(tuán)隊越來越多地依賴由 AI 生成的代碼，這種從生成代碼中發(fā)現(xiàn)潛在安全缺陷的能力將變得愈發(fā)重要。

　　最佳實踐

　　對于更高層級的職位，則應(yīng)考察他們能否把握最佳實踐，并借此與技術(shù)新人 / 直接下屬順暢溝通、傳授軟件開發(fā)經(jīng)驗。擁有這種能力，才是一名好的技術(shù)管理者。

　　寫在最后

　　在《平均的終結(jié):如何在崇尚標(biāo)準(zhǔn)化的世界中勝出》一書中，Todd Rose 寫道:幾乎任何有意義的人類特質(zhì)、尤其是天賦，總會包含多個維度。問題在于，當(dāng)我們試圖衡量一個人的才能時，卻經(jīng)常訴諸平均值，想要讓參差不齊的個體簡化為單一維度，例如標(biāo)準(zhǔn)化的考試分?jǐn)?shù)或者工作績效排名。

　　事實上，如果我們選擇狹隘的問題解決技能，那么最終得到的就只會是“平均”或者說平庸的候選人。他們只是在簡單學(xué)習(xí)并應(yīng)付這些考察維度，反而讓我們錯過許多真正能夠提升團(tuán)隊生產(chǎn)力的卓越人才。將代碼審查作為面試中的團(tuán)隊技能考察指標(biāo)，有助于更好地衡量受試者的整體技能水平，避免靠 Leetcode 刷題導(dǎo)致的“高分低能”問題。

　　隨著軟件開發(fā)行業(yè)正發(fā)生整體轉(zhuǎn)變，我們越來越依賴 Copilot 和 GPT 等 AI 工具來生成代碼、提高生產(chǎn)力，所以必然要據(jù)此調(diào)整對人才的甄選思路。機器人就能解決的算法難題，在考察受試者時應(yīng)當(dāng)占據(jù)更低的比例和權(quán)重。相反，未來的核心技能也許是閱讀并審查代碼是否正確、貫徹最佳實踐并保障安全性等能力。

　　用代碼審查替代 Leetcode 作為面試主體，不僅能幫助團(tuán)隊更好地對受試者做整體分析，更能強調(diào)其核心技能和團(tuán)隊協(xié)作表現(xiàn)等現(xiàn)實指標(biāo)，為行業(yè)內(nèi)軟件構(gòu)建范式的整體轉(zhuǎn)變做好準(zhǔn)備。