同一套面試，新的積木

程式面試，我當過很多次應徵者，也當過很多次面試官。這種面試終於開始改變了。Felix Rieseberg 是 Anthropic 的工程經理，他在〈Hunger Beats Tenure 〉裡寫到，他已經不做程式面試了，因為現在 Claude 解小型程式題比應徵者還強。Steve Yegge 的〈The Last Technical Interview 〉說整套流程是「一場大型射飛鏢遊戲」。很多公司正在重新設計面試流程，讓應徵者可以使用 AI。

讓應徵者用 AI 是簡單的部分。比較難的問題是，他們用了之後，你要衡量什麼。我認為答案是我們本來就知道怎麼做的事。

問題沒變

面試一直在測的，是對手邊資源的判斷力。我職涯的大部分時間裡，這些資源是資料結構、演算法、記憶體和時間複雜度。選雜湊表而不選串列，是一個判斷，面試官看的就是這個。

現在的資源是模型、上下文、token 和 session。用強的模型做規劃，再把實作交給比較便宜的模型，和選雜湊表是同一種決定。知道要給模型多少上下文、什麼時候該丟掉一個 session 重新開始，也是。問題沒變，變的是積木。

也就是說，你不需要發明一種新的面試。你可以沿用舊的面試，只是換上新的積木：像以前看人寫程式那樣，看他們用 LLM 開發軟體，然後評估他們怎麼運用模型、上下文和時間。

這也回應了另一個擔心：你測的會不會是下一季就過時的工具冷知識。工具每次改版都在變。判斷該把強模型用在哪裡，這件事不會變。這就是模型之上的那一層，也是會複利累積的部分。

尷尬的一小時

這件事我很早就確定了。那時 Cursor 的 Tab 自動完成是我編輯器裡最讓人興奮的功能，我還沒全面改用 agent 開發，而我用傳統的程式面試形式在面試應徵者。即使在那時候，看一個人手寫程式，也是我工作上做過最尷尬的事之一。面試中冒出問題時，我會去問 ChatGPT。每場面試一開始，我都會告訴應徵者，他們平常用什麼工具，這裡都可以用。有幾個人用了 ChatGPT，用得很生疏。大多數人沒用。

現在我做的每件事都經過 LLM：寫程式、寫文件、Slack、瀏覽器。我幾乎不讀程式碼了。回頭看，那些面試測的是一種當時已經在退場的工作方式。

這種形式一直讓我覺得不對勁。很多年前，遠在 Tab 自動完成出現之前，我應徵一個前端職位，被要求實作一個 JavaScript Promise。我知道這題想問什麼，就是看我懂不懂非同步 JavaScript。但 Promise 本來就存在，工作上也永遠不會有人叫我寫一個。

把題目變難

如果應徵者可以用模型，題目就得難很多。不該再有人去修五個單元測試，或在白板上實作 Promise。給他們一整個程式碼庫，和工作上真正會做的事：開發新功能、改善效能、寫文件、研究使用者怎麼用產品。這就是現在的工作，只是打字的是 LLM。

夠難的題目，也能測到大家擔心不看人寫程式之後會流失的東西。照單全收模型給的東西，你不可能把它做完。你得讀它做了什麼、發現哪裡錯了，再把它導回正軌。

Anthropic 已經在做類似的事。Tristan Hume 寫過他們的效能工程 take-home 作業 ，明確允許使用 AI。他們已經重新設計了三次，因為每個新的 Claude 模型都追上了應徵者。怎樣才算夠難，標準一直在移動。

讀 session

做出來的東西是結果，session 是證據。每一場用 LLM 進行的面試，都會留下應徵者工作過程的完整紀錄，這比白板給過任何人的都多。像審 pull request 一樣讀它，只是你審的是過程。

規劃。 他們有沒有要模型先提計畫、讀過、並提出反對意見？還是直接開始下 prompt，然後碰運氣？

模型選擇。 每件工作有沒有用對模型？用強的模型做規劃和探索，再把實作交給比較便宜的模型？給應徵者一份標明成本的模型清單，不然你根本看不到這一點。

上下文。 他們是一次就給模型對的上下文，還是同一件事解釋了五遍？token 用量是一個指標。把它當證據，不要當分數。在找到可行解法之前走進兩條死路，可能是好的判斷；如果應徵者知道 token 會被計分，他們會去最佳化 token，而不是解題。

