"说说你在没有职权的情况下影响他人"——STAR回答拆解

一句话总结："说说你在没有职权的情况下影响过别人"有明确的评分标准——真实存在的利益相关方阻力、你用来说服对方的具体交换条件或证据、以及下次会怎么调整。哪怕项目最后成功了，一个"我沟通到位，大家最后都想通了"式的泛泛故事，照样答不好这道题。

职业生涯走到第三轮面试左右，你大概率会碰到这道题的某个版本："说说你需要影响一个你没有职权管的人的经历。"听起来像是常规的领导力行为面试问题，但它实际考察的范围窄得多——大多数候选人答偏了。

在FAANG和大厂面试里，这道题几乎是海外求职（H1B、OPT、跨国大厂跳槽）绕不开的一关，尤其在PM、TPM、工程序列的中后期面试环节几乎必问。

这道题为什么会存在

规模到一定程度的公司，运转基本都靠跨部门协作：产品需要工程配合，工程需要基础设施支持，基础设施又要财务放行。这些事几乎都不走汇报线。Center for Creative Leadership的研究反复发现，管理者要完成的大部分工作，都需要影响不在自己正式汇报链条里的人——但大多数人对这件事的自信程度，远低于他们管理直属下属时的自信。面试官问这道题，是因为职位头衔预测不了你能不能真的把跨部门的事情推动下去，一个真实故事才能说明问题。

这也是为什么公司一直坚持用行为面试的格式问这道题，而不是问一个假设性场景。几十年的招聘研究（可以追溯到经典的Schmidt和Hunter元分析）反复证明，问一个具体的过去案例，比让人描述自己一般的做事方式，更能预测工作表现。"我很擅长建立共识"这句话是无法证伪的，但一个点名道姓、有具体怀疑者的故事不是。

面试官到底在打分什么

大多数针对这道题的准备文章，止步于一个泛泛的四步模板——铺垫场景、描述行动、提一句软技能、说个不错的结果——然后甩给你一个用滥了的例子（那个非营利组织筹款的故事，几乎逐字出现在好几个不相关的"面试准备"网站上，这本身就说明面试官已经听腻了）。这个模板漏掉了真正被打分的东西。根据这道题在Amazon、Meta、JPMorgan Chase等公司真实面试环节里的呈现方式，评分标准通常有五个部分：

1. 真实的利害关系和真实的截止日期——不是一个假设性的改进方案，而是有明确日期、拖延就要付出代价的事情。
2. 确有其事的阻力证据——你能说出谁反对，以及站在对方的位置上，他的反对为什么讲得通，而不只是"有些人当时不太情愿"。
3. 具体的杠杆，不是含糊的——你收集的数据、你提出的小范围试点、你给出的激励，或者你达成的一笔交换。"我把好处讲清楚了"不算杠杆。
4. 可衡量、至少是具体的结果——变化是什么，你怎么知道的。
5. 复盘的一句话——下次会怎么调整，或者你从中学到了这个方法在什么情况下不管用。

前三点里少了任何一个，都是这类回答哪怕故事是真的、听起来也显得空洞的最常见原因。

这道题在不同公司、不同岗位怎么变着法问

同一个能力项，不同公司的问法差别很明显，知道变体有助于你挑对故事：

• Amazon把这道题和"Have Backbone; Disagree and Commit"这条领导力准则绑在一起——他们特别想听你用数据对一个你不认同的决定据理力争，等决定拍板之后，哪怕没有权力推翻它，也要全力去执行。
• Meta这类工程主导的公司，常把它包装成技术分歧："说说你不同意某位资深工程师的设计方案，但没有权力去改它的经历。"这里的杠杆通常是一个原型、一份基准测试，或者一个范围明确的实验，而不是嘴上的争论。
• JPMorgan Chase这类大型企业倾向于直白地问："没有职权的情况下要怎么影响别人？"——经常是圆桌面试的形式，这种场合更看重紧凑、结构化的回答，而不是一段长叙事。
• PM、TPM和跨部门岗位几乎默认会被问到这道题，因为这些岗位的全部工作内容就是协调不向你汇报的人——面试官在这里经常会追问，如果同样的策略失败了你会怎么办。

如果你在为某家具体公司准备，应该按照它的问法去匹配你的故事，而不是一套通用版本套用到所有面试里。

用STAR搭建你的回答

一旦手里有了一个真正有摩擦的故事，STAR方法能让你的表达保持紧凑：

