STAR method
Situation, Task, Action, Result: a structure for behavioural interview answers. Spend most of the time on what you did and what changed, with numbers.
STAR is a way to tell a work story in an interview: the Situation (context), the Task (what needed doing and why it was yours), the Action (what you did, step by step), and the Result (what changed, with numbers). Interviewers at companies like Amazon, Google and Meta use behavioural questions ('tell me about a time you disagreed with a decision') and score how clearly you show your own judgement. STAR keeps the answer focused and under three minutes.
A good bug report: what was happening, what was expected, what you did, what happened next. Nobody wants the full history of the codebase first.
Saying 'we' throughout. The interviewer is scoring you, and if they can't tell what you personally decided, they have to assume you didn't.
The common failure is proportion: two minutes of situation, thirty seconds of action, no result. Aim for roughly 15% Situation, 10% Task, 55–60% Action, 15–20% Result in a 2–3 minute answer. Action must be first person and specific: decisions, trade-offs, who you persuaded and how; 'we' hides your contribution, so say what the team did and then what you did. Result needs a baseline and an after with the sample size and timeframe ('p95 from 4.1 s to 1.8 s over 6 weeks on 40k daily queries'), plus what you'd do differently, which signals reflection. Senior and staff loops expect scope signals: team size, number of teams affected, a dissenting stakeholder, and the Blast radius of the decision. Prepare 6–8 stories that each map to several common prompts (conflict, failure, ambiguity, influence without authority, delivering under a deadline) and rehearse them aloud with a timer. Amazon explicitly maps behavioural questions to its Leadership Principles, so tag each story with the principles it shows.
6–8 prepared stories, each 2–3 minutes; ~15/10/55/20 split across S/T/A/R; first-person actions; result with baseline → after, sample size and timeframe; one dissenting stakeholder; one 'would do differently'; each story tagged to the prompts and leadership principles it answers.
Q: 'Tell me about a time you shipped something that went wrong.' S (20 s): 'Our code-search assistant served ~40k queries/day across 300 engineers.' T (15 s): 'I owned the switch to a new embedding model.' A (90 s): 'I ran an offline eval on 500 queries, saw +6 points recall, and shipped via alias swap. I didn't shadow it. Within a day, results for monorepo paths regressed. I rolled back in 4 minutes, traced it to the tokenizer splitting paths differently, added 200 path-heavy queries to the golden set, and persuaded the platform lead, who wanted to abandon the migration, to re-run with a shadow week.' R (30 s): 'Second rollout: +5 points recall, no regressions; shadow-before-swap became our team's rule. I'd have stratified the eval set by query type from the start.'
Prepare 6–8 stories with numbers, a dissenting stakeholder and a 'what I'd do differently', and rehearse them to 2–3 minutes with most of the time on Action. When asked a behavioural question, pick the story, say the one-line situation, and get to your decisions within 30 seconds. Expect probing follow-ups: 'what exactly did you do vs the team?' and 'what would you do now?'
Numbers worth knowing
- Answer length
- 2–3 minutesleaves time for follow-ups in a 45-minute loop with 3–4 questions
- Time on Action
- ~55–60%the part interviewers score
- Prepared stories
- 6–8each reusable across 3+ question types
How to decide
| When | Do this |
|---|---|
| Question is 'tell me about a time…' | STAR with a prepared story; one-line situation. |
| Story has no measurable result | Use a proxy (time saved, incidents avoided) or pick another story. |
| Senior/staff loop | Add scope: team size, teams affected, stakeholder you persuaded. |
| Asked about a failure | Own it, show the fix, and the process change it led to. |
Operating it
- Interviewing for senior/staff: stories need cross-team scope and influence, not just execution
- Same story used for 3+ prompts in one loop: prepare more
- Feedback says 'unclear individual contribution'
- Rehearsal timing: flag any story over 3 minutes
- Count of numbers per story: aim for ≥2 (baseline, after)
- Coverage matrix: each common prompt type covered by ≥2 stories
When it goes wrong
A strong engineer was rejected after a behavioural round with feedback 'couldn't assess ownership'.
Interview debrief notes: answers ran 5+ minutes, mostly context.
Unprepared stories, told chronologically, with 'we' throughout and no numbers.
Rewrote six stories in STAR with ~60% action, first-person decisions and baseline/after metrics; rehearsed with a timer. Next loop passed.
Sources
- Leadership Principles — Amazon, 2025docs
- Staff Engineer: Leadership beyond the management track — Will Larson, 2021book
Check yourself
Three questions. Every option is explained once you answer.