軟體工程師面試怎麼準備？依職缺把程式題、專案與設計排出優先順序

軟體工程師面試準備，應先依職缺與已確認的面試任務，把程式題、專案、設計排出優先順序，而不是給每個人同一份刷題表。只有十二小時時，前端元件實作、後端交易處理與資深跨服務設計，需要留下的證據並不相同。

這篇面向臺灣求職者，提供從職缺文字到練習產物的判斷方法，並用兩份有限時間預算示範調整。下面的職缺、候選人與分配時數都是虛構練習，不是任何臺灣公司的正式招募流程、評分權重或錄取預測。

選題不是準備的終點：你仍要說清楚它修補哪個缺口，以及做完要留下什麼證據。

先讀職缺中的動作，不只圈技術名詞

「熟悉 React、SQL、雲端服務」只能指出工具範圍。真正影響準備的，是你入職後要交付什麼：實作互動介面、維護交易服務、處理事故、推動跨團隊遷移，還是定義架構方向。把每一項職責改寫成「我要能完成或解釋哪個任務」，才有辦法選練習。

例如「維護 API」可能包含驗證、版本相容性、錯誤碼與可觀測性，而不是背 HTTP 名詞。「與產品合作」可能需要說明模糊需求如何被收斂，不代表準備十段團隊合作口號就足夠。遇到描述過廣的條目，先列出兩種合理解讀，再用職缺上下文或招募方資訊縮小。

用三份虛構職缺練習閱讀。A 是初中階前端，要求表單、非同步資料與可存取性；B 是中階後端，要求訂單 API、資料庫交易與值班；C 是資深工程師，要求跨服務遷移與技術協調。這三者都叫 Software Engineer，卻不能只因職稱相同就平均分配時間。

虛構職缺中的責任	需要證明的事	第一個準備產物
A：實作表單與資料互動	狀態、驗證、競態與鍵盤操作能共同運作	可操作的小元件與邊界測試
B：維護交易 API 與值班	錯誤情境不破壞資料，能定位故障	一段交易流程及事故診斷紀錄
C：推動跨服務遷移	依賴、相容性、切換與責任分工可說清楚	分階段遷移圖和一項取捨

這張表不是猜題表。實際 invitation 若指定演算法題、既有程式除錯或白板設計，應優先服從已確認的任務；職缺則用來選相關例子和深度，不用來推翻面試通知。

分開「需要的能力」與「這輪怎麼觀察」

能力可能是解題、建模與溝通；觀察方式可能是線上測驗、live coding、專案深挖或設計討論。同一個後端能力，在現場可能要求修改程式，在另一家公司可能要求口頭推演。準備內容相近，產物形式仍要不同。

Microsoft 官方技術面試說明明確提到澄清問題、先形成計畫、實作與測試。本文把它作為一個僱主公開的技術準備例子，不把 Microsoft 的輪次、時間或工具規則套到所有臺灣公司。不同職缺的實際範圍仍需確認。

在開啟正式測驗前，核對截止時間、時區、可用語言、輸入介面、是否能執行程式、允許的文件與 AI 工具，以及中斷時的聯絡方式。準備邀請中的示範環境，不表示可以提前啟動有計時的正式測驗。

如果通知沒有寫設計，不能推出「不會問設計」；如果職稱是 senior，也不能推出必有某一種 system design。把這種資訊標為未確認，安排基本覆蓋並提出窄問題：「這輪主要是演算法實作、既有程式修改，還是服務設計？」比詢問會出哪題更有用。

用職級調整責任範圍，不用職級跳過 Coding

初階候選人可以用課程、研究、實習與個人開發證明技術判斷，前提是分清完成的範圍。你沒有運營大型服務，不需要編造百萬使用者；可以展示一個失敗的測試如何促使你修改資料結構，或一次部署問題如何被定位。

有實務經驗的候選人，需要能回答「你負責哪一段、為什麼這樣改、如何驗證」。只說使用了哪些框架，無法替代個人決策。若專案由多人完成，把你的程式、同事的基礎設施和共同決策分開，反而更容易承受追問。

資深職缺常在職責上擴大到跨團隊、取捨與長期維護；這是依職缺安排準備的理由，不是免除基本實作的理由。若通知仍安排 Coding，能熟練做架構簡報但無法測試一段函式，是需要優先修補的缺口。

「設計」也有層次：元件與介面邊界、單服務資料模型、跨服務一致性，不是同一種題目。先確定要談哪一層。對前端職缺，說清請求競態與狀態擁有者，可能比畫一套陌生的全球分散式系統更能回應職責。

做一次短診斷，找出最貴的失誤

先完成一題與已確認任務相近的練習，錄下從理解到測試的過程。診斷不是看你讀解答後能否認出演算法，而是看你能否獨立定義輸入、選擇狀態、實作，並提出能推翻錯誤解法的例子。