1. Situation（情境）——用一两句话说清楚跨部门的利害关系：需要达成什么，以及为什么这不是你一个人能决定的事。
2. Task（任务）——在没有权力强制执行的情况下，你要对什么结果负责。
3. Action（行动）——谁反对了，反对的理由是什么，以及你用来说服对方的具体杠杆。这是面试官真正在听的部分。
4. Result（结果）——发生了什么，最好带数字，以及你学到了什么或者会做出什么调整。

大多数候选人最容易讲得单薄的是Action这一步。对比一下"我跟团队开会解释了为什么这个改动很重要"和"基础设施负责人担心这次迁移会破坏她团队依赖的on-call手册，于是我提出让两套系统并行跑两周，在切换前把diff报告分享给她的团队——这消除了她最主要的顾虑"。后者证明了影响力确实发生了，前者只是在自称如此。

两个回答范例

产品经理，跨部门发布："我负责一次定价调整，需要一位不向我汇报的销售总监签字批准，他一直怀疑这会打击他团队的成单率。我没有推迟截止日期，而是拉了两周的成交数据，找出在现行定价下最可能流失的账户，并提议给现有客户保留一个续约周期的旧价格——他真正的顾虑其实不是定价改动本身,而是他手上正在进行中的那些交易。他接受了这个保留方案，我们按期上线，下一个季度的流失率反而比上一个季度更低。如果我当时只是把成型的方案甩过去要他签字，我觉得他会直接把这事升级上去。"

软件工程师，技术分歧："另一个团队的一位资深工程师给我负责的功能提了一个共享缓存层的方案，我相当确定在我们的流量模式下这会引入竞态条件，但我没有权力否决他的设计。我没有在设计评审会上争论，而是花两天做了一个小的压测原型，在接近真实的并发场景下复现了这个竞态条件。我把复现结果和一个建议的锁策略分享给他，他同意在合并前加上修复。现在回头看，我本应该在设计文档阶段就更早提出流量模式的顾虑——原型最后证明是有效的，但也让我们多花了本可以省下的两天。"

两个故事都点出了具体需要说服的那个人，以及具体是什么说服了他们——这让故事变得可核查，可核查才可信。

应对追问

那些已经听过这道题无数遍套路回答的面试官，经常会当场追问诸如"如果试点数据不理想你会怎么办？"或者"如果她还是拒绝了呢？"这种问题。这正是背好的稿子容易崩的地方，因为它从一开始就没有为真正的逻辑分支做过准备。

如果你在用AceRound这样的实时面试辅助工具练习，这是特别值得专门演练的一个环节——在你回答到一半时真的冒出一个合理的追问（而不是提前准备好的静态稿子），这比事先读一遍模板然后祈祷临场能撑住，更接近一场真正高压面试的实际感觉。

常见问题

没有职权的情况下要怎么影响别人？ 面试里靠的是"证明"而不是"自称"：选一个对方完全不归你管、你也没法调用你老板去压他的故事，讲清楚你怎么靠数据、关系或者一个小范围试点建立起共识。可信度来自你能具体说出谁反对、为什么反对——而不是一句笼统的"我沟通能力强"。

说说你需要争取一群不归你直接管理的同事支持某个重要项目的经历。 好的回答会点出那个最难说服的具体人物、你给他的具体交换条件（不是笼统的"我解释了好处"），以及一个可衡量的结果。如果你的故事套在任何项目上都成立，那就太泛了——面试官在听的是那个差点就说不的人。

你怎么说服过一个一开始并不愿意配合的人？ 这个变体想听到摩擦被讲明白。先用对方的逻辑说清楚他当初为什么反对（站在他的位置上这个反对是合理的），再讲清楚到底是什么具体改变了他的想法——一个更小的请求、一份证据，或者一笔交换。跳过"反对理由"这一步，是这类回答最容易显得空洞的原因。

说说你不同意某位资深工程师的设计方案，但没有权力去改它的经历。 这是技术/IC路线的版本，在Meta等公司很常见。评分点在于你有没有用建设性的方式把分歧往前推——做原型、拿数据、跑一个范围可控的实验——而不是要么沉默要么反复重复同一个论点。以"如果再来一次我会怎么做"收尾，是区分资深回答和初级回答的关键。

这道题和一般的领导力问题有什么区别？ 领导力故事可以靠你的职位或汇报线撑着。这道题专门把这根拐杖拿走了——面试官想看的是，当你没法直接下指令时，你能不能靠证据、信任或者激励机制把影响力建立起来。如果你举的例子里那个人本来就向你汇报，那就没有回答这道题。

---

作者 · Alex Chen。职业顾问，前科技公司招聘人员。在招聘一线做了5年后转去帮候选人准备面试，写的都是真实面试里发生的事，不是教科书式的建议。