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

　　隨著軟件開發行業正發生整體轉變，我們越來越依賴 Copilot 和 GPT 等 AI 工具來生成代碼、提高生產力，所以必然要據此調整對人才的甄選思路。

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

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

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

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

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

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

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

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

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

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

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

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

　　在面試中強調代碼審查的八大理由

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

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

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

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

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

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

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

　　這種方式更適合評估那些負責理解代碼、而非直接編寫代碼的技術角色，包括工程經理、架構師和技術支持人員等。

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

　　具體策略

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

　　“道法自然”

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

　　找出 Bug

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

　　重構與重新設計

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

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

　　以性能為導向

　　找點最近剛剛做過性能修復的代碼，看看受試者能否發現導致一段代碼運行緩慢的原因，包括他們能否提出算法、替代設計或修復思路以提高代碼性能。

　　具體包括應用程序所需執行的現有 SQL DDL 架構及常見自然語言查詢�；蛘邉h除索引定義，看看受試者能否提出索引或替代設計來提高性能。

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

　　關注測試

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

　　安全嗅覺

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

　　最佳實踐

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

　　寫在最后

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

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

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

　　用代碼審查替代 Leetcode 作為面試主體，不僅能幫助團隊更好地對受試者做整體分析，更能強調其核心技能和團隊協作表現等現實指標，為行業內軟件構建范式的整體轉變做好準備。