The STAR method
In one line
STAR (Situation, Task, Action, Result) turns a rambling memory into a two-minute story that proves what you did and what changed because of it.
What it is
STAR is a simple structure for answering behavioural questions, the ones that start with 'Tell me about a time when...'. You describe the Situation (the context), the Task (what you were responsible for), the Action (what you personally did) and the Result (what happened, ideally with a number).
Interviewers trust past behaviour as the best predictor of future behaviour. STAR makes your past behaviour easy to follow and easy to score, because each part answers a question the interviewer would otherwise have to ask.
Why interviewers ask
Most companies, from startups to Amazon and Google, score behavioural answers against a rubric: was the problem real, what did the candidate personally do, and was there a measurable outcome. A strong technical candidate can still fail this round by telling vague or 'we did' stories. STAR tests clarity, self-awareness and whether you can show impact.
How it works
- 1Situation (about 15 percent of the answer): one or two sentences of context. Team, product, timeframe, and why it mattered. Skip anything the listener does not need.
- 2Task (about 10 percent): your specific responsibility or goal. Make the stakes clear: a deadline, a metric, a risk.
- 3Action (about 60 percent): the steps you took, in order, using 'I' not 'we'. Include why you chose each step and one obstacle you handled. This is where you are scored.
- 4Result (about 15 percent): the outcome with numbers if possible (time saved, errors cut, users affected), plus what you learned or would do differently.
- 5Aim for 90 seconds to 2 minutes. Then stop and let the interviewer ask follow-ups; they will dig into the parts they care about.
Worked example · Question: Tell me about a time you improved something without being asked
- Situation: 'Last year I was a backend developer on a five-person team running an order API. Our CI pipeline took about 25 minutes per run, and people merged code only twice a day because of it.'
- Task: 'Nobody owned the pipeline, but it was slowing every release, so I set myself a goal of getting it under 10 minutes without dropping any tests.'
- Action, part 1: 'I first measured where the time went. I added timings to each stage and found that 14 minutes was the integration test suite, which ran tests one after another against a fresh database.'
- Action, part 2: 'I split the suite into four parallel jobs, gave each its own database container, and cached Python dependencies between runs. Two tests failed in parallel because they shared fixed IDs, so I fixed them to generate unique IDs.'
- Action, part 3: 'I shared the plan with my lead before switching over and kept the old pipeline as a fallback for a week in case the new one was flaky.'
- Result: 'Runs dropped from 25 minutes to 8. Merges went from about 2 to about 6 a day, and the old pipeline was removed after a week with no flaky failures. I learned to measure before optimising: my first guess was the Docker build, which was only 3 minutes.'
- Why this scores well: clear stakes, 'I' statements, a reason for each step, one obstacle handled, numbers in the result and a short lesson.
Picture it
STAR is like a short film trailer: a few seconds to set the scene, a clear goal for the hero, most of the time on the action, and an ending that shows what changed. Nobody wants a trailer that is all opening credits.
Key patterns
STAR + L (learning)
When: Failure, mistake or 'what would you do differently' questions
How: Add one or two sentences after the Result about what you learned and how you applied it later.
Lead with the result
When: The interviewer seems short on time or asks for a quick example
How: Open with a one-sentence headline ('I cut our CI time from 25 to 8 minutes'), then give STAR briefly.
One story, many questions
When: Preparing a story bank
How: Tag each story with the themes it shows (ownership, conflict, ambiguity) so one strong story can answer several different questions.
Real-world use
A technical win
A performance fix, a migration you led, or a bug you tracked down. Strong because you can quote numbers like latency, error rate or hours saved.
A people situation
Disagreeing with a teammate about a design, onboarding a new hire, or calming a frustrated stakeholder. Shows communication and empathy, which technical stories rarely do.
A failure or mistake
An outage you caused or a deadline you missed. STAR still works: the Result covers the fix and the lesson, and the Action shows how you owned it.
A student or early-career project
A final-year project, hackathon or internship task. Interviewers for junior roles expect these; the same structure and numbers (users, accuracy, marks) make them credible.
In a project
You have interviews in three weeks and want every behavioural answer to come out in clean STAR form instead of improvised.
- List 8-10 real experiences from the last few years: wins, failures, conflicts, things you led.
- For each, write one line per STAR letter in a notes app. Force at least one number into each Result.
- Rewrite every 'we' in the Action line as what you personally did.
- Say each story out loud with a timer; cut anything that pushes it past 2 minutes.
- Practise in a mock interview and ask for feedback on which part felt thin, usually Action or Result.
Impact: Answers become 90-second stories with clear personal impact, you stop freezing on 'tell me about a time' questions, and follow-up questions become easy because you already know the details.
Trade-offs
Use it when
- Any 'tell me about a time...' or 'give me an example of...' question
- Questions about strengths and weaknesses, where a short story proves the claim
- Follow-ups in technical rounds such as 'describe a hard bug you fixed'
Avoid it when
- Hypothetical questions ('what would you do if...'): answer the scenario, then optionally back it up with a short real example
- Simple factual questions ('why this company?'), where a rigid four-part story sounds rehearsed
- Spending more than a third of the time on Situation; it is the least scored part
Common mistakes
- Saying 'we' throughout, so the interviewer cannot tell what you personally did.
- Spending a minute on background and rushing the Action in two sentences.
- Ending without a result, or with a vague one like 'it went well' instead of a number or concrete change.
- Picking a story with no real challenge, so there is nothing to show.
- Memorising a script word for word, which sounds robotic and breaks under follow-up questions.
Interview questions
Quick revision
- S = context in 1-2 sentences. T = your goal and stakes.
- A = about 60 percent of the answer, in 'I' statements, with reasons.
- R = numbers, plus what you learned.
- Target 90 seconds to 2 minutes, then stop.
- Include one obstacle you handled; it makes the story real.
- Prepare 8-10 stories and reuse them across themes.
- Be honest: follow-up questions expose made-up details fast.
Check yourself
1. Which part of a STAR answer should usually take the most time?
2. A candidate says 'we redesigned the API and it worked out'. What is the main problem?
3. Which is the strongest Result statement?
4. How should you handle a hypothetical question like 'What would you do if a teammate missed deadlines?'
Saved on this device. Create a free account to keep it on every device.
Practise this with Sam
A real mock interview, out loud, with an honest scorecard. Free to start.