Tell Me About a Time You Influenced Without Authority: STAR Answer
"Tell me about a time you influenced without authority" only rewards real stakeholder friction. Here's the rubric interviewers score, plus STAR examples by role.

TL;DR: "Tell me about a time you influenced without authority" is scored on a specific rubric — real stakeholder resistance, the concrete trade-off or evidence you used to move them, and what you'd do differently next time. A generic "I communicated well and everyone came around" story fails this question even if the project succeeded.
Somewhere around the third interview loop of your career, you'll get some version of this question: "Tell me about a time you had to influence someone without having authority over them." It sounds like a general leadership behavioral question, but it's actually testing something narrower — and most candidates answer the wrong thing.
Why This Question Exists
Every company above a certain size runs on cross-functional work: product needs engineering, engineering needs infra, infra needs finance sign-off. Almost none of that work happens through a reporting line. The Center for Creative Leadership has repeatedly found that the majority of what leaders need to accomplish requires influencing people outside their formal chain of command — yet most people rate themselves as far less confident doing this than they are at managing direct reports. Interviewers ask this question because a title doesn't predict whether you can actually get cross-functional work done; a real story does.
That's also why companies keep asking it in behavioral-interview format specifically, rather than as a hypothetical. Decades of hiring research (going back to the classic Schmidt and Hunter meta-analyses on interview validity) consistently find that asking for a specific past example predicts job performance better than asking someone to describe their general approach. "I'm good at building consensus" is unfalsifiable. A specific story with a named skeptic isn't.
The Rubric Interviewers Are Actually Scoring
Most prep articles for this question stop at a generic four-step template — set the scene, describe your actions, mention a soft skill, state a good outcome — and then hand you a single canned example (the same nonprofit-fundraising story shows up nearly word-for-word across several unrelated "prep" sites, which should tell you how much interviewers have already heard it). That template misses what's actually being scored. Based on how this question shows up in real loops at companies like Amazon, Meta, and JPMorgan Chase, the rubric usually has five parts:
- Real stakes and a real deadline — not a hypothetical improvement, but something with a date attached and a cost if it slipped.
- Evidence of genuine resistance — you can name who disagreed and why their objection made sense from their seat, not just that "some people were hesitant."
- A concrete lever, not a vague one — data you gathered, a smaller pilot you proposed, an incentive you offered, or a trade you made. "I explained the benefits clearly" is not a lever.
- A measurable or at least specific outcome — what changed, and how you know.
- A retrospective note — what you'd do differently, or what you learned about when this approach won't work.
Missing any of the first three is the most common reason these answers feel hollow even when the underlying story is real.
How the Question Changes by Company and Role
The same underlying competency gets asked in noticeably different phrasings, and knowing the variant helps you pick the right story:
- Amazon ties this to its "Have Backbone; Disagree and Commit" leadership principle — they specifically want to hear you push back on a decision you disagreed with, using data, and then commit fully once a call was made, even without authority to overrule it.
- Meta and similar engineering-heavy companies often frame it as a technical disagreement: "Tell me about a time you disagreed with a senior engineer's proposed design but had no authority to change it." Here the lever is usually a prototype, a benchmark, or a scoped experiment — not a verbal argument.
- JPMorgan Chase and other large enterprises tend to ask it flatly: "How do you influence without authority?" — often in a panel format, which rewards a tighter, more structured answer over a long narrative.
- PM, TPM, and cross-functional roles get this question almost by default, since the entire job is coordinating people who don't report to you — interviewers here often follow up by asking what you'd do if the same tactic failed.
If you're preparing for a specific company, match your story to how they phrase it rather than reusing one generic version for every loop.

