工程師行為面試怎麼準備？用 STAR 講清楚決策、衝突與失敗

工程師行為面試怎麼準備？先找出你真正做過、也能接受追問的決策，再用 STAR 整理敘述。面試官聽完後，應該能分辨當時的限制、你的責任、你採取的行動，以及結果從哪裡得到證實。

STAR 是 Situation、Task、Action、Result，也就是情境、任務、行動與結果。STAR 整理的是敘述順序；每個決策與結果仍需要具體細節支持。本文用三個原創教學情境，示範技術決策、團隊衝突與失敗如何講清楚。

行為面試準備，先把證據與說法分開

官方資訊： Amazon 的 SDE III 準備頁建議候選人回想具體經歷，適用時提供數據，並用 STAR 組織成功、挑戰、失敗與成長的例子。這是 Amazon 對該職務的公開建議，不是所有公司的共同評分表。Amazon 官方 SDE III 面試準備

候選人分享： jc-hiroto 在 2023 年 12 月的繁體中文文章中，回顧自己遇到的 BQ 與專案敘述方式。這是較早的個人經驗，可以幫助理解故事怎麼整理，但不能證明今天任何公司的輪次或時間安排。SDE BQ 之我的見解

以下的故事、追問表與練習方法是本文的編輯建議。示範人物、專案與數字皆為虛構，不是候選人的錄取案例。準備自己的版本時，只保留能用真實經歷支持的內容；沒有觀察到的成效，就不要補成看起來更漂亮的結果。

開始寫稿前，先把事實列出來：專案目標、當時的限制、你負責的部分、你做過的選擇、相關紀錄、最後結果。接著選出最能回答題目的一次決策，再安排背景、行動與結果。反過來先寫「展現領導力」的故事，容易把細節改成符合形象的版本。

另一份可參考的公開資料是 UC Berkeley 人資的行為面試建議。它使用 CAR（情境、行動、結果）架構，特別提醒候選人說明自己採取的行動。這也說明縮寫不是重點：不論採用哪個架構，都要讓個人貢獻可以被辨認。UC Berkeley 人資建議

STAR 的四段各自要回答什麼

情境要讓對方理解問題，任務要交代你必須完成什麼，行動要說清楚你的判斷，結果則要回到原來的目標。四段不必各占相同篇幅，尤其不要用大量背景擠掉真正的行動。

段落	要回答的問題	工程師常漏掉的資訊
Situation 情境	當時為什麼需要處理這件事？	規模、期限、現有系統限制
Task 任務	你對哪個結果負責？	個人責任與團隊目標的差別
Action 行動	你怎麼判斷，做了什麼？	備選方案、採用依據與協作過程
Result 結果	發生了什麼，如何確認？	指標口徑、未達成部分與後續改善

「我們把系統改好了」同時缺少任務、行動與結果。可以先改成：「我負責找出批次延遲的原因，比較增加 worker 與減少重複查詢，最後先修正查詢路徑。」這仍然需要證據，但至少對方知道接下來能問什麼。

準備時，不妨先練一個兩分鐘版本，再保留能展開的細節。兩分鐘是本文用來控制敘述的練習限制，不是面試通則。若題目要求特定細節，就直接回答，不必為了完成四段格式繞回長篇背景。

故事一：技術決策要說出你沒有選的方案

原創示範情境： 一個內部報表每天早上產生，團隊收到使用者反映，報表偶爾太晚完成。你負責調查並提出改善，但不能在本週更換資料庫。

較空泛的回答是：「我分析問題、提出最佳方案，最後大幅提升效能。」這句話幾乎可以放進任何專案，聽不出你實際做了什麼。

可以改成以下版本：

我負責調查每日報表的延遲。當時不能更換資料庫，因此先檢查現有查詢與執行紀錄。我發現同一份對照資料在每個項目都重新查詢，於是比較了增加 worker 和在單次工作內重用對照資料。增加 worker 會把更多查詢同時送到資料庫，所以我先做了重用方案，並保留功能開關方便回復。

我用同一份固定輸入比較修改前後，確認輸出一致，再觀察後續排程是否完成。若要說正式環境改善多少，還需要相同口徑的執行紀錄；我不會把本地測試的差異直接當作線上成果。