把失誤寫成可以觀察的句子。例如「把空陣列當成一定有第一筆」、「沒有確認重複 ID 是忽略還是覆蓋」、「只測成功請求，取消後仍更新畫面」。不要只寫「基礎差」或「太緊張」，因為這些標籤無法決定下一小時要做什麼。

再做一次專案追問：請夥伴問你為什麼選資料庫、誰負責部署、成果數字怎麼量測。若你在 Coding 中最常漏契約，在專案中又說不清觀測範圍，兩者可能共享「未先定義成功條件」這個缺口；練習可以針對這個決策習慣，而不是再加二十題。

為缺口區分三種情況：已確認會用且目前做不到；職缺相關但尚未確認考法；只是網路推薦但與這次申請關係弱。第一種優先，第二種保留基本覆蓋與確認動作，第三種在時間有限時可以先不做。這是準備排序，不是對未公開評分方式的推測。

可以依序問自己三個問題：下一輪是否已確認需要這個任務？目前能否獨立完成並解釋？剩餘時間能否產出一個可驗證的改善？若第一個答案是肯定、第二個是否定，就優先安排小範圍修補；若任務尚未確認，先查清範圍，不急著投入大型重學計畫。

例如甲已確認會做搜尋元件，卻只背過防抖的定義。一次實作應刻意讓請求 A 先送、請求 B 後送，卻讓 B 先回應，檢查 A 的舊結果是否覆蓋畫面。能重現並修正這個錯誤，比多讀一份框架名詞表更符合目前缺口；但若邀請改成純演算法題，這個練習就不應繼續占據主要時數。

MDN 的 AbortController 文件說明取消 fetch 等非同步操作的能力。把它當成工具邊界來練習：已完成操作與尚未完成操作不同，畫面也仍需知道哪個請求的結果可以生效；「呼叫了取消」不是所有狀態都正確的測試結論。

鍵盤測試則可以參考 W3C 對焦點順序的說明：焦點移動應保留內容意義和操作性。甲的練習應檢查輸入、錯誤提示與下一步之間是否能合理操作，而不是只數可以按 Tab 的元素。這是一項技術檢查方向，不是宣稱小元件已通過完整無障礙稽核。

如果三個答案都不確定，不要用「哪個主題最熱門」代替決策。先完成一個最小診斷，或向招募方確認作業形式。新增資訊的價值在於它能改變時間配置，而不是讓準備清單越來越長。

同樣十二小時，兩個候選人怎樣分配

候選人甲申請虛構前端職缺 A，已確認下一輪是元件實作加專案討論。甲熟悉演算法，但診斷中發現快速切換搜尋詞時舊回應會覆蓋新結果，表單錯誤也不能用鍵盤找到。準備應先修這些任務相關缺口，而不是用熟悉的演算法題填滿時間。

候選人乙申請虛構後端職缺 B，已確認下一輪是 Coding 加專案深挖。乙有值班經驗，但寫演算法時容易忘記邊界和複雜度。乙應保護獨立實作與測試時間，再用既有交易專案練習責任與故障推演。

準備範圍	甲：前端元件與專案，共 12 小時	乙：後端 Coding 與專案，共 12 小時
主要實作缺口	5 小時：搜尋與表單的取消、競態、鍵盤測試	5 小時：獨立演算法實作、邊界與變體
真實專案追問	3 小時：狀態邊界、自己的程式與成果口徑	3 小時：交易、事故、個人責任與證據
職務相關技術	2 小時：JavaScript 行為與元件測試	2 小時：重試、交易失敗與資料一致性
未確認設計的基本覆蓋	1 小時：資料流與狀態擁有者	1 小時：單服務模型及瓶頸
環境與收尾	1 小時：邀請、工具、可執行檔與最後測試	1 小時：邀請、工具、輸入入口與提交檢查

十二小時只是示範預算，不是最佳時數或招聘權重。兩人都不在這次衝刺重學全部 DSA，也不新做大型作品。每一格應有結束條件：能執行一組競態測試、能解釋一個不變條件、能用合法披露的證據回答一項追問，而不是「看完五支影片」。

如果甲先前的演算法診斷其實失敗，而邀請又包含 Coding，就要重排，不應因為「我是前端」忽略它。排序必須由當前任務和實際缺口共同決定，不能由一張固定表單代替判斷。

只剩六小時，或邀請突然更新時怎麼改

若乙只剩六小時，可以保留三小時 Coding 與測試、兩小時專案追問、一小時環境與提交檢查。這次明確不新增分散式架構教材，也不追求陌生題型全覆蓋。未確認的設計範圍仍向招募方確認，並把現有專案資料流當作最低準備，而非假裝不存在風險。