驗證。 他們有沒有在改任何東西之前，先讓模型寫測試？有沒有讀 diff？模型寫出很慢的程式時，他們有沒有注意到，並要求它改好？只要有人開口，模型很會修效率差的程式碼。

補救。 模型走錯方向時，他們多快發現？是修正方向，還是開一個乾淨的 session 重來？

上線。 他們知不知道什麼時候該停？工作的一部分，就是說「這樣就夠好了」，把它上線，然後把接下來的五個改進寫成工單。

讀者。 他們有沒有分別寫給人看的文件和給 agent 看的文件，而且分得清楚哪個是哪個？給團隊的進度更新，和一份寫給 LLM、讓它在凌晨三點協助值班工程師的 runbook，讀起來不一樣。這些文字有多少是 AI 廢文，有多少明顯經過他們編修？

工作迴圈。 他們的迭代迴圈長什麼樣子？用了哪些 MCP server？他們是打字給模型，還是用說的？我現在大部分工作都用語音，快很多。

注意看，這份清單有多少是舊的面試。你拆解問題拆得好嗎？你會寫測試嗎？你在意效能嗎？你能說清楚自己做了什麼嗎？同樣的問題，新的積木。

還有一件事我會問，雖然一個小時內看不到：上線之後，有什麼在跑？我有排程任務，會清理幾個技術債很重的 repo 裡的死碼，還有一些會檢視我自己的 agent session，用來改進我的 harness。設定過這種維護的人，等於在告訴你他們怎麼看待這份工作。

如果 session 是 agent 工作的單位，它也是評估的正確單位。

闔上筆電

如果面試的一部分在看應徵者怎麼和模型合作，另一部分就應該看他們怎麼和人合作。闔上筆電，聊天。沒有模型幫忙找字眼，他們能把一個想法講得多清楚？他們能不能在沒有輔助的情況下，帶你走一遍他們的過程，而且讓你聽得懂？

系統設計介於兩者之間。它是技術題，但大部分是一場對話：在腦中掌握一個比語法更高層次的系統，再把它解釋給別人聽。它和以前一樣抽象，也是技術面試和行為面試交會的地方。

這部分比以前更重要。很長一段時間，大家心目中的優秀工程師，是那種深陷在程式碼裡、需要經理替他跟所有人溝通的人，因為任何打斷都要花好幾個小時在腦中重建整個程式碼庫。這種工程師還是會表現得很好。但如果工作就是說清楚你要什麼，對模型說，也對團隊說，那說清楚你要什麼，就是這份工作。

相信 vibe

接下來這段，可能會讓我這個面試官惹上麻煩：就算是技術面試，我評估的很大一部分是 vibe（感覺）。不管是資淺還是資深，我的決定很多來自對話本身。他們看起來有好奇心嗎？有熱情嗎？來之前有沒有想過這家公司在做什麼？聽起來很基本，但有相當多應徵者沒做到。

如果你能跟我聊一個小時，講你怎麼用 LLM 開發軟體、試過什麼、什麼壞了、你改了什麼，我需要知道的大部分就都知道了。如果有人程式寫得飛快，卻是個自以為了不起的混蛋，我不會錄用他。我得跟這個人共事。

「vibe」這個詞名聲不好，就跟 vibe coding 一樣。但 vibe 正是面試長久以來低估的東西，而它現在重要得多。Felix 叫它 hunger（渴望），我覺得我們講的是同一件事。

其中一部分，現在是願不願意採用新工具。AI 作為一門生意是否被高估，仍然有爭論。那是另一個問題。模型寫程式到底好不好，已經沒什麼好爭的了。一個面試表現出色、上班後卻什麼都手寫的應徵者，不會是你最有效率的工程師。

你還是需要一份評分表。別人問你怎麼招人時，「vibe 怎麼樣？」站不住腳。所以，把你的直覺在反應的東西寫下來：好奇心、熱情、有沒有做功課。那也是一份評分表。

別再裝了

如果一家公司今天還在面試時要我手寫程式，我會把它當成一個訊號：他們的流程過時了，而且過時的大概不只面試。要修正這件事，不需要什麼新的招募哲學。我們面試的一直是判斷力。變的只有積木。給應徵者工作上用的工具，把題目變難，其餘的面試照舊。

別再看人打字了。看他們工作。