示範的重點是決策有依據，也有邊界。實際回答時，請補上你真正知道的資料量、觀察期間與結果。如果你只負責調查、最後由資深工程師選定方案，也可以直接說，不需要把決策權全部攬到自己身上。

接著練三個追問：「為什麼不直接快取所有資料？」「對照資料中途更新會怎樣？」「哪個條件出現時，你會改採增加 worker？」回答這些問題時，應回到一致性、記憶體、更新頻率和瓶頸，而不是重複「當時這樣比較快」。

如果你沒有完整效能數據，可以說：「我確認消除了每個項目的重複查詢，但當時沒有控制其他線上變因，所以無法把所有延遲改善歸因於這次修改。」能限制結論，是技術判斷的一部分。

故事二：衝突要保留對方合理的立場

衝突故事最容易變成「我說服了不懂技術的同事」。這樣的敘述可能讓對方聽不見你如何合作，只聽見你如何評斷別人。先說出共同目標，再解釋不同方案各自保護什麼。

原創示範情境： 團隊要在期限前推出搜尋篩選功能。你擔心新索引增加維護負擔，另一位同事擔心直接查詢無法滿足回應時間。兩人都希望功能能穩定上線，只是對風險的判斷不同。

可以這樣組織行動：你先把爭論從「哪個方案比較好」改成可驗證的問題；找出代表性查詢，定義回應時間與資料更新需求；和同事分別做最小實驗，再一起比較結果。若最後採用對方的方案，也應說明什麼證據改變了你的想法。

一個可追問的回答是：

我原本主張先沿用現有查詢，因為團隊當時沒有維護新索引的經驗。同事提出尖峰查詢可能超時，我們便一起選了幾種使用者操作做測試。結果顯示其中一類查詢確實無法滿足我們訂的目標，我因此支持先為這類查詢建立索引，並負責補上更新失敗的監控。

我們沒有把所有搜尋路徑一次遷移，而是記錄哪些路徑先使用新索引，以及出現資料落差時如何回復。這次經驗讓我把「維護成本高」拆成可討論的工作，而不是把它當成否決新方案的理由。

這個示範只呈現處理分歧的方法，不能證明妥協必然帶來較好的結果。也可能實驗支持你的方案；此時仍要交代你如何讓對方參與驗證、如何處理他原先擔心的風險。

追問可以包括：「如果期限不允許做兩個實驗呢？」「誰有最終決策權？」「對方不同意測試條件怎麼辦？」你可以說明如何縮小問題、找決策者確認或記錄尚未解決的風險。不要把每次衝突都寫成皆大歡喜；有些結果只是決策更清楚，關係仍需要後續修復。

故事三：失敗要交代你的責任與後來的改變

「我太追求完美」通常無法回答一次失敗的具體經過。選擇一個你確實做錯判斷、漏掉檢查或未及時溝通的事件，說清楚影響、處理方式和後來如何改變。

原創示範情境： 你負責修改通知服務，測試只覆蓋成功回應，上線後遇到下游超時，重試造成部分重複通知。這裡的失敗是測試與失敗語義的缺口，不應把責任全部推給下游服務。

回答可以從承認缺口開始：「我當時只確認正常流程與明確錯誤，沒有處理超時但下游可能已完成的情況。」接著說明當下怎麼止血，例如暫停有問題的重試路徑、確認影響範圍、與相關團隊協調恢復。實際用過什麼措施才說什麼，不要為了完整而補出不存在的回滾流程。

後續改善也要具體。你可能補上請求識別、重複檢查、未知結果的查詢流程或故障注入測試。解釋哪一項對應原來的失敗，並說明誰負責審查和驗證。只說「以後會更小心」，無法讓人理解工作方式有什麼改變。

結果不一定是「從此零事故」。更可信的表述可能是：「我們完成修正並加入超時案例，後續觀察期間沒有再看到相同模式；其他重複來源仍需要另外處理。」如果沒有足夠觀察期，就只說測試和修正完成，不宣稱事故已永久消失。

最後準備一個更難的追問：「如果讓你重來，你會在哪個時間點做不同決定？」回答應指向具體時刻，例如評審時先確認失敗語義，或在發版前要求一個未知結果案例。這比抽象地說「加強溝通」更能呈現你學到了什麼。

