「請舉例說明你曾在沒有職權情況下發揮影響力」：STAR 答案拆解

重點先講：「請舉例說明你曾在沒有職權情況下發揮影響力」這題有明確的評分標準——真實的利害關係人阻力、你用來說服對方的具體交換條件或證據，以及下次會怎麼做不一樣。就算專案最後成功了，一個「我溝通得很好、大家都被說服了」的籠統故事，還是會在這題上失分。

在你職涯的某場外商面試——通常已經進到第三輪左右——面試官會丟出這題的某個版本：「請舉例說明你曾必須在沒有職權的情況下影響某個人。」聽起來像是一般的領導力行為面試題，但它實際考的東西窄得多——而大部分求職者答錯了重點。

這題為什麼存在

規模到一定程度的公司，運作都靠跨部門協作：產品需要工程配合，工程需要基礎架構支援，基礎架構需要財務放行。這類協作幾乎沒有一項是靠匯報線走的。Center for Creative Leadership 的研究反覆發現，領導者要完成的工作大多需要影響正式匯報體系以外的人——但多數人對自己在這件事上的信心，遠低於他們管理直屬下屬的信心。面試官問這題，是因為職稱預測不了你到底有沒有能力真正把跨部門的事情推動起來；一個真實的故事才能。

這也是為什麼公司特別喜歡用行為面試的形式問這題，而不是假設性問法。數十年的招募研究（可以追溯到經典的 Schmidt 與 Hunter 後設分析）一致發現，請對方舉出具體過去案例，比請對方描述自己的一般做法，更能預測工作表現。「我很擅長凝聚共識」這句話無從驗證。一個點名了誰質疑、為什麼質疑的具體故事，可以。

面試官實際在評的評分標準

大部分準備這題的文章，都只停在一個籠統的四步驟模板——鋪陳場景、描述你的行動、提一個軟實力、講一個好結果——然後丟給你一個罐頭範例（同一個非營利募款故事，在好幾個互不相關的「面試準備」網站上幾乎一字不差地出現，這件事本身就說明面試官已經聽膩它了）。這種模板漏掉了真正被評分的東西。根據這題在 Amazon、Meta、摩根大通這類公司真實面試裡出現的樣子，評分標準通常有五個部分：

1. 真實的利害與真實的期限——不是一個假設性的改善，而是綁著日期、拖延會有代價的事。
2. 真實阻力的證據——你能講出誰不同意，以及為什麼站在他的立場上，反對是合理的，而不只是「有些人有點猶豫」。
3. 具體的槓桿，不是模糊的槓桿——你蒐集的數據、你提出的小型試點、你提供的誘因，或你談成的交換。「我把好處解釋得很清楚」不算槓桿。
4. 可量化、至少是具體的結果——改變了什麼，以及你怎麼知道。
5. 一段回顧——下次會怎麼做不一樣，或你學到這套方法在什麼情況下行不通。

前三項少了任何一項，是這類答案就算故事本身是真的，聽起來還是空洞的最常見原因。

這題會依公司和職務而變化

同一種核心能力，會用明顯不同的說法來問，知道變體版本有助於你選對故事：

• Amazon 把這題綁在它的「Have Backbone; Disagree and Commit」領導力原則上——他們特別想聽到你用數據反駁一個你不同意的決策，然後即使沒有推翻它的職權，一旦拍板了也全力承接執行。
• Meta 和其他技術導向的公司，常把它框成技術分歧：「請舉例說明你曾不同意某位資深工程師提出的設計，卻沒有職權去改變它。」這裡的槓桿通常是原型、基準測試，或是範圍受限的實驗——而不是口頭爭論。
• 摩根大通和其他大型企業傾向問得很直白：「你怎麼在沒有職權的情況下發揮影響力？」——常常是小組面試形式，這種形式獎勵的是更緊湊、結構化的答案，而不是一段長敘事。
• PM、TPM 和跨部門職務幾乎必問這題，因為整份工作就是在協調不對你匯報的人——這裡的面試官常常會追問：如果同一套做法失敗了，你會怎麼做。

如果你在準備特定公司的面試，就用他們問法的框架去對應你的故事，而不是拿同一個籠統版本套所有場次。

用 STAR 架構答案

一旦你有了一個帶著真實摩擦的故事，STAR 方法能讓你的表達保持緊湊：

1. Situation（情境）——用一到兩句話講清楚跨部門的利害關係：需要發生什麼，以及為什麼這不是你一個人能決定的事。
2. Task（任務）——即使沒有職權去強制執行，你對哪個結果負責。
3. Action（行動）——誰反對、他的反對理由是什麼，以及你用來說服他的具體槓桿。這是面試官真正在聽的段落。
4. Result（結果）——發生了什麼，最好帶一個數字，加上你學到什麼或會怎麼調整。

