The short answer
Situation, Task, Action, Result β but the proportions are the whole technique. Two sentences of context, most of the answer on what you personally did, and a closing result the interviewer can picture. Build six to eight stories rather than an answer per question, and practise re-pointing each story at a different question.
What matters most
- Situation and task are context, not content β two or three sentences between them.
- Action is the answer. Most of your speaking time belongs there, in the first person.
- Build six to eight versatile stories, not one answer per question.
- A result that went badly is usable, provided you can say what changed afterwards.
What each letter is for
The four parts do different jobs, and confusing them is the root of most weak answers. Situation and task exist so the interviewer can follow you. Action exists so they can assess you. Result exists so they can believe you.
- Situation
- Where you were, roughly when, and what was going on. One or two sentences. The interviewer does not need the org chart, the project code name or the history of the account.
- Task
- What you specifically were responsible for. This is the sentence that separates you from your team, and skipping it is why so many answers dissolve into "we".
- Action
- What you did, in sequence, with the reasoning attached. This is the part being scored. If your answer were cut in half, this is the half to keep.
- Result
- What happened, stated plainly, with a number where an honest number exists. Then, if it helps, what you took from it.
A rough guide to timing: in a two-minute answer, aim for about twenty seconds of situation and task combined, seventy to eighty seconds of action, and twenty to thirty seconds of result. Most people invert that without noticing, because the situation is the easiest part to talk about and the action is the part that requires you to have thought about your own decisions.
The proportion problem, shown
The same story, told two ways. Only the balance changes.
We had a big problem with our onboarding flow. It had been built years ago by a team that had mostly left, and there was a lot of legacy code in it, and the product manager at the time had wanted it to do several things at once. Marketing was unhappy because sign-ups were falling, and support was unhappy because they were getting tickets. Anyway, we looked at it and eventually we fixed it and things got better.
Sign-ups through our onboarding flow had been sliding for two quarters and nobody owned it. I took it on. I pulled the funnel data first and found the drop was concentrated at one screen β a verification step that timed out on slow connections. I rewrote that step to retry in the background instead of failing, shipped it behind a flag to ten per cent of traffic, and watched it for a week before rolling it out. Completion on that screen went from sixty-one per cent to eighty-four, and the related support tickets stopped almost entirely.
Build a story bank, not an answer list
Preparing one answer per question is a losing game, because the question will be phrased differently than you rehearsed and you will be left trying to force a script onto it. Interviewers can hear that happening. Preparing stories instead is both less work and more flexible: six to eight well-developed situations will cover the overwhelming majority of behavioural questions, because the questions are drawn from a small set of underlying competencies.
- 1List the raw material
Go through the last three to five years and write down every situation that had friction in it: a project that nearly failed, a disagreement, a deadline, a decision made without enough information, something you changed that others resisted, something you shipped that you were proud of.
- 2Keep the eight with the most in them
A good story has more than one competency inside it. A project that was late, that you took over, that involved persuading a sceptical stakeholder, and that ended with a measurable result can answer four different questions.
- 3Write each one out in full, once
Longhand, in STAR order. You will never deliver it in that form, but writing it forces you to find the result, and to notice where your own actions are vague.
- 4Tag each story with the questions it answers
Conflict, leadership, failure, ambiguity, influence without authority, prioritisation, customer focus, learning something quickly. Most stories carry three or four tags.
- 5Practise the pivot, not the recital
Take one story and open it four different ways for four different questions. The middle stays the same; the first sentence and the last sentence change to answer what was actually asked.
Our interview prep tool runs through a bank of practice questions and gives you somewhere to draft and store STAR answers, which is a faster way to do step three than a blank document.
Where STAR answers go wrong
| Failure | What the interviewer hears | Fix |
|---|---|---|
| Speaking entirely in "we" | That you may have been present rather than responsible | Say what the team did once, then switch to "I" for everything you personally decided or built |
| No result at all | That the story might not have worked | End on an outcome even when it is not a number: a decision made, a process adopted, a client retained |
| A result with a number that means nothing | Padding | Give the baseline as well. "Up forty per cent" is unreadable without knowing forty per cent of what |
| Situation that runs a minute | That you cannot judge what matters | Cut to: what was happening, why it was a problem, and that it landed on you |
| A story from eight years ago | That nothing notable has happened since | Prefer recent material unless the old story is genuinely your strongest and you say why you have gone back |
| The same story three times | That you have one achievement | This is what the tagging step in the bank prevents |
STAR is not for every question
The framework belongs to behavioural questions β the ones that begin "tell me about a time", "give me an example", or "describe a situation where". It is the wrong shape for several other question types, and applying it anyway is a common and very audible mistake.
- Hypotheticals. "How would you approach a launch with no marketing budget?" wants your reasoning, not a story. Answer the question, then offer a relevant example if one exists.
- Opinion and motivation questions. "Why this role?" or "what kind of manager do you work best with?" are not asking for evidence of a past incident.
- Technical questions. These want a demonstration. See our guide on behavioural versus technical interviews for how the two formats differ in preparation.
- Anything you can answer in one sentence. Not every question deserves two minutes, and treating a small question as a large one wastes the time you needed for a large one.
The structured interview behind the framework
STAR is popular partly because so many employers now run structured interviews: a fixed set of questions asked of every candidate, scored against a written rubric. The US Office of Personnel Management publishes its guide to structured interviews for federal hiring, and it is a useful thing for a candidate to read, because it shows the machinery from the other side β the competencies, the anchors, the reason your interviewer is writing while you talk.
The practical consequence is that a rambling answer is not merely less pleasant to listen to; it is harder to score, and an unscoreable answer tends to be scored low. Signposting helps. Naming the competency at the top of your answer β "this is an example of pushing back on a stakeholder" β costs three seconds and tells the person with the rubric which box you are aiming at.
A short checklist before you speak
- You know which of your eight stories you are about to use.
- The context will take two sentences, not six.
- There is a sentence early on that says what you personally were responsible for.
- The middle is a sequence of things you did, with the reasoning attached.
- There is an ending, and it is a result rather than a fade-out.
- You can say the whole thing in about two minutes.
- You have a second, different story ready if they ask for another example.
The stories are also the raw material for your resume bullets, and the traffic goes both ways: if a story will not compress into a strong bullet, it is usually because the result is missing. Our guide to quantifying achievements covers finding a defensible number, and the resume builder is where to put them once you have.
Questions people actually ask
Is the STAR method still used?
Yes, and more than ever, because structured interviewing has become standard at large employers. When an interviewer is scoring against a written rubric, an answer with a clear situation, action and result is simply easier to mark than a discursive one.
How long should a STAR answer be?
About ninety seconds to two minutes. If you are past two and a half minutes you have almost certainly over-explained the situation. Watch the interviewer: if they have stopped writing, you have finished and they are waiting.
What if I have no work example for a question?
Use one from study, volunteering, contract work, a side project or a previous industry. Say where it comes from rather than disguising it. An honest example from outside paid employment is far stronger than a vague one from inside it.
Should I say STAR out loud in the interview?
No. Naming the framework is unnecessary and slightly stilted. Signposting the competency is useful; announcing the method is not.
Can I use the same story twice in one interview?
Once, if you flag it: say you are returning to the same project but looking at a different part of it. Twice starts to suggest a thin bank, which is the reason for preparing six to eight rather than two.
Is STARL different from STAR?
Only in emphasis. The L stands for "learned" and simply makes explicit what a good result section already does when the outcome was mixed. Use whichever label you find easier to remember.
