行為面試指南（STAR 法與故事庫）

一份實用的準備指南，針對軟體工程面試裡的行為／「領導力」回合。coding 與系統設計拿走了 大部分的注意力，但行為回合才是把「很強的候選人」和「可以錄用的候選人」分開的地方。這份指南 涵蓋這類回合怎麼評分、STAR 框架、一份可重複使用的故事庫、幾個完整的範例答案， 以及檢查清單。

總覽

行為回合在評估什麼

在多數頂尖／大型科技公司裡，行為面試不是一個「軟性」或可以隨便打發的回合。它是一場結構化、 以證據為基礎的對話，設計來擷取關於你實際上怎麼做事的訊號 —— 而不是你抽象地說你會怎麼做。

面試官通常會評的訊號：

為什麼它重要

• 行為回合常常佔整個 loop 的三分之一左右（通常是 1–2 個專門的回合，加上散在技術回合裡的 行為性追問）。
• 它常常是決勝點：兩個 coding 分數相同的候選人，就在這裡被分開。
• 行為訊號不好（自大、怪別人、講不出可衡量的影響）可以否決一個其他方面都很強的 loop —— 很多公司把某些特質列為「不能不及格」。

它怎麼被評分

面試官通常會做接近逐字的筆記，把你的故事對應到上面那些訊號的評分表，每一項評為 強／混合／沒有訊號。他們受過訓練，會做追根究柢的追問（「你自己具體貢獻了什麼？」、 「你會有什麼不一樣的做法？」）。含糊或誇大的答案在這種追問下會崩掉 —— 這就是為什麼具體、 有數字、以第一人稱講述的故事會贏。

STAR 框架

STAR 是回答「請說一個你曾經……的經驗」這類問題的標準結構。它讓你的答案具體、 按時間推進，也讓面試官容易評分。

**經驗法則：**答案的核心是 Action。如果你花在 Situation 的時間比 Action 多， 那就搞錯了。

STAR+（再加上反思／學習）

強的候選人會在後面補一段簡短的反思：你學到什麼、你會有什麼不一樣的做法，或這段經驗如何 改變了你後來的行為。這直接展示了判斷力與學習那個訊號，往往也是「好」與「很強」之間的差別。

S → T → A → R → (+) Reflection / Learning

收尾範例：「最大的收穫是，我當時假設大家對齊了，而不是去確認。現在跨團隊的工作我一定先寫 一頁的決策文件 —— 之後每個專案我都這麼做。」

該花多少時間

一個完整的 STAR 答案應該講約 2–3 分鐘。配速：

• **Situation + Task：**20–30 秒。剛好夠讓人理解賭注就好。不要去描述組織圖或歷史沿革。
• **Action：**60–90 秒。分數是在這裡賺的。用「我做了 X，為了 Y」。
• Result：20–30 秒。有數字就用數字開頭。
• **反思：**10–20 秒。

STAR 常見的錯誤

故事庫

事先準備 6–8 個有彈性的故事。大部分行為問題都是少數幾個主題的變化，而一個好故事可以從 不同角度涵蓋好幾個主題。

**覆蓋度小技巧：**把你準備好的故事對這些主題畫成一張表格。目標是每個主題至少有一個故事， 而你最強的 2–3 個故事各自能涵蓋 3 個以上的主題。

完整範例 1 —— 和同事的衝突

題目：「說一次你和同事意見不同的經驗。」（主題 #1）

**情境。**在一個虛構的內部分析平台上，一位資深同事和我對事件資料該怎麼存有不同意見。他想維持 現有的單一寬表；我認為它撐不過我們預估的攝入成長。

**任務。**作為擁有攝入管線的工程師，我需要在下一季的工作開始前讓大家對 schema 達成一致 —— 選錯的話，之後要回頭改會非常貴。

行動。我沒有在抽象層面爭論，而是先請他把他的理由講給我聽，於是我理解他真正擔心的是遷移 風險，不是那個設計本身。接著我做了一個小型的負載測試，把 30 天的真實流量重播到兩種 schema 上，並分享數字：寬表的 p95 查詢延遲在超過某個門檻後急遽惡化，而我們兩季內就會到那個門檻。 然後我提出一個分階段遷移的方案，直接回應他的風險顧慮。

**結果。**當取捨變成具體的數字而不是意見之後，他就同意了。我們零停機地上線了新 schema， 尖峰負載下的查詢延遲降低約 40%。

**反思。**我學到大部分的「意見不同」其實是缺少共同的數據。現在我的預設做法是 「我們量一下」，而不是辯論 —— 這把衝突變成了一次共同的調查。

完整範例 2 —— 最大的失敗

題目：「說一次你失敗的經驗。」（主題 #3、#11）

**情境。**我剛開始負責一個虛構的通知服務時，改了對外寄信的批次邏輯，預期能降低供應商成本。

**任務。**這個改動只有我一個工程師負責，包含上線前的驗證。

行動。我測了 happy path，但跳過了正式規模的負載測試。在真實流量下，批次邏輯把訊息 壓得太久，下游佇列開始堆積，讓一部分對時間敏感的通知延遲了最多 20 分鐘。警報一響，我立刻 回滾、在事故頻道貼出清楚的狀態更新，並且公開承認這個錯誤，而不是推給別的原因。之後我跑了一次 不究責的事後檢討，在部署管線裡加上負載測試的關卡，並為佇列深度寫了 runbook 警報。

結果。事故在約 35 分鐘內被控制住，沒有資料遺失。更重要的是，那道新的負載測試關卡後來在 上到正式環境前攔下了兩個類似的問題。

**反思。**這次失敗教會我「能跑」不是標準 —— 「在規模下能跑，而且壞掉時壞得安全」才是。 之後每個團隊我都是那個推動上線前負載關卡的人。

完整範例 3 —— 超出職責範圍的當責

題目：「說一次你承擔了職責以外的事的經驗。」（主題 #7、#10）

**情境。**在一個虛構的結帳團隊裡，on-call 的負擔很痛苦 —— 同樣三個不穩定的警報幾乎每晚都會 叫醒某個人。那不是任何人被指派的專案，所以它一直被延後。

**任務。**沒有人負責「修好 on-call 健康度」，但痛是真的，士氣也在掉。我決定把它變成我的事， 即使它不在我的 roadmap 上。

**行動。**我花了幾天把三個月的警報歷史拉出來，發現約 70% 的 page 來自那三個警報，而且它們全都 能自動恢復。我帶著數據寫了一份簡短的提案，拿去找主管和另外兩位受影響最深的工程師，爭取到一小塊 時間。接著我修掉底層的重試邏輯、調整警報門檻。因為我對其他工程師沒有職權，我是靠攤開數據、 並讓他們一起形塑解法來取得認同。

**結果。**一個月內夜間 page 減少了大約 75%，團隊問卷裡的 on-call 滿意度從紅燈變成綠燈。

**反思。**我學到「不是我的事」往往只是「還不是任何人的事」，而數據加上一份具體的提案， 就是沒有頭銜也能領導的方式。

完整範例 4 —— 面對模糊

題目：「說一次需求不清楚的經驗。」（主題 #6、#12）

**情境。**我被要求為一個虛構的開發者工具「改善 onboarding 體驗」—— 沒有規格、沒有成功指標， 只有一種模糊的感覺：新使用者流失了。

**任務。**我的工作是把那個開放式的請求，變成一季內可交付、可衡量的東西。

行動。我沒有去猜，而是先定義指標：啟用率（新使用者在 24 小時內成功發出第一個 API 呼叫 的比例）。我在漏斗上埋了追蹤，發現最大的流失點在 API key 那一步，並訪談了五位近期的使用者來 確認。接著我把範圍縮到單一個影響最大的修正 —— 一段引導式的 key 設定流程 —— 其餘延後， 並把我的假設寫下來，好讓利害關係人能及早糾正我。

**結果。**啟用率在一季內從約 48% 提升到約 63%，而我做的那個漏斗儀表板成了團隊排定 onboarding 工作的標準依據。

**反思。**模糊通常代表缺了一個指標。現在我的第一步永遠是把那個含糊的目標變成可衡量的， 再讓數據把範圍收窄。

準備你自己的故事

步驟 1 —— 從自己的經歷裡挖

用這些提示做腦力激盪（目標是 10–15 個原始故事，再挑最好的）：

• 你覺得自豪的專案 —— 它難在哪裡？
• 某件事壞掉、或某個專案延誤的時候。
• 意見不同的時刻 —— 和同儕、主管、其他團隊。
• 你影響了某個你其實控制不了的結果。
• 你用吃苦頭的方式學到某件事。
• 那些很刺但確實有道理的回饋。

步驟 2 —— 故事工作表模板

每個故事填一份。控制在一頁之內。

Title:            (one line — e.g. "Schema load-test disagreement")
Themes covered:   (e.g. conflict, data-driven decisions, influence)
Situation (2 sent): _______________________________________________
Task / my role:   _______________________________________________
Action (bullets — start each with "I ..."):
    - I ...
    - I ...
    - I ...
Result (quantified): ______________________________________________
Reflection:       _______________________________________________
Likely follow-ups: "What was *your* part?" / "What would you change?"

步驟 3 —— 讓一個故事涵蓋多個主題

同一個故事可以靠你強調哪一段來換角度：

核心事實準備一次，然後練習用不同的重點重講。

步驟 4 —— 量化影響

數字讓結果可信。如果沒有精確數字，就用站得住腳的估計，並且說清楚（「大約」、「差不多」）。 可用的面向：

• **效能：**延遲、吞吐量、p95/p99、錯誤率。
• **效率：**省下的工程時數、降低的成本、建置／部署時間。
• **規模：**使用者數、每秒請求數、服務的資料量。
• **業務：**轉換率、啟用率、留存、營收。
• **團隊：**減少的 on-call page、review 的回覆時間、新人上手時間。

常見行為問題（依類別）

下面收進了值得演練的經典問題。把每一題對應到你故事庫裡的一個故事。

領導力與當責

• 說一次你把一個沒人願意接的問題接下來的經驗。
• 你什麼時候在沒有正式職權的情況下推動了一個決定或專案？
• 描述一次你把標準拉高／改善了團隊做事方式的經驗。
• 你見過最好／最糟的設計 —— 你對它做了什麼？

衝突與團隊合作

• 說一次和同事或主管意見不同的經驗，以及最後怎麼解決。
• 你自己一個人做事、以及在團隊裡做事，分別在什麼狀態下最好？
• 一次你必須和難相處的人共事的經驗。
• 一次你必須說服別人接受不受歡迎立場的經驗。

失敗與回饋

• 說一次你最大的失敗／一個不順利的專案。
• 你遇過最難的 bug —— 你怎麼處理它？
• 一次你收到嚴厲回饋的經驗 —— 你後來怎麼做？
• 過去的專案裡，你有什麼地方可以做得更好？

模糊與壓力

• 一次需求不清楚的經驗 —— 你怎麼往下走？
• 說一次在很趕的截止日下交付的經驗。
• 一次你必須在太多互相競爭的需求裡排優先序的經驗。
• 你在過去的專案裡遇到最大的挑戰。

動機與「為什麼是這個職位」

• 你為什麼想要這份工作／這個職位？
• 過去的專案裡你最享受什麼，為什麼？
• 你的哪些技能或經驗會是這裡的資產，為什麼？
• 你最近一個專案學到了什麼？
• 你對現有產品有什麼改進的想法？

反問面試官的問題

永遠準備好 3–5 個問題 —— 一個都不問會被讀成沒興趣。好問題是具體的、往前看的， 而且顯示你真的好奇。差的問題是那些你五秒鐘就能查到的，或是讓人覺得你只在意福利的。

可靠的常備問題（收進原本的清單並一般化）：

• 新人在前三個月最常犯的錯誤是什麼？
• 你覺得團隊／產品未來 3–5 年會往哪裡走？
• 當初是什麼讓你決定加入的，實際狀況符合期待嗎？
• 過去幾年在這裡，你覺得自己的能力有成長嗎？
• 加入這個團隊的第一週大概是什麼樣子？
• 團隊裡技術決策怎麼做、歧見怎麼解決？

非 coding 的錄用訊號（general attributes）

除了純粹的 coding 能力，面試官還會評估一組能預測長期表現的通用特質。行為問題的答案 是這些特質的主要證據：

**關鍵洞察：**你不要宣稱這些特質（「我是很棒的領導者」）—— 而是用一個具體的故事 展示它們，讓面試官自己得出結論。用演的，不要用講的。

要避開的紅旗

• 把失敗歸咎於同事、主管或「公司」。
• 全程只說**「我們」** —— 面試官找不到你的貢獻。
• 誇大或無法驗證的說法，一被追問就散掉。
• 對前雇主或前同事講壞話。
• 沒有反思 —— 一個沒有學到教訓的失敗故事。
• 散漫、沒有結構，逼面試官自己去挖重點。
• 自大 —— 貶低別人的想法、把團隊成果全歸自己。
• 賭注太小 —— 為了 tab 還是空格而起的「衝突」展示不出真正的判斷力。
• 講假設 —— 說「我會……」而不是「我做了……」。
• 最後一個問題都不問。

面試前檢查清單

• [ ] 以 STAR+ 形式準備好 6–8 個故事，每個一頁工作表。
• [ ] 把故事對到一張主題覆蓋表（每個主題至少有 1 個故事）。
• [ ] 每個故事都有量化的 Result（或站得住腳的估計）。
• [ ] 練習講行動時用**「我」**，出聲練、每個計時到約 2–3 分鐘。
• [ ] 演練過可能的追根究柢追問（「你負責哪一部分？」、「你會改什麼？」）。
• [ ] 準備好一個簡潔具體的**「為什麼是這個職位」**答案。
• [ ] 準備好 3–5 個要問面試官的問題。
• [ ] 讀過紅旗清單，並用它自我檢查每個故事。
• [ ] 每個故事都能不看筆記、像聊天一樣講出來，而不是逐字背下來。

參考資料

• Coding Interview University
• STAR 法 —— situation、task、action、result（廣泛使用的行為面試框架）