The STAR method, and when it gets in the way
3 min read
Situation, Task, Action, Result is a good scaffold and a bad script. How to use it so answers stay specific, and the three places it reliably makes people worse.
STAR — Situation, Task, Action, Result — is the standard advice for behavioural questions, and it is mostly good advice. It stops the commonest failure, which is answering "tell me about a time you disagreed with a colleague" with a general philosophy of disagreement rather than an actual time.
But it is a scaffold, not a script. Used as a script it produces answers that are technically complete and completely forgettable.
The version that works
Situation — one or two sentences. Enough context that the rest makes sense. Not the org chart.
"We had a nightly job that reconciled payouts, and it had started failing about once a week."
Task — often one sentence, sometimes none. What was actually on you. If the situation already made that obvious, skip it. Nobody has ever complained that an answer was too short.
Action — this is the answer. Sixty to seventy percent of your words. What you did, in enough detail that someone could picture it. This is where interviewers decide whether you did the work or watched it happen.
Result — one or two sentences, with a number if you have one. And if you don't have a number, say what changed anyway. "It stopped failing" is a result.
Where it goes wrong
The situation eats the answer. People are most comfortable describing context, so they spend ninety seconds on background and twenty on what they did. Interviewers are listening for the actions. If you find yourself still explaining the team structure after three sentences, you have gone wrong.
"We" instead of "I". The most expensive word in a behavioural interview is "we". It is honest — most work is collective — but the interviewer is trying to establish what you contributed. Say "the team decided X, and I owned Y". You can be generous about credit and still be clear about your part.
Rehearsed to death. An answer delivered word-for-word from memory sounds like it, and it collapses the moment the interviewer asks something adjacent. Learn the beats, not the sentences.
When not to use it
STAR is for "tell me about a time". It is the wrong tool for at least three common questions:
- "How would you approach X?" is hypothetical. There is no situation. Answer with your actual approach, then optionally ground it in a time you did something similar.
- "What's your biggest weakness?" is not a story question. Forcing a STAR narrative onto it is how people end up with the humble-brag answers everyone can see through.
- "Why do you want to work here?" needs a reason, not an anecdote.
Building a stock you can actually draw on
Most people prepare six polished stories and then get asked about something else. A better use of the same hour: list eight to ten things you have actually done, in two lines each. Not polished. Just the raw material.
Then, for each, note which questions it could answer. One good project usually covers conflict, ambiguity, failure, and influencing without authority — the same events, framed differently.
The goal is not to have an answer ready. It is to be able to find one quickly when the question is not the one you expected.
The thing that decides it
Specificity. Two candidates describe the same project; one says "I improved the reliability of a critical pipeline" and the other says "I added a dead-letter queue so the failures stopped taking the whole run down with them." Only one of those could have been invented on the spot.
The way to find out whether an answer is specific enough is to say it out loud to something that will ask a follow-up. Rehearse against the role and see which stories survive the second question.