若甲的邀請更新為既有程式除錯，原本五小時元件實作不必全部丟棄。拿已完成的小元件，刻意加入一個過期回應錯誤、一個驗證漏分支，練習從症狀找最小重現與修復，再確認沒有破壞鍵盤行為。舊產物轉換用途，比重新找十個新教程更直接。

相反，如果更新為完全不同的演算法測驗，就需要承認方向改變。把未完成的大型 UI 功能暫停，先確認輸入與輸出契約、練最薄弱的基本題型。不要以「已經投入很多」為理由繼續不相關任務；也不要讓一個未經證實的論壇留言觸發這種大調整。

每次重排記下三件事：新資訊是什麼、哪項時間被移動、哪些風險仍沒覆蓋。這樣下次看到新面經時，你能判斷它是否真的改變準備，而不是被每個“必考”標題牽著走。

程式題、專案和設計，各留下不同證據

程式題的產物是一份可執行解法、契約、複雜度與反例。若只是背出題型名稱，還沒有證明你能處理需求變化。測試應針對等號、空值、重複、排序與身份規則，並說明輸入修改與額外空間，而不是只給一個通過範例測試的截圖。

專案的產物是一項可辯護的決策。譬如你選擇先修回應競態而不是重構整個狀態框架，要能說清使用者症狀、替代方案、實施邊界和驗證。沒有線上資料就說功能測試或預發布觀察；團隊指標也不能自動算作你個人帶來的因果結果。

設計的產物是一條完整資料流與一條失敗路徑。對於訂單API，可以推演提交成功但回應遺失時如何重試；對於UI，可以推演使用者返回上一步後草稿是否保留。這些問題比「用某某資料庫可以擴充」更接近職責所需要的判斷。

最後為每份產物準備簡短解釋與進一步深挖。你應該能先說明問題和關鍵選擇，再按對方的問題展開，而不是開場講完十分鐘架構史。若考官改變一個約束，明確指出原設計哪一部分仍成立、哪一部分要重新選擇。

技術回答要展示推理，而非堆滿名詞

回答「為什麼用這個技術」時，先講約束再講選項。例如需要支援重複請求，就比較身份、去重結果與提交邊界；不是先宣佈“使用Redis”。如果資料庫已經提供所需交易能力，新增元件反而可能製造新的故障邊界。

不確定時可以說：「在目前假設下我會這樣做；若吞吐、延遲或一致性目標不同，我會重新評估這一段。」接著指出你需要哪個量測來決策。不知道真實流量卻報出精確機器數，或者把教程的數字當作自己專案結果，都會讓後續解釋變得困難。

用英文面試時也保留這條邏輯。可以練一句：“I would first clarify which state must remain correct when a request is retried.” 再用自己的例子解釋，而不是為了英語流利省略關鍵邊界。你的目標是讓對方能跟上選擇，不是持續說話。

專案涉及機密時，去掉客戶身份、內部連結、憑證和不可披露程式碼。經授權使用相對量級或脫敏模型，並說明哪裡被簡化。獨立練習專案也可以成為證據，但不要把本地執行結果說成生產服務表現。

依缺口選練習，做完再決定下一步

下面不是臺灣公司統一題庫。題目包含不同公司與角色，完整英文標題用於定位練習；選擇依據是它們能訓練職責閱讀、實作檢查和責任說明。使用它們時，先確認是否符合你自己的邀請。

題目	對應的準備缺口	應產出的證據
Code Review of a Multi-File HTTP API: Wrong Method, Payload and Validation Bugs	既有 API 程式除錯	最小重現、修補與回歸測試
Resume Project Deep Dive: Tech Stack Choices, Trade-offs, Business Logic and Ownership	技術選型與個人責任不清楚	自己的決策、替代方案與邊界
Explain Technical Contributions and Delivery Under a Tight Deadline	有限時間內如何交付；此為 MLE 角色練習	留下與推遲的專案及理由
Validate AI-Generated Code Safely	會生成程式，但驗證不完整	契約、反例與自己理解的實作
Resolve a Disagreement in Code Review	技術討論只有結論、沒有依據	共同標準及改變判斷的證據

從 Software Engineer 題庫挑與下一輪任務最相近的一題，完成後重新看一次職缺。若你仍說不清為什麼選它，就先修準備優先順序；若可以指出具體缺口，就把下一段時間用於那個缺口。面試準備不是讓所有欄目都有打勾，而是在有限時間內留下與職務相關、能承受追問的證據。

資料來源與延伸閱讀

• Microsoft Careers：Technical interviews，職務相關解題、實作與測試的官方例子
• MDN：AbortController，取消非同步操作的介面與邊界
• W3C WAI：Understanding Focus Order，焦點順序的說明

資料核對：2026 年 10 月 6 日。職缺與時間配置為原創示範，正式測驗與面試條件以個人邀請為準。