STAR is the most-taught and most-misused interview framework in existence. Every career coach mentions it. Every candidate nods. Then, on the call, they spend three minutes on Situation, thirty seconds on Action, and forget to mention a Result. The interviewer writes "rambles, no impact stated" and moves on.
Here's what STAR actually looks like when done correctly — and ten real examples to pattern-match against.
The framework, more honestly
STAR stands for:
- Situation — the context. 1–2 sentences.
- Task — your specific responsibility. 1 sentence.
- Action — what you (not "we") did. 3–5 sentences. This is the meat.
- Result — the outcome, with a metric if possible. 1–2 sentences.
The single biggest mistake is inverting the ratio. Most candidates do 60% Situation + 30% Action + 10% Result. You want 10% S + 10% T + 60% A + 20% R.
The second biggest mistake is saying "we" throughout the Action. Interviewers don't hire "we." They hire you. Switch to "I" even when the work was collaborative. "I led the migration" is a stronger signal than "We did the migration."
The 10 prompts every candidate should be ready for
Behavioral interviews recycle a small set of archetypes. If you have solid STAR answers to these 10, you can adapt to 90% of real prompts:
- Tell me about a time you led a project.
- Tell me about a time you disagreed with your manager.
- Tell me about a time you failed.
- Tell me about a time you had to handle conflict on a team.
- Tell me about a time you missed a deadline.
- Tell me about a time you took on something outside your role.
- Tell me about a time you had to influence without authority.
- Tell me about a time you had to make a decision without enough data.
- Tell me about a time you gave difficult feedback.
- Tell me about a time you received difficult feedback.
Write down your best story for each. Then compress each to 90 seconds. Rehearse them out loud. This is not optional — the prompts will come, and you want the muscle memory.
10 worked examples
Here's one example per archetype, compressed. Each is ~90 seconds out loud.
1. Led a project
S: Last year my team inherited a billing service that was failing reconciliations weekly. T: I was asked to lead a rewrite without slowing down our existing roadmap. A: I scoped the work into three phases, negotiated a six-engineer loan from the platform team for eight weeks, set up a parallel-run infrastructure so we could compare old and new outputs daily, and ran a weekly risk review with finance and engineering. I personally owned the event-sourcing design and the cutover plan. R: We shipped in 10 weeks with zero billing incidents during cutover, and reconciliation failures dropped from 4/month to 0 over the next quarter.
2. Disagreed with your manager
S: My manager wanted to ship a new feature behind a hard launch date; I believed we hadn't validated the core assumption. T: I needed to push back without derailing the timeline or the relationship. A: I wrote a one-page doc with the two pieces of customer-research data we had, proposed a 2-week user test as a pre-launch gate, and offered to run it myself on top of my existing work. I presented it as an option, not an ultimatum. R: She approved the test. The test showed the flow was unclear for 40% of users; we fixed it pre-launch, and the feature hit its adoption goal in the first month instead of missing by a mile.
3. Failed
S: Two years ago I led a deprecation of a legacy service. T: I was supposed to coordinate the cutover with three dependent teams. A: I sent the migration doc, assumed silence meant agreement, and set a cutover date. On cutover day, one team had missed the doc — their staging integration broke, and we rolled back. R: We delayed two weeks. I rewrote our migration playbook to require explicit written sign-off from each downstream team before a cutover date is set. We've used that playbook for five migrations since, zero surprise rollbacks.
4. Handled team conflict
S: Two engineers on my team had a months-long technical disagreement about our API design that was stalling reviews. T: I was the tech lead and needed to resolve it before it poisoned the team. A: I scheduled a 45-minute design review, asked each to prepare a one-page proposal, and we walked through both on a whiteboard. I rephrased each side's core concern in the other's words until both agreed I'd understood. Then I made a decision and documented the tradeoffs. R: Review velocity doubled the next sprint. One of the two later told me the meeting was the first time he felt heard on the issue.
5. Missed a deadline
S: Our team committed to a Q2 launch for a data pipeline. T: I was responsible for the ingest layer. A: Midway through Q2 I realized I'd underestimated the schema-migration work and was going to miss by three weeks. I flagged it to my manager immediately, rebuilt the estimate with explicit assumptions, and proposed scoping down the first launch to one source instead of three. R: We shipped on the original date with one source, added the other two the next sprint. I now add a 20% buffer to ingest-layer estimates and force myself to break down migration work before committing.
6. Took on something outside your role
S: Our team didn't have a designer assigned to a internal admin tool. T: I was the engineer, not the designer, but the tool was unusable. A: I spent two evenings learning Figma basics, wireframed the four key flows, and ran a 30-minute walkthrough with three power users. I iterated twice based on feedback, then built the frontend. R: Ticket volume to our team from admin-tool users dropped by 60% the first month. Our design team adopted two of the patterns from that tool in other internal products.
7. Influenced without authority
S: Our mobile app was shipping features that depended on backend changes I thought should happen in a different order. T: The backend team was in a different org; I had no authority over them. A: I wrote a sequencing proposal with explicit dependency math, sent it to the backend tech lead with a "would love your feedback" note, and invited him to our next planning. I didn't frame it as a blocker — I framed it as a question. R: The backend team reordered their roadmap, and the joint launch shipped two weeks earlier than the original path would have.
8. Made a decision without enough data
S: We had an incident where one of two downstream systems was sending corrupted data, but we couldn't tell which in time. T: I was on call. A: I took the more conservative path — paused ingest from both, notified the affected customer teams with a 2-hour ETA, and isolated the problem via staged replay. R: We identified the source in 90 minutes, resumed ingest from the healthy system within the ETA, and the bad system's data didn't pollute our warehouse. I'd rather over-pause than under-notify.
9. Gave difficult feedback
S: A senior peer on my team was repeatedly dismissive in code reviews, especially to junior engineers. T: I noticed two juniors had started avoiding reviewing with him. A: I asked for a 1:1, opened with a specific example, and described the impact I was seeing — not accusations, just observations and their effects. I asked if he'd noticed. He hadn't. We talked about review language and agreed to a review check-in in three weeks. R: Junior engineers started re-engaging within two weeks. He later told me he'd appreciated the directness.
10. Received difficult feedback
S: In a performance review my manager said my design docs were too long and burying the key decisions. T: I needed to take it seriously, not rationalize. A: I asked her for two examples. She showed me. I rewrote one of my recent docs with an explicit "Decisions" section at the top, sent it to her for feedback, and adopted the pattern across all future docs. I also asked two peers to flag it if I slipped. R: Review-cycle time on my docs dropped by about half, and I've used that pattern in every team I've joined since.
Common STAR mistakes to avoid
- "We" instead of "I" — the most common, the most damaging
- Skipping the Result — no metric, no impact, no closure
- Picking stories where you weren't actually the main actor — if the Action is mostly someone else's, pick a different story
- Inventing stories — experienced interviewers can smell fabrication. Real stories with smaller stakes always beat fake stories with big stakes.
- Not having a failure story — everyone asks. "I've never failed" is a red flag.
Where to go next
- Pair these stories with the how to answer behavioral questions guide for the universal-stories framework
- For technical roles, see the system design interview cheatsheet
- Role-specific prompts in the software engineer interview questions and product manager interview questions guides
- Structure your resume bullets using the same impact pattern — the data scientist resume example is a good reference
The bottom line
STAR is not complicated. The discipline is. Write down your 10 stories. Compress each to 90 seconds. Practice them out loud until they feel natural but not rehearsed. Use "I." End with a metric. Do this, and you'll be in the top 10% of candidates by structure alone.
