Influence Without Authority

Show how you got buy-in from people who didn't report to you: learn what they care about, bring evidence, start small and know when to escalate.

How It Works

Influence questions ask how you got something done when you couldn't just decide. Another team owned the service, a senior engineer had a different plan, or leadership controlled the roadmap. "Tell me about a time you convinced another team" is really asking how you change minds without authority over the people involved. That describes most of an engineer's cross-team work.

The answer interviewers hope not to hear is "I was right, so I kept explaining until they agreed." It shows conviction, but it skips everything they're scoring. They want to see that you treated the other side's position as reasonable and worked out why they held it.

What they cared about. Their goals, their workload, the risk they were worried about. Influence starts with understanding why the answer is currently no.
Evidence. Data, a benchmark, an incident or a customer complaint. Something they can check, not your opinion said more firmly.
A small first step. A prototype, a pilot on one service, a single data point. Small asks are easier to say yes to, and they produce the evidence for the big one.
Allies. Who else had the same problem, and who the decision-maker already trusted.
Compromise and escalation. What you gave up to reach agreement, and whether you escalated when you couldn't reach it.

Pick a story where the other side started out unconvinced for a reason you came to respect. The best ones end with a change they owned, not one you forced on them. A partial win or a compromise is fine, and often better, because it shows you can read a situation instead of only pushing harder. Avoid stories you won by going over someone's head, unless escalating was the right call and you told them first.

Scope grows with level. A mid-level engineer might get their own team to adopt a testing practice, or get another team to accept a design in review. A senior engineer often needs another team to change its roadmap. At staff level, the audience is usually directors or several teams at once, and the story is about building a case over weeks: writing the proposal, running the pilot and lining up the people whose support decides it.

Influence and conflict stories overlap, so one disagreement you worked through can answer both. Tag it with both in your story bank, and be ready for follow-ups like "what would you have done if they still said no?"

What Interviewers Listen For

Whether you understood what the other side cared about before trying to persuade them.
Evidence they could check, not just a stronger version of your opinion.
A small first step that lowered the cost of saying yes.
Respect for the people you persuaded, in how you describe them now.
Judgment about compromise and escalation: when to give ground and when to go up a level.

How It's Asked

The same question comes in many wordings. Any of these wants the same kind of story.

Tell me about a time you persuaded someone to change their mind.
Describe a time you got buy-in for an idea that wasn't popular at first.
Tell me about a time you had to convince another team to do something.
How have you sold a technical change to leadership?
Tell me about a time you influenced a decision you didn't own.
Describe a time you got people to follow your lead without being their manager.
Give an example of a time you used data to change a decision.

Sample Answers

The Question

Tell me about a time you had to convince another team to change how they worked.

Try drafting your own answer first, then compare. Both answers are invented.

Show Sample Answers

A Common Answer

Sure. At my last company another team owned an API we depended on, and they kept changing it without telling anyone. It was causing problems for every team that used it. I wrote up a proposal for contract testing and presented it at their planning meeting.

They were pretty resistant at first, mostly because it was more work for them, but I kept pushing and explaining the benefits. Eventually my manager talked to their manager and they agreed to do it. It took a while, but we got there in the end.

A Strong Answer

I was on the checkout team at an online furniture retailer. Our service called the inventory team's API, and their changes kept breaking us without warning. In six months we'd had seven incidents from unannounced changes to their responses. I wanted them to run contract tests in their CI, so a breaking change would fail their build before it reached us. They owned the service, so it was their call.

My first try didn't work. I posted a design doc in their channel on why contract testing is good practice, and it got two thumbs-up reactions and nothing else. So I asked their tech lead for half an hour to understand why. They were behind on a database migration, and a flaky test suite had once blocked their deploys for two days. To them, any new CI step sounded like weeks of work and a fresh way to get stuck.

That told me what to change. I pointed out that four of the seven incidents had paged their on-call too, so this was their problem as well. I wrote the contract tests myself for the three endpoints we used, and set them to report only, never block, for a month. All they had to do was review one pull request. The search team used the same API and had the same problem, so I brought in their lead, and she added tests for her endpoints. I'd also agreed with my manager that if the pilot didn't convince them, we'd raise it at the monthly architecture review with their lead in the room.

We didn't need to. In that month the tests flagged two breaking changes before merge, and their engineers fixed both in the pull request. Their lead agreed to make the tests blocking, on one condition: if a contract test turned flaky, the consuming team fixes it within a business day or it gets switched off. I accepted that. In the next six months we had one incident from their API instead of seven, and two more teams added contracts on their own.

What I took from it is that my doc asked them to take on risk, and the pilot asked for almost nothing. Now when I need another team to change something, I start by asking what's making them say no.

Why It Works

The strong answer finds out why the other team was saying no (a migration and a history of flaky tests) and shapes the ask around it. The weak answer calls them "resistant" and stops there.
The evidence is specific and checkable: seven incidents, four of which paged them too, then two breaking changes caught in a month.
The candidate lowers the cost of yes by writing the tests, running them non-blocking and accepting the fix-it-in-a-day rule. The weak answer wins through two managers, which is borrowed authority, not influence.
The reflection admits the first attempt failed and names the habit it led to.

Common Pitfalls

Telling a story where you were right and they eventually admitted it. The question is how you changed their mind, so their reasons belong in the story.
Winning by escalation. Going to your manager can be the right move, but if it's the whole story, it shows authority you borrowed rather than influence you built.
Describing the people you persuaded as stubborn or political. Interviewers listen closely to how you talk about colleagues you disagreed with.
Leaving out what your idea cost the other side. Without it, the interviewer can't tell why getting a yes was hard.
Choosing a story where nobody really objected. Getting agreement from someone who already agreed isn't influence.