現場寫程式面試：面試官到底在看什麼
現場寫程式面試，是你在別人注視下即時寫程式、而且一邊寫一邊講的那一關。關於它的建議大多在講之前幾週該刷什麼題，很少有人講那四十五分鐘本身——而準備程度相同的應徵者，偏偏就是在這四十五分鐘裡被拉開差距的。
這一關實際上長什麼樣子
你進入通話，面試官打開一個共用編輯器——CoderPad、CodeSignal、HackerRank，有時就是分享螢幕的 IDE——然後給你一道題。時間通常在三十到六十分鐘之間。你們看到的是同一個游標。能用到什麼工具，取決於平台和面試官的設定：例如 CoderPad 對多種語言提供自動完成，但面試官可以在設定裡關掉程式碼執行或它內建的 AI 助手。唯一不變的是，每一次停頓都有人在看。
它和線上程式測驗是兩回事。線上測驗衡量的是你交出的程式碼，這一關衡量的是你怎麼把它寫出來：會不會先問清楚再動手、能不能自己發現自己的錯誤、手在打鍵盤的時候還能不能把話講清楚。最終答案的比重，比大多數人以為的低得多。
評分表上真正的四項
大多數公司的評分表可以歸成四行：有沒有先理解題目再解題、思路是否合理而且講清楚了為什麼、能不能在不被一再提示的情況下寫出可以執行的程式碼、被追問時能不能講出取捨。
注意，四項裡只有一項跟程式碼有關。這也是為什麼一個安靜寫出完美解法的人，分數常常比不上一個把比較慢的解法講清楚、再自己最佳化掉的人——面試官只能替「傳到他那裡的東西」打分數。
開場兩分鐘，比重高得不合理
直覺會想馬上開始打，因為打字看起來像在進展，而沉默讓人心慌。這個直覺是錯的。開場應該用來複述題目、問清楚那一兩個真正會改變解法的問題——資料規模、有沒有排序、有沒有重複、能不能修改輸入——然後講出你打算用的思路和它的複雜度。
這九十秒換到三樣東西：你解的是對的那道題、面試官很早就拿到一個正面訊號，以及後面卡住時你有一個可以退回去的計畫。跳過這一步的人，常常到第二十分鐘才發現陣列本來就排序好了。
腦袋一片空白的時候
有時候就是什麼都想不出來。最可靠的脫困方式，是把最笨的解法講出來：「暴力解是兩兩列舉，平方複雜度。我先從這裡開始，再看哪裡在重複計算。」這不是認輸——這正是面試官希望聽到的，因為在一個講清楚的基準上做最佳化，是一個看得見、可以打分數的過程，而講出基準本身，通常就會露出可以最佳化的地方。
第二個辦法是拿一個具體的小例子。取四個元素手算一遍，邊算邊講。你需要的規律常常在例子裡看得到，在抽象層面則看不到。
第十五分鐘：發現思路是錯的
這一刻感覺像面試結束了。處理得好，它反而是你能發出的最強訊號之一——在別人指出之前先發現自己的錯誤，正是這份工作本身的內容。
要講得明確又簡短：「這樣走不通，一旦有重複元素，我的索引就亂了。我想換成以值為 key 的雜湊表。」不要一邊心存僥倖一邊繼續替已經死掉的思路打補丁，面試官看得到，而且會記成「無法自我評估」。也不要長篇大論地道歉。一句話指出問題，一句話講替代方案，然後繼續往下走。
那個看不到的 bug
壓力之下，人會把同樣的五行程式碼反覆讀，期待讀出不同的結果。要用機械的方式打斷這個循環：在你認為正確的位置把狀態印出來，看它是不是真的正確。面試裡幾乎所有的 bug 都是 off-by-one、初始值錯，或比較方向寫反，而這三種，在你把中間結構印出來的那一刻全都會現形。
除錯也要講出來。「這裡這個 map 我預期有三筆資料，我確認一下。」出聲除錯本身就是正面訊號，盯著螢幕不講話則不是。
沉默才是真正的失分項目
面試官要填的評分表，只能用傳到他那裡的資訊來填。思考三十秒完全沒問題——只要你替它貼個標籤：「讓我想一下要用什麼資料結構。」沒有標籤的沉默，會被記成「卡住了」。這是這份清單裡成本最低的習慣，也是被拒絕的應徵者身上最常缺少的那一個。
為什麼快捷鍵在這一關行不通
市面上大多數即時面試輔助工具靠快捷鍵驅動：聽到問題、按一下、拿到答案。這種模式預設你的手是空的。但在現場寫程式這一關，你的手不是空的——你在打字，面試官盯著你的編輯器，你伸手去按快捷鍵的那半秒，在這裡是看得到的，而在純對話的面試裡不會。
所以這是唯一一關：輔助要嘛自己運作，要嘛等於沒有。Interview Copilot 對每一個講完的問題自動回答，不用按任何鍵：它從通話聲音裡聽到面試官、判斷問題已經結束，然後在你繼續打字的同時，把答案的結構放到你的螢幕上。不是一段照念的稿子，而是機制、取捨，以及值得講出來的那個數字。
輔助在哪裡有用，在哪裡反而害人
即時工具真正有用的情境很窄：沒聽清楚的問題、明明知道卻一時想不起來的函式庫函式簽名，以及這一關不是用母語進行時的術語。這些都是「提取」問題，而高壓下的提取困難，是一種真實存在、跟工程能力無關的額外負擔。
反過來會害人的，是你沒辦法辯護的答案。面試官一定會追問——為什麼用這個結構、資料量變十倍會怎樣、有重複值會不會壞掉——而追問瞄準的正是你剛剛講的那句話。給出一個漂亮的答案，然後在追問上崩掉，比給一個慢一點但完全屬於你的答案更糟，因為它把「不確定要不要錄取」變成了「確定不錄取」。
可以用的界線很簡單：用它來聽懂和想起來，推理自己做，用自己的話講出來——因為被打分數的只有後面這件事。
資料來源
- CoderPad — pad settings (code execution, AI Assist, autocompletion)
- HackerRank — Introduction to HackerRank Interviews
以上資訊已在 2026 年 10 月 14 日對照這些頁面查證過。
FAQ
現場寫程式面試是什麼？
面試官打開共用編輯器，你在他注視下即時寫程式並講解思路，通常三十到六十分鐘。和線上程式測驗不同，它衡量的不是最終的程式碼，而是你怎麼得到它：有沒有先問清楚、思路是否合理、能不能一邊寫一邊解釋。
現場寫程式時可以執行和測試程式碼嗎？
通常可以，而且應該用——跑一次比在腦中跟它搏鬥快得多。HackerRank 的面試介面有 Run Code 和 Run Tests 兩個按鈕；CoderPad 有 Run 按鈕，但依官方文件，面試官可以替這場面試關掉程式碼執行。如果面試官沒說，先問一句；有些人會故意關掉，想看你能不能在沒有執行結果的情況下推理正確性。
寫不出最佳解會直接沒過嗎？
通常不會。評分表裡只有一項跟程式碼有關。先寫出能跑的暴力解、講清楚它慢在哪裡、再自己最佳化，分數常常比安靜地寫出最佳解還高。真正致命的是一句話都不講。
卡住的時候該怎麼辦？
把最笨的解法講出來，從它開始。或拿一個四個元素的小例子手算一遍，邊算邊講。兩種方式都能把「卡住」變成一個看得見、可以打分數的過程，而沉默不能。