沒有漂亮數字，也能交代有根據的結果

結果可以是可核對的變化，不一定要是百分比。測試覆蓋了一個原本會失敗的路徑、交接文件讓接手者能獨立部署、需求確認避免了錯誤實作，都是可以說清楚的結果。把觀察與推測分開，對方才知道哪些結果已確認、哪些仍需驗證。

把證據分成三種會比較容易：直接紀錄，例如測試輸出或執行時間；別人的回饋，例如使用者確認操作恢復；你自己的推論，例如預期減少未來維護成本。第三種仍然可以說，但要標明「預期」及需要什麼資料驗證。

如果資料涉及保密，就改用比例、範圍或去識別化描述，同時保留比較口徑。例如「相同資料集與環境下，執行時間約縮短一半」，仍然要能解釋如何測量。不能因為不方便透露原始值，就隨意換一個更有說服力的數字。

準備一張簡單證據表，檢查哪些說法需要收斂：

想說的結論	可以支持的證據	較精確的表述
我改善了整個系統的穩定性	一個失敗案例的回歸測試	我修正了這條重試路徑，並補上對應測試
我說服大家採用最佳方案	方案比較與評審紀錄	我整理比較條件，團隊依測試結果選擇方案
使用者非常滿意	少量回饋或客服紀錄	這幾位使用者確認問題已解決，尚無全面調查
我主導整個專案	個人負責的模組與協作紀錄	我負責這個模組，與其他負責人共同完成交付

中英文試講時，保留因果關係，不逐字背稿

如果面試以英文進行，可以先用繁體中文整理事實，再用短句重述。不要把中文長段落逐字翻譯成英文，否則真正重要的決策常被埋在背景裡。

例如：「我原本傾向沿用現有查詢，但測試顯示某一類操作無法達到回應時間目標，所以我支持針對該路徑建立索引。」可以說成：

I initially preferred the existing query path. Our test showed that one query type missed the latency target, so I supported adding an index for that path.

這段英文保留了原先立場、證據與改變後的決策。下一句再補自己的行動，例如監控或回復機制，不必一次塞進所有細節。若你不記得精確數字，可以說明記得的範圍與限制，不要為了流暢而臨場編造。

找練習夥伴時，請對方不要只評價你講得順不順，而是追問三件事：「哪一步是你做的？」「有什麼證據？」「什麼情況下你會換方案？」如果追問讓你卡住，先補事實或縮小結論，再修改措辭。

同一個專案可以回答不同問題，但切入點要跟著題目改變。問衝突時，重點放在分歧與協作；問失敗時，重點放在錯誤判斷與改善。不要把同一份完整稿件從頭背到尾，期待面試官自行找到相關段落。

用五道題檢查故事能否承受追問

它們不代表所有公司採用相同題目或同一套評分方式。

練習題（英文）	要檢查的故事細節
Behavioral: Handling a Conflict, Feedback, and On-Call Incidents	分開衝突、回饋與值班事件中的個人責任
Discuss Collaboration, Feedback, and Conflict	說清楚你如何理解對方立場並改變做法
Describe a Failure and the Change It Prompted	從失敗連到具體的後續改變
Explain Performance, OKRs, Failure, and Project Learning	確認成果指標的口徑與專案學習
Resolve Team Conflicts to Improve Delivery Efficiency	用協作過程與交付結果支持衝突故事

先完成一次試講，再修改一個最明顯的缺口：背景太長，就刪到足夠理解限制；個人行動不清楚，就補上你實際負責的決定；結果太空泛，就加證據或收斂結論。保留修改前後的錄音或筆記，比單純增加故事數量更容易看見進步。

工程師行為面試準備的最後一步，是讓敘述與履歷、專案細節保持一致。如果你想先練失敗故事。

Sources and Further Reading

• UC Berkeley 人資：Behavioral Interview Tips & Examples

• Amazon 官方：SDE III Interview Prep

• jc-hiroto：SDE BQ 之我的見解，2023 年 12 月 28 日

資料核對日期：2026 年 10 月 6 日。公司官方建議、較早的候選人分享與本文原創示範已分別標示；本文不根據單一經驗推斷各公司的現行面試流程。