In the last lesson we saw that a behavioural interviewer is collecting evidence of specific signals. STAR is the structure that delivers that evidence cleanly, every time, under pressure. It is to the behavioural round what the 4-phase framework is to system design: a flexible scaffold that keeps a rambling answer from happening.
The four parts — and the time each deserves
STAR stands for Situation, Task, Action, Result. The parts are not equal. The most common failure is spending three minutes on backstory and ten seconds on what you actually did. Flip that.
| Part | Share | What goes here |
|---|---|---|
| Situation | ~10% | One or two sentences of context. Just enough for the stakes to make sense. |
| Task | ~10% | Your specific goal or responsibility. What were you on the hook for? |
| Action | ~60% | The heart. The concrete steps you took, in order, with the reasoning behind the key decisions. |
| Result | ~20% | The outcome — ideally with a number — and what you learned. |
A good spoken answer is two to three minutes. That’s long enough to show depth, short enough to leave room for the follow-up questions where the real evaluation happens.
Situation and Task: set the scene fast
The interviewer does not need your org chart. They need just enough to understand why the problem mattered. “Our checkout service was timing out during peak sale hours, costing us conversions” is a complete Situation. Resist the urge to explain the entire system first.
The Task is your personal mandate. “I was asked to reduce checkout latency” or, better at senior level, “I noticed the pattern in our incident data and took it on myself to fix it.” The Task is where you plant the first seed of ownership.
Action: this is the answer
Sixty percent of your words belong here, because this is what the interviewer is scoring. Three rules:
- Say “I”, not “we”. “We decided” tells the interviewer nothing about your contribution. “I proposed X, the team pushed back on cost, so I prototyped it over a weekend to show the saving” shows exactly what you did. You can absolutely credit the team — “I worked with our DBA to…” — but the subject of the key verbs should be you.
- Walk through the decisions, not just the tasks. “I added caching” is thin. “I saw 80% of our reads were the same catalogue data, so I added a read-through cache with a short TTL, and chose write-through invalidation over TTL-only because stale prices were unacceptable” shows judgement.
- Show the hard part. Every strong story has a moment of difficulty — a trade-off, a disagreement, a constraint. Linger there. That’s where the signal lives.
Result: never skip it
An answer with no result is a story with no ending, and it is the most common reason strong experience scores poorly. Quantify if you possibly can: “cut p99 from 800ms to 120ms,” “reduced on-call pages by 60%,” “shipped two weeks early.” If you genuinely can’t measure it, describe the concrete outcome: “the feature shipped and is still the default flow today.” Then add the learning — one sentence on what you’d do differently or what you took forward. The learning is what turns a result into evidence of growth.
A full worked example
Here’s a complete STAR answer to “Tell me about a time you had to deliver under a tight deadline.” Notice the proportions.
(Situation) Last year our biggest client gave us six weeks’ notice that they’d churn unless we supported SSO, which we’d always deprioritised.
(Task) I was the senior engineer on the identity team, and I owned getting SSO shipped and certified before their renewal date.
(Action) The obvious path — building SAML and OIDC from scratch — was a three-month job, so I ruled it out immediately. I evaluated two managed identity providers in two days, and chose the one that let us keep our existing user table instead of migrating. The risk was our legacy session logic, so I spent the first week writing a compatibility layer and a migration script with a dry-run mode, and I got our two other backend engineers to review it in a single focused session rather than piecemeal. When we hit a blocker with the client’s Okta config mid-way, I set up a shared Slack channel with their IT team and drove the debugging directly instead of going through account management, which saved us about four days.
(Result) We shipped SSO in five weeks, one week before the deadline, and passed their security review on the first pass. The client renewed a $1.2M contract. Afterwards I wrote up the compatibility layer as an internal pattern, and two other teams reused it the next quarter.
That’s roughly 200 words — about ninety seconds spoken — and the Action is clearly the bulk of it. It deposits ownership, judgement (buy vs build), impact (shipped early, $1.2M renewal), and even a bit of scope (the pattern others reused).
The three STAR mistakes
- Front-loading the Situation. If you’re a minute in and haven’t said what you did, you’ve lost them. Cut the backstory ruthlessly.
- Hiding in “we.” A whole Action in the first-person plural is a red flag — it reads like you’re borrowing someone else’s work. Be specific about your part.
- No Result. Ending on “…and then we moved on” wastes the whole setup. Always land the outcome.
Follow-up questions dig into the Action
A good interviewer won’t just accept your story — they’ll probe it: “Why did you choose the managed provider over building it?” “What did the other engineers push back on?” “What would you do differently?” These follow-ups are where levelling happens, and they almost always target the Action. This is the real reason your Action needs genuine detail and real decisions behind it: a rehearsed summary collapses the moment someone asks “why.” Know your stories deeply enough that you can go one or two layers deeper than the headline on any part of the Action.
Key Takeaways
- Structure every answer as Situation (10%), Task (10%), Action (60%), Result (20%).
- The Action is the answer — spend your time there, say “I”, and walk through the decisions, not just the tasks.
- Always close with a Result, quantified if possible, plus one line on what you learned.
- Keep it to two to three minutes; follow-up questions dig into the Action, so that’s where your depth should live.
Next: Lesson 3 — Building Your Story Bank, so you always have the right story ready.