結對程式設計面試：當你不是一個人時，他們在評什麼
預設的想法是：你正在被觀察。而實際上是：有人正在和你一起工作。幾乎所有能拿高分的做法，都是從意識到這個差別推出來的。
代價最大的那個誤會
多數應徵者一開始就假定面試官是一個剛好在場的裁判，所以正確的行為是表現能力、避免露出弱點。在這個假設下，你不會發問，因為發問看起來像不懂；你不會把思路講出來，因為還沒成形的想法看起來不夠精緻。
這剛好反了。在結對關卡裡，面試官在這四十分鐘是你的同事，而被衡量的是「和你一起工作是什麼感覺」。你的沉默不是沉穩——它代表這個人很難一起結對。
把對方用起來，而且要講出聲
結對給了你一樣單人關卡沒有的東西：一個已經知道答案的第二顆大腦。用得好的應徵者會一再做三件事。
他們在往上蓋之前先確認假設。「我假設這些 ID 是唯一的——這個前提成立嗎？」十秒鐘，省掉二十分鐘的錯誤方向。
他們提出選項，而不是瞎猜。「這裡我可以用 dict，也可以先排序。排序讀起來比較簡單，dict 比較快。你這邊比較在意哪一個？」這不是優柔寡斷——真正的工作就是這樣推進的。
他們接受提示而不爭辯。當對方說「如果串列是空的呢」，正確的回應不是辯護，而是「好問題」，再加一行防呆判斷。
打字不等於在工作
一個常見模式：應徵者穩穩打了三十分鐘，做出一個差點能跑的東西，然後收到負面回饋。面試官沒辦法跟上他的推理，所以除了成品之外沒有任何能評估的東西——而成品還沒做完。
相反的模式分數更高：程式碼更少、講解更多、檢查點更頻繁。「好，主要路徑處理完了。往下走之前——你要我處理格式錯誤的輸入，還是先把正常流程跑通就夠？」
這個問題是在真正做事。它表示你知道那種情況存在、它尊重時間，而且它讓面試官變成範圍決定的參與者，而不是旁觀者。
當你不同意對方時
這種情況會發生：面試官提出一個你覺得不對的做法。兩個極端都會扣分。默默照做，看起來像沒有主見。死咬不放，看起來像一個在團隊裡會讓人精疲力盡的人。
正確的做法是讓分歧變得具體又便宜。「我覺得輸入已經排好序的時候這裡會出問題——我可以拿那個案例試一下嗎？」這樣它就變成一個兩分鐘的實驗，而不是一場爭論，而且不管最後誰對，你都已經展示了你怎麼解決技術分歧。而這幾乎就是這道題真正在問的東西。
最後五分鐘
大多數應徵者把最後一段時間用來打得更快，希望能做完。沒做完是常態，而且很少致命——Thoughtworks 就直接告訴應徵者，他們不期待你交出完整的解答。沒解釋清楚才更糟。
更好的用法是：停下來，講清楚你現在在哪裡。「一般情況這樣是通的。如果再給我十分鐘，我會處理重複元素，做法是在這裡維護一個 seen 集合。」
你已經證明了你知道還缺什麼、也知道你會怎麼收尾——而這本來就是「做完」能證明的大部分東西。
他們在記什麼
結對關卡的面試官，通常照一張很短的評分表打分數，演算法只占其中一部分。公開評分標準的 Wise 列了三項：技術能力（程式碼清楚、好維護、有效率）、解決問題的方式，以及溝通與協作——包括你怎麼回應回饋。在別家一再出現的項目也差不多：溝通、協作、對回饋的處理，以及壓力下的除錯。
溝通不等於口才。它指的是：旁邊看著的人能不能預測你的下一步。能，你就是好讀懂的；不能，那你做的每一件事看起來都像在猜，就算其實不是。
對回饋的處理，是應徵者最低估的一項。面試官至少會打斷你一次，而且常常用的是你本來就知道的事。被記下來的是：這次打斷有沒有讓你變得防衛，以及對話多快回到工作本身。
除錯才是他們想看的部分
結對關卡幾乎一定會有一個時刻：程式碼沒有照你預期的方式跑。那一刻不是面試裡的挫折——它常常就是這一關的重點。
弱的版本是亂改，改到輸出看起來對為止。強的版本是在動任何東西之前先提出一個假設：「計數多了一，而迴圈是從零跑到 n 而且包含 n——我覺得問題出在邊界。我用 n 等於一來驗證一下。」
先講假設，再去驗證。兩句話，你展示的就是方法，而不是反射動作。
開場兩分鐘怎麼鋪
動手寫之前，出聲做三件事：複述一次問題、確認輸入的形狀、講出你打算先做什麼。這只要九十秒，卻會改變整場的基調。
它也給了面試官一個及早修正方向的機會。只要你留個口子，他們通常會用——第二分鐘的修正是免費的，同樣的修正發生在第二十分鐘，這一關就沒了。
如果題目本身模糊，那種模糊通常是故意的。針對它發問不是拖延；它就是第一個被考的東西。
這時候 Copilot 能做什麼
Interview Copilot 即時跟著這一關，對方一講完問題，就把結構放到你的螢幕上——這個問題真正在問什麼、哪個限制條件是關鍵、哪個取捨值得講出來。不是讓你照念的台詞：是一個支架，你用自己的話從上面講下去。
資料來源
以上資訊已在 2026 年 10 月 14 日對照這些頁面查證過。
FAQ
什麼是結對程式設計面試？
在這一關裡，你是和面試官一起做一個東西，而不是被人看著解謎題。對方可能也會寫程式、給方向，或扮演一位隊友。被評的是協作：你會不會解釋、會不會聽、提出的反對意見有沒有用，以及對方的意見有沒有被你吸收。
結對程式設計關卡到底在評什麼？
評的是「和你一起工作有沒有效率」。具體來說：你有沒有講出自己的意圖、有沒有用上搭檔給的東西、反對時是有理由，還是直接服從或無視，以及你寫的程式碼在即時狀態下別人看不看得懂。
如果我覺得面試官講錯了，該不該反對？
該，但要附上理由和替代方案。「這樣可行，不過它多掃了一遍串列——我們能不能一次走完？」就是他們想聽的回答。默默照做和默默推翻，兩種分數都很差。
我應該打多少程式碼？
比你以為的少。被評估的不是打字，而是決定。長時間安靜地打字不會產生任何證據，所以邊寫邊講你在寫什麼、為什麼這樣寫。