Building Your Answer With STAR
Once you have a story with real friction in it, the STAR method keeps the delivery tight:
- Situation — the cross-functional stakes in one or two sentences: what needed to happen, and why it wasn't yours to decide alone.
- Task — what outcome you were responsible for, even without the authority to mandate it.
- Action — who resisted, what their objection was, and the specific lever you used to move them. This is the section interviewers are actually listening to.
- Result — what happened, ideally with a number, plus what you learned or would change.
Where most candidates go thin is the Action step. Compare "I met with the team and explained why the change mattered" against "The infra lead was worried the migration would break an on-call runbook her team relied on, so I offered to run both systems in parallel for two weeks and share the diff report with her team before we cut over — that removed her main objection." The second version proves influence happened; the first just claims it did.
Two Sample Answers
Product manager, cross-functional launch: "I was responsible for a pricing change that needed sign-off from a sales director I didn't report to, and who was skeptical it would hurt his team's close rate. Instead of pushing the deadline, I pulled two weeks of deal data showing the accounts most likely to churn under the current pricing, and proposed grandfathering existing customers for one renewal cycle — his actual objection was about the deals already in his pipeline, not the change itself. He agreed to the grandfathered rollout, we shipped on schedule, and churn in the following quarter was actually lower than the prior one. If I'd just presented the finished plan and asked for buy-in, I think he'd have escalated it instead."
Software engineer, technical disagreement: "A senior engineer on another team proposed a shared caching layer for a feature I owned, and I was fairly sure it would introduce a race condition under our traffic pattern, but I had no authority to veto his design. Instead of arguing it in the design review, I built a small load-test prototype over two days that reproduced the race condition under realistic concurrency. I shared the repro and a proposed lock strategy, and he agreed to add the fix before we merged. In hindsight, I should have raised the traffic-pattern concern earlier in the design doc phase — the prototype worked, but it cost us two days we could have avoided."
Both stories name the specific person who needed convincing and the specific thing that convinced them — that's what makes them checkable, and checkable is what makes them credible.
Handling the Follow-Up Question
Interviewers who've heard the generic version of this answer many times often follow up live with something like "What if the pilot data had come back unfavorable?" or "What would you have done if she'd still said no?" This is where a rehearsed story can fall apart, because it wasn't actually built to handle a real branch in the logic.
If you're practicing with a real-time copilot like AceRound, this is one of the more useful moments to rehearse specifically — having something surface a plausible follow-up while you're mid-answer (not just a static script beforehand) is closer to what an actual pressure-tested loop feels like than reading a template once and hoping it holds up live.
Frequently Asked Questions
How do you influence without authority? In an interview, you show it rather than claim it: pick a story where you had no formal power over the people you needed to move, then walk through how you built alignment (data, relationships, or a pilot) instead of asking your manager to intervene. The credibility comes from naming who disagreed and why, not from a generic "I'm a good communicator" claim.
Tell me about a time when you needed to gain support for an important initiative from colleagues over whom you had no direct authority. Strong answers name the specific stakeholder who was hardest to convince, the concrete trade-off you offered them (not just "I explained the benefits"), and a measurable result. If your story could apply to literally any project, it's too generic — the interviewer is listening for the one person who almost said no.
How have you convinced someone to do something they were initially not in favor of doing? This variant wants the friction made explicit. State their original objection in their own logic (why saying no was reasonable from where they sat), then explain what specifically changed their mind — a smaller ask, evidence, or a trade you offered. Skipping the objection is the most common way this answer falls flat.
Tell me about a time you disagreed with a senior engineer's proposed design, but had no authority to change it. This is the technical/IC-track version, common at Meta and similar companies. It's scored on whether you escalated the disagreement productively — prototyping, data, or a scoped test — rather than either staying silent or repeatedly re-litigating the same argument. Ending with what you'd do differently if it happened again is what separates a senior answer from a junior one.
What's the difference between this question and a general leadership story? A leadership story can rely on your title or reporting line. This question specifically removes that lever — the interviewer wants to see influence built through evidence, trust, or incentives when you couldn't just direct someone. If your example involved someone who reported to you, it doesn't answer the question.
Author · Alex Chen. Career consultant and former tech recruiter. Spent 5 years on the hiring side before switching to help candidates instead. Writes about real interview dynamics, not textbook advice.
Related Articles

How Do You Handle Ambiguity? The Interview Answer That Actually Works
Answer 'how do you handle ambiguity' with a Clarify-Frame-Decide-Communicate framework, plus sample answers for tech, consulting, and startup roles.

Tell Me About a Time You Had to Learn Something Quickly: A Real Answer
"Tell me about a time you had to learn something quickly" tests learning agility, not memory. STAR structure, real examples, what to say when you blank.

Tell Me About a Time You Had to Make a Difficult Decision: A Real Answer, Not a Script
'Tell me about a time you had to make a difficult decision': it works only if you could defend the other choice. STAR structure and pushback tips inside.