大部分求職者在 Action 這一步講得太單薄。比較一下「我跟團隊開會解釋這個改變為什麼重要」和「基礎架構主管擔心這次遷移會打斷她團隊仰賴的一份 on-call 手冊，於是我提議兩套系統並行跑兩週，並在切換前把差異報告分享給她的團隊——這打消了她最主要的顧慮」。第二個版本證明了影響力確實發生了；第一個只是宣稱它發生了。

兩個範例答案

產品經理，跨部門上線案：「我當時負責一項定價調整，需要一位我不匯報的業務總監簽核，而他懷疑這會傷害他團隊的成交率。我沒有硬推期限，而是拉了兩週的成交數據，找出在現行定價下最可能流失的客戶群，並提議讓現有客戶延續一個續約週期的舊價——他真正的顧慮其實是他手上已經在談的那些案子，而不是調整本身。他同意了這個過渡方案，我們照時程上線，接下來一季的流失率甚至比前一季更低。如果我當初直接丟出一份完成的方案要他買單，我覺得他會把這件事往上呈報。」

軟體工程師，技術分歧：「另一個團隊的資深工程師為我負責的一個功能提議了一個共享快取層，我相當確定在我們的流量模式下會引發競態條件，但我沒有否決他設計的職權。我沒有在設計評審會上跟他爭論，而是花兩天做了一個小型負載測試原型，在符合實際情況的並發量下重現了那個競態條件。我把重現結果和一個鎖策略提案分享給他，他同意在合併前加上修正。事後回想，我應該在設計文件階段就更早提出流量模式的疑慮——原型有效，但花掉了本來可以省下的兩天。」

兩個故事都點名了需要被說服的具體對象、以及具體是什麼說服了他們——這正是它們可以被查核的原因，而可以被查核，正是它們可信的原因。

應付追問

聽過這題籠統版本太多次的面試官，經常會當場追問：*「如果試點數據結果不理想呢？」或「如果她還是說不，你會怎麼做？」*這正是排練過的故事容易崩解的地方，因為它本來就沒被設計來應付邏輯上真正的分支。

如果你是用像 AceRound 這樣的即時 AI 面試陪練工具練習，這是特別值得專門練的一個環節——讓系統在你回答到一半時丟出一個合理的追問（而不是事先寫死的固定腳本），會比讀一遍模板就期待它在真實場上撐得住，更接近一場真正被壓力測試過的面試。

常見問題

沒有職權要怎麼影響別人？ 在面試裡，你要示範而不是自稱。選一個你對需要說服的人沒有正式權力的故事，說明你怎麼靠數據、關係或試點建立共識——而不是請主管出面壓下去。可信度來自你能講出誰不同意、為什麼不同意，而不是一句空泛的「我很擅長溝通」。

請舉例說明你曾需要爭取沒有直接管轄權的同事支持某項重要計畫的經驗。 有力的答案會點名最難說服的那位關鍵人物、你開出的具體交換條件（不只是「我解釋了好處」），以及可量化的結果。如果你的故事套在任何專案上都成立，那就代表太籠統——面試官在聽的是那個差點說不的人。

你曾怎麼說服一個原本不贊成的人去做某件事？ 這個變體題想聽到的是摩擦被講清楚。先用對方的邏輯陳述他原本的反對理由（站在他的位置上拒絕為什麼合理），再說明到底是什麼具體地改變了他的想法——一個縮小範圍的請求、證據，或是你提出的交換。跳過反對意見這一段，是這類答案最常翻車的原因。

請舉例說明你曾不同意某位資深工程師提出的設計，卻沒有職權去改變它。 這是技術／IC 職涯路線的變體，在 Meta 這類公司很常見。評分重點在於你有沒有用建設性的方式把分歧往上推——做原型、拿數據，或設計一個範圍受限的測試——而不是選擇沉默，或反覆重複同一套論點。最後補一句「下次會怎麼做不一樣」，是資深答案和資淺答案的分水嶺。

這題跟一般的領導力故事有什麼不同？ 領導力故事可以靠你的職稱或匯報關係撐場。這題特別把那個槓桿拿掉——面試官想看到的是，當你不能直接下指令時，你怎麼靠證據、信任或誘因建立影響力。如果你的例子裡對方是你的下屬，那就沒有回答到這題。

---

作者 · Alex Chen。職涯顧問、前科技業獵頭。在招募端待了 5 年後轉向幫求職者準備面試。寫的是真實的面試互動邏輯，不是教科書式的建議。