What do interviewers evaluate in Influence questions?

Interviewers listen for signals like: Did you actually have to influence, or did you have implicit authority via your manager / project priority? Did you build shared context before asking for commitment, or did you push your conclusion? Did you earn credibility with concrete proof points (prototype, data, scoped pilot), or just argument?

gitGood.dev

GeneralAdvanced Premium

Leadership Without Authority

The senior+ signal. Can you drive cross-team work, mentor, and build consensus when nobody reports to you - or do you only execute when given a mandate?

About this theme

Leadership without authority is one of the most discriminating signals at senior, staff, and principal levels. Almost every meaningful engineering project involves people you don't manage - partner teams, peers on your own team, stakeholders in product or design, vendors, customers. The interview question is whether you can move work forward through influence, technical credibility, and clear communication, or whether you stall the moment you don't have a formal mandate. Strong candidates tell stories where they (a) built shared context with people who had different priorities, (b) earned trust through cheap proof points before asking for big commitments, (c) navigated explicit disagreement without escalating prematurely, and (d) recognized when influence wasn't going to work and escalated cleanly. Weak candidates tell stories where they "just convinced everyone" without describing how, or stories where the work succeeded because the candidate had de facto authority (their manager backed them, the project was already a top priority, etc.). This theme is heavily tested at Google (staff+ rounds), Meta (E5/E6), Stripe (senior+), and any company evaluating you for technical leadership scope.

What interviewers are evaluating

→Did you actually have to influence, or did you have implicit authority via your manager / project priority?
→Did you build shared context before asking for commitment, or did you push your conclusion?
→Did you earn credibility with concrete proof points (prototype, data, scoped pilot), or just argument?
→When people disagreed, did you investigate their reasoning, or label them as blockers?
→Did you mentor or grow others as a side effect, or only extract their effort?
→When influence wasn't working, did you escalate cleanly - or either give up or go around?
→At senior+ levels: did you scope the work so others could own pieces, or did you bottleneck on yourself?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time you led a project where you had no formal authority over the people involved.
?Describe a situation where you had to drive consensus across teams with different priorities.
?Tell me about a time you mentored a peer or junior engineer who wasn't reporting to you.
?Walk me through how you got buy-in for a technical change that crossed team boundaries.
?Describe a time you had to influence a more senior engineer or stakeholder to change direction.
?Tell me about a time you tried to influence and it didn't work. What did you do?
?Describe a project where you had to coordinate work across people who didn't agree on the goal.

Sample STAR answers (preview)

The full library pairs strong and weak examples with notes on what makes each work (or fail). Here's how two of the strong stories open.

STRONG

Strong: Cross-team migration through influence

Prompt: "Tell me about a time you led a project where you had no formal authority over the people involved."

Situation: About a year ago at a fintech, I noticed our four backend teams were each implementing their own retry / idempotency logic for outbound webhooks. Three of the four had subtle bugs that were causing duplicate notifications to merchants. There was no platform team, no designated owner, and no roadmap line item for fixing it. I was a senior engineer on one of the four teams.
Result: All four teams adopted within 5 months. - the full Task → Action → Result walkthrough and the "why this works" notes are in the member version.

STRONG

Strong: Influence didn't work, escalated cleanly

Prompt: "Tell me about a time you tried to influence and it didn't work. What did you do?"

Situation: On a previous team, I was the senior engineer on a system that depended on a partner team's API. I'd flagged for two months that their error-handling contract was under-specified - they returned 500s for transient errors and 400s for client errors, but used 500s for some genuinely client-side problems. This made our retry logic incorrect in a way that was already causing low-volume bugs.
Result: Joint fix shipped 6 weeks later. - the full Task → Action → Result walkthrough and the "why this works" notes are in the member version.

What's in the full theme

3 full STAR answers (strong and weak, with interviewer notes) · 7 common pitfalls · 6 follow-up strategies

The full STAR library for this theme is part of Premium

Unlock it with a subscription.

Start Your 7-Day Trial

Try everything free for 7 days. Cancel anytime.

Every behavioral theme's strong and weak answers, pitfalls and follow-ups
Coach critiques on your own stories (40 a month)

View Plans

7-day trial, then $8/mo - or $48/yr ($4/mo, save 50%). Cancel anytime.

Related behavioral themes

Ownership

Amazon LP

Tested at every level, scored harder at senior. Did you take responsibility for outcomes - or just for tasks?

FREE

Conflict

General

The most universal behavioral question. Tested everywhere. The signal is in how you investigate the disagreement, not in how you 'won.'

Ambiguity

General

Tested at Google, Anthropic, OpenAI, and any senior+ loop. Strong candidates show how they get curious; weak candidates show how they get anxious.

Companies that test this theme

Google

L5 Senior Software Engineer

Google

L6 Staff Software Engineer

Practice these stories live

Reading STAR answers is the floor. The interview signal is in delivering them out loud, with follow-ups, under pressure. Write your own Influence story first, then say it out loud in a behavioral mock - Alex reads your story bank.

Write your Influence story →Practice it in a behavioral mock →

GeneralAdvanced Premium

Leadership Without Authority

The senior+ signal. Can you drive cross-team work, mentor, and build consensus when nobody reports to you - or do you only execute when given a mandate?

About this theme

What interviewers are evaluating

→Did you actually have to influence, or did you have implicit authority via your manager / project priority?
→Did you build shared context before asking for commitment, or did you push your conclusion?
→Did you earn credibility with concrete proof points (prototype, data, scoped pilot), or just argument?
→When people disagreed, did you investigate their reasoning, or label them as blockers?
→Did you mentor or grow others as a side effect, or only extract their effort?
→When influence wasn't working, did you escalate cleanly - or either give up or go around?
→At senior+ levels: did you scope the work so others could own pieces, or did you bottleneck on yourself?

Common prompts

Variations on these are asked at every level. Have a story pre-loaded for at least three of them.

?Tell me about a time you led a project where you had no formal authority over the people involved.
?Describe a situation where you had to drive consensus across teams with different priorities.
?Tell me about a time you mentored a peer or junior engineer who wasn't reporting to you.
?Walk me through how you got buy-in for a technical change that crossed team boundaries.
?Describe a time you had to influence a more senior engineer or stakeholder to change direction.
?Tell me about a time you tried to influence and it didn't work. What did you do?
?Describe a project where you had to coordinate work across people who didn't agree on the goal.

Sample STAR answers (preview)

The full library pairs strong and weak examples with notes on what makes each work (or fail). Here's how two of the strong stories open.

STRONG

Strong: Cross-team migration through influence

Prompt: "Tell me about a time you led a project where you had no formal authority over the people involved."

Situation: About a year ago at a fintech, I noticed our four backend teams were each implementing their own retry / idempotency logic for outbound webhooks. Three of the four had subtle bugs that were causing duplicate notifications to merchants. There was no platform team, no designated owner, and no roadmap line item for fixing it. I was a senior engineer on one of the four teams.
Result: All four teams adopted within 5 months. - the full Task → Action → Result walkthrough and the "why this works" notes are in the member version.

STRONG

Strong: Influence didn't work, escalated cleanly

Prompt: "Tell me about a time you tried to influence and it didn't work. What did you do?"

Situation: On a previous team, I was the senior engineer on a system that depended on a partner team's API. I'd flagged for two months that their error-handling contract was under-specified - they returned 500s for transient errors and 400s for client errors, but used 500s for some genuinely client-side problems. This made our retry logic incorrect in a way that was already causing low-volume bugs.
Result: Joint fix shipped 6 weeks later. - the full Task → Action → Result walkthrough and the "why this works" notes are in the member version.