STAR 原則，以及怎麼用才不像在背稿

四個字母分別代表什麼

• Situation 情境——背景，一到兩句話。在哪裡、什麼時候、當時什麼東西有風險。
• Task 任務——具體由你負責的是什麼。一句話。
• Action 行動——你做了什麼。這才是答案本身。其他都是包裝。
• Result 結果——什麼改變了，有數字就給數字。

STAR 出自人才評鑑公司 DDI：它自稱在 1974 年隨著 Targeted Selection 行為面試系統推出這個方法，前提是「過去的具體行為，是預測未來行為最好的證據」。DDI 自己把情境和任務合成一段（ST），這本身就說明它們不該占太多時間。Amazon 的官方面試準備頁面也建議用 STAR 回答領導力準則類的問題，並盡量給出數據。

沒人告訴你的比例

這是經驗法則，不是官方標準。一個 90 秒的回答裡：情境加任務一共大約 15 秒，行動大約 50 秒，結果大約 15 秒。如果你還在講公司的組織架構、專案的來龍去脈、還有誰參與，那你仍然卡在 Situation，而面試時間正在燒掉。

面試官不替情境打分數。他們在聽的是你做了哪些決定、為什麼這樣決定。一個不大的問題、但你的判斷清楚可見，分數會比一個戲劇化的問題、而你的角色模糊不清還高。

說「我」，不要說「我們」

這是強的應徵者最常見的失分方式。「我們決定做遷移」沒有透露任何關於你的資訊。如果是你主導的，就說是你主導的。如果你是五個人裡的一個，就講清楚你負責哪一塊。面試官整天都在聽「我們」，他們會把它當成謙虛或遮掩——而這兩樣都沒辦法給分。

解決方法很機械：在 Action 那一段，大部分句子用「我」開頭。如果做不到，那這個故事大概不是關於你的，換一個。

一個完整範例

問題：「分享一次你不認同某個決定的經驗。」

弱（情境太重）：「當時我們團隊大概十二個人，公司剛經歷一次組織調整，我那時候的主管是從另一個部門調過來的……然後有個專案已經跑了大概八個月……」——四十秒過去了，什麼事都還沒發生。

強：「去年春天，我的總監想在兩週內上線一次定價調整。（情境）這次上線由我負責。（任務）我不同意——我們當時沒有任何方法衡量它對流失率的影響，所以就算上了也學不到東西。我要求先給一週把轉換漏斗的埋點做起來，並帶了一頁說明，寫出有埋點和沒埋點我們分別看得到什麼。他同意延後兩週。（行動）我們在第一批用戶裡抓到流失率上升了 9%，在影響全部用戶之前就回滾了。（結果）」

同一個故事。強的那一版把時間花在決定和推理上，而這是唯一能帶到工作中的部分。

如果結果是不好的

有些最好的回答結尾並不漂亮。「我們上線了，然後失敗了」完全沒問題——前提是 Result 那一段變成你從中學到什麼、之後改了什麼。面試官特地問失敗，就是因為修飾過的成功故事什麼都說明不了。一個有清楚教訓的失敗，勝過一個你講不清楚的成功。

行不通的是沒有擔當的失敗。「需求改了」和「另一個團隊延遲了」不是結果，是藉口。

要準備幾個故事

不是一題一個——你永遠猜不到題目。準備五到六個故事，每個對應幾個主題：衝突、失敗、領導、說服、緊急期限、模糊不清的局面。一個好故事通常能換個重點，回答三四個不同的問題。

每個故事寫成四行，一個字母一行。不要寫成段落——你要記的是結構，不是句子。

壓力之下

緊張的時候最先丟掉的就是結構，而那正是最需要它的時刻。Interview Copilot 聽到問題後，會搭出一個 STAR 形狀的回答——情境、你做了什麼、結果——兩三句可以自然講出來的話。Pro 版會用你自己履歷裡的內容；不論哪個版本，都不應該捏造一條你沒提供過的成績。

資料來源

• DDI — The STAR Method (introduced in 1974 with Targeted Selection)
• Amazon Jobs — Product Manager Interview Prep (Leadership Principles, STAR)

以上來源都在 2026 年 10 月 14 日查證過。

應用程式在這裡怎麼幫忙

相關文章

接著讀