To answer “tell me about a time you showed leadership” without a manager title, pick a real moment when you moved people or a decision forward without authority over them: unblocking a stalled project, mentoring someone, winning a technical argument with data, or coordinating an incident. Tell it in two to three minutes, spend most of that time on how you got others to act, use “I” for your own moves, and end with a concrete result. Then match the scope to the level: a new grad leads a task or a teammate, a senior engineer leads across teams.
What the interviewer is actually testing
Engineering interviewers are not asking whether you have managed people. They want to know whether you step up when something needs an owner, and whether other people follow when you do.
Google has been explicit about this. In Thomas Friedman's 2014 New York Times column “How to Get a Job at Google,” Laszlo Bock, then Google's senior vice president of people operations, said the company looked for emergent leadership rather than titles: stepping in to lead when a team problem calls for it, then stepping back when your part is done. Former interviewers commonly report that leadership is still one of the attributes Google scores for engineers, though the internal rubric is not public.
Amazon says it evaluates candidates through the lens of its 16 Leadership Principles, and a leadership question usually touches several at once: Ownership (leaders never say it is not their job), Earn Trust, Have Backbone; Disagree and Commit, and Hire and Develop the Best for mentoring stories. Our Amazon Leadership Principles examples show how to angle one story toward each.
Across companies, a strong answer gives evidence of five things:
- Initiative — you noticed the gap and acted before anyone assigned it to you.
- Influence — you got people who did not report to you to change what they were doing.
- Judgment — you picked a sensible course and can explain the tradeoff.
- Follow-through — something measurable changed because of it.
- Humility — you listened, adjusted the plan, and shared the credit.
Four leadership stories engineers already have
These four types cover nearly every variant of the question, from “tell me about a time you led a team” to “tell me about a time you took initiative.”
| Story type | What it looks like for an IC or new grad | Signal it sends |
|---|---|---|
| Leading without authority | Organizing a fix for flaky tests, slow builds or an outdated onboarding guide nobody owned; getting a stalled group project moving | Ownership, initiative, influence |
| Mentoring | Onboarding an intern or new hire, pairing with a struggling teammate, TA work, code reviews that taught something | Developing others, patience, clarity |
| Driving a decision | Writing a design doc or proposal, settling a library or architecture debate with data, changing a team norm | Judgment, backbone, persuasion |
| Incident response | Coordinating during an outage or a broken demo, running the postmortem, pushing the fix that prevents a repeat | Calm under pressure, bias for action |
Prepare at least two. You may get a second leadership-flavored question later in the loop, and reusing the same story weakens both answers.
A structure that holds up to follow-ups
STAR (situation, task, action, result) works, but leadership answers need a specific weighting. Amazon's own interview guide suggests about two to three minutes per story, personal actions told in “I” statements, and measurable outcomes. Budget the time like this:
| Part | Time | What to say |
|---|---|---|
| Situation | ~20 sec | Team, project, stakes. One or two sentences. |
| The gap | ~15 sec | What nobody owned, and why it mattered. This is what makes it a leadership story. |
| Action | ~90 sec | How you got others to move: the data you gathered, the proposal you wrote, the one-on-ones, the pushback you got and how you changed the plan. |
| Result | ~20 sec | A number, a deadline hit, or a lasting change in how the team works. |
| Reflection | ~10 sec | What you would do differently, or what you now do by default. |
The gap is the beat most candidates skip. Without it, the story sounds like you did your assigned job well; with it, the interviewer hears that you took on a problem outside your lane. For the base format with more worked stories, see our behavioral interview STAR examples.
Put the disagreement in. Leadership without friction sounds thin. If someone pushed back, say what their concern was and what you changed because of it. That one detail shows influence, judgment and humility at once.
Sample answers by level
These are illustrative answers to show shape and scope, not scripts. Swap in your own facts and numbers, and never claim a result you cannot explain in detail when asked.
New grad: getting a stalled class project moving
“In my senior capstone, four of us were building a course-scheduling app, and by week six the frontend and backend could not talk to each other because two of us had designed different API shapes. Nobody was the official lead, and the demo was four weeks out. I suggested we stop coding for an afternoon and agree on the contract. I wrote a draft API spec from what both sides had already built, walked the team through it, and we settled the three endpoints we disagreed on by checking which shape the UI actually needed. I also proposed two short integration check-ins a week so mismatches surfaced in days, not weeks. We demoed on time with every feature in our original scope working end to end. Next time I would push for the contract in week one instead of week six.”
Why it works: small scope, but a clear gap, a specific action that changed how the group worked, and a reflection that shows judgment.
Early career: coordinating an incident
“About six months into my first job, I was secondary on-call when checkout errors spiked on a Friday evening. The primary was debugging, and people from three other teams joined the channel asking for status and suggesting fixes at the same time, which kept pulling the primary away. I was not the most senior person there, but nobody was coordinating, so I said I would. I posted a status update every 15 minutes, asked one engineer to check the last deploy and another to check the database, and routed questions to me so the primary could focus. The deploy check turned up a bad config change, and we rolled it back about 40 minutes in. Afterward I wrote the blameless postmortem and proposed a config validation step in the deploy pipeline, which the team adopted. What I took from it: name someone to coordinate in the first five minutes, even when it is not obvious who should.”
Why it works: Google's SRE book recommends separating incident command, hands-on operations and communication so the person fixing the system is not also fielding questions, and writing blameless postmortems that fix systems rather than people. This story does both, unprompted.
Mid-level to senior: driving a decision across teams
“Three services in our org each used a different retry and timeout setup, and two incidents in one quarter traced back to mismatched timeouts between them. I owned one of the three services, not the others. I pulled the data from both postmortems into a two-page proposal for a shared client configuration and met each of the other tech leads one-on-one before the review. One lead pushed back hard: her team's batch jobs legitimately needed longer timeouts. She was right, so I changed the design to allow per-caller overrides on top of shared defaults. I migrated my own service first as the reference, then paired with one engineer from each team on theirs. All three moved over within the quarter, and we had no timeout-related incidents in the two quarters after. If I did it again, I would bring the other leads in before writing the draft, not after.”
Why it works: cross-team scope, influence with no authority, a real objection that changed the plan, and a result measured over time.
How scope signals seniority
The same question gets graded differently at different levels. Interviewers listen for how far your influence reached: your own task, your team, or several teams. Public engineering ladders make this explicit. Dropbox's published career framework, for example, has its entry level (IC1) executing defined tasks with specific guidance from a manager or tech lead, says IC2 engineers may mentor new hires and interns, lets IC3 engineers act as tech lead for projects on their team, and describes IC4 impact as starting to extend outside the team through cross-team initiatives. Level names and expectations vary by company, so treat the table below as a general guide rather than any one company's rubric.
| Target level | Story scope | Who you moved | Good example |
|---|---|---|---|
| Intern / new grad | A task, a class or internship project | Classmates, fellow interns, one teammate | Unblocked a group project; wrote the onboarding guide the next intern used |
| Early career | A feature or an incident on your team | Your team, occasionally a partner team | Coordinated an incident; drove a design choice your team adopted |
| Mid-level | A multi-phase project | Your team plus cross-functional partners | Tech lead for a project; mentored a newer engineer through a first launch |
| Senior | Work that spans teams | Other teams' engineers and leads, your manager's peers | Drove a shared standard, migration or process across teams |
Two rules follow. Pick the story whose scope matches the level you are interviewing for, even if a smaller story is more dramatic. And if your best story is smaller than the level, do not inflate it: a stretched story falls apart under follow-ups faster than a modest one told straight.
If you think you have no leadership story
You are probably looking for the wrong shape. Run through these questions and write down anything that comes to mind:
- Did you fix something nobody owned, with other people's help? Broken docs, flaky tests, a slow build.
- Did you teach someone something that changed how they worked? A new hire, an intern, a student you TA'd.
- Did you argue for a technical choice with data and change the outcome, or lose the argument and commit anyway?
- Were you the person who kept things organized during a bad hour? An outage, a failed demo, a hackathon at 3 a.m.
- Did you run something? A standup while your lead was out, a retro, a study group, a club project.
Pick the two with the clearest result and the most people involved. Internship and school examples are fine early in your career; the same advice applies when you describe a challenging project.
Mistakes that sink leadership answers
- The “we” story. “We decided, we built, we shipped” leaves the interviewer nothing to score. Use “I” for your own moves and “we” only for shared outcomes.
- Title as proof. “I was the team lead, so I assigned the tasks” describes a role, not leadership. Show a moment where the title did not do the work for you.
- The hero who went around everyone. Rewriting a teammate's code over a weekend without telling them may have worked, but it fails the trust test. Influence counts; overriding people does not.
- A vague result. “It went really well” is not a result. Use a number, a date hit, or a lasting change in how the team works.
- Never stepping back. Stories where you kept control after your part was done miss the point of emergent leadership: good leaders also hand off.
- A long setup. If the action has not started by the 45-second mark, cut context.
Follow-up questions to prepare for
Interviewers dig into leadership stories to check that they are real and that the actions were yours. Have a one- or two-sentence answer ready for each:
- Why did you step in instead of raising it with your manager?
- Who disagreed, and what did you change because of their concerns?
- What would have happened if you had not done it?
- How did you know it worked? What did you measure?
- Does the change still hold without you, or did it depend on you?
- What would you do differently next time?
The fastest way to find weak spots is to tell the story out loud. Have a colleague fire these questions back at you, or run a free AI mock interview in CoPilot Interview: paste the job description and your résumé, choose behavioral questions, answer out loud, and each answer gets a score with what worked and what to improve.
Rehearse your leadership story out loud
Paste a job description and your résumé, pick behavioral questions, and answer an AI interviewer out loud; each answer is scored with what worked and what to improve. The free plan gives you 15 minutes a day with no credit card.
Try a free AI mock interviewFAQ
What if I have never been a manager or team lead?
Use a story where you led without authority: you fixed something nobody owned, mentored someone, drove a technical decision or coordinated an incident. Amazon's interview guide calls its Leadership Principles the foundation of every hiring decision, engineers included, and Google's former people chief described looking for emergent leadership rather than titles.
Can new grads use school or internship examples?
Yes. Internship stories are usually strongest, but capstone projects, hackathons, TA work, open source and club projects all work if you can name the gap, what you personally did and a concrete result.
How long should a leadership answer be?
Aim for about two to three minutes, the range Amazon's own interview guide suggests per story. Keep the setup under 30 seconds and spend most of the time on what you did to get others moving.
Is mentoring a good leadership example?
Yes, as long as you show what changed for the person you mentored and how you adjusted your approach for them. At Amazon it maps to the Hire and Develop the Best principle.
How is a leadership question different from a conflict question?
A leadership question is about moving a group toward an outcome, while a conflict question is about resolving a disagreement with a specific person. The stories can overlap, but prepare separate ones so you do not repeat yourself in the same loop.