面試官18個月觀察：47%新人能跑通代碼卻講不清原理

過去18個月，北美技術招聘圈流傳一個詭異現象：簡歷上的項目越來越漂亮，面試現場的表現卻越來越抽象。

不是那種緊張導致的結巴，而是根本性的認知斷層——候選人能寫出跑通的代碼，被追問"這段為什么這樣寫"時，卻像突然被拔掉了電源。

機制一：代碼能跑，但人不會了

AI編程工具的普及，把"寫出功能"的門檻砍到了腳踝。GitHub Copilot、Cursor這類工具讓新手幾小時內就能攢出一個像模像樣的項目，放到簡歷上足夠唬人。

問題在于，這個生產過程里，人扮演的角色越來越像策展人而非創作者。選哪個方案、調哪行參數，決策權交給了算法。候選人提交的作品集確實"functional"，但技術面試要的不是這個——它要的是你面對白板時，能從第一性原理推導出解法。

一位Google招聘委員會成員描述這種落差：「他們帶來的項目看著很完整，但問'如果輸入是空數組會怎樣'，眼神就空了。」

機制二：功能導向正在制造"紙面工程師"

教育體系對AI工具的擁抱，無意中強化了一種危險的學習路徑：以輸出為唯一目標，跳過中間的掙扎與試錯。

傳統編程學習的價值，很大程度上來自那些卡住的夜晚——調試時被迫逐行追蹤變量，重構時親手把面條代碼拆成模塊，這些痛苦才是理解的錨點。AI工具把痛苦外包了，理解也就成了無根之木。

招聘現場的反饋很殘酷：候選人能解釋"這段代碼做什么"，但解釋不了"為什么選這個數據結構"或"時間復雜度怎么來的"。這種"表面熟練"在高壓面試中迅速崩盤，因為追問一旦超出工具生成的代碼邊界，知識體系就出現斷層。

機制三：技術面試成了壓力測試的照妖鏡

面試設計的初衷，本就是模擬真實開發中無法Google、無法求助AI的場景。它刻意制造認知負荷，逼候選人展示無法被工具替代的思維能力。

但AI教育培養出的開發者，在這種環境下暴露出一個結構性缺陷：他們的知識是"調用型"而非"生成型"。能識別好代碼，但寫不出；能跑通測試用例，但造不出測試用例。面試中的白板環節、邊界條件追問、復雜度分析，恰好戳中這些軟肋。

更麻煩的是系統性風險。如果招聘標準被迫下調以填補headcount，企業最終雇用的是一群"代碼搬運工"——日常開發或許能應付，但生產環境出故障時，缺乏從根因定位到修復的完整能力鏈條。

一位Meta工程總監的觀察很直白：「我們不是在招會按Tab鍵的人，是在招系統出問題時能扛住的人。」

裂縫正在擴大

這個趨勢沒有自限機制。AI工具在進化，教育體系的調整卻滯后得多。當新一代開發者批量進入市場，招聘方被迫在"能干活"和"真懂行"之間做越來越艱難的權衡。

已有公司在調整策略：延長試用期、增加系統設計輪次、把"解釋你三個月前寫的代碼"變成固定環節。但這些是補丁，不是解法。

根本矛盾在于，AI輔助編程和基礎能力培養之間，還沒有找到穩定的共生模式。工具越強大，新手越難抵抗"先跑起來再說"的誘惑——而那個"再說"，往往永遠不會來。

教育者和行業領袖現在面臨一個選擇：是讓AI成為腳手架，還是讓它變成拐杖？這個選擇的結果，將決定未來幾年軟件行業的平均故障率和凌晨三點的on-call頻率。

一位參與多輪校招的Netflix工程師留下一個未解的問題：「如果五年后，AI能生成并維護90%的代碼，我們面試時到底該考什么？」