The question is simple: "Tell me about a time you solved a hard problem in production." The answer starts on a Tuesday. It moves through a red board, a war room, three logging tools and a YAML file that got changed twice. Two minutes later the interviewer knows a lot about the project and almost nothing about what you decided. The result never showed up.
That isn't a lack of experience. It's a lack of shape. When you tell the project in calendar order, the interviewer has to dig out what you did and what changed afterwards, and the clock usually runs out first. This post gives you something small on purpose: an eight-line STAR card, and a 90-second test on your phone's voice recorder that checks whether the result lands at the end.
The four letters and this post's clock
STAR stands for Situation, Task, Action and Result. Career centers such as Northwestern, Glasgow and Amherst use the same structure for behavioral questions, the "tell me about a time when…" kind. A senior Amazon recruiter also tells candidates to format their answers this way. The University of Washington's career page sums up what interviewers listen for: a specific situation, what you took on, what you did, and how it ended, including when it didn't go to plan.
None of these sources treat STAR as a script to memorize. Amherst and the Amazon recruiter both describe it as a way to organize your answer, not a text to recite.
The clock is a separate question. The 90 seconds, with the Result in the last ~20 seconds, and the eight-line card are this post's own editorial heuristics. They are not an official STAR measure. The career centers give similar advice, and none of it is a standard. Duke talks about answers of one to two minutes and calls the result the critical part. Illinois Tech's example is a story of about two minutes with roughly 20 seconds of Result. Northwestern suggests Action should take up half the answer and always be the longest part. We tighten it to 90 seconds because that limit forces you to cut the Situation, which is where the time usually goes, and it still sits comfortably inside Duke's range.
The chronological dump and the eight-line card
The case below is an editorial composite of a common production pattern: an HTTP timeout, a retry storm and a connection pool that's too small. It isn't the author's experience and there's no real client behind it. The numbers are configuration values from the scenario, not measured metrics.
First, the version that fails:
> "It started on a Tuesday, the board was red, someone opened a war room. The payments API is a Spring Boot service, we use RestTemplate, there was a Jira from last quarter about timeouts. I pulled logs in Grafana, then Kibana, then I sshed in — wait, I mean I used the dashboard. Billing was slow. We had retries. I think three retries. The Tomcat threads were busy. Hikari looked fine at first. Then I remembered a blog post about connection pools. We changed a YAML, reverted it, changed it again. The team was stressed. Eventually it calmed down. I learned a lot about resilience."
The Situation turns into a soap opera and the Task never appears. The Action wobbles between "we" and a tour of tools. The Result comes down to "it calmed down" and "I learned a lot". By the end, the interviewer can name three observability tools and not one decision you made.
Now the same incident in eight lines:
- S: Spring Boot API that calls billing over HTTP; the error rate jumped during a traffic spike; the on-call dashboard showed timeouts, not 4xx.
- T: Restore checkout without a blind restart, and stop amplifying load on billing.
- A: I captured one failing trace: 10 s client timeout, three immediate retries, Tomcat request threads stuck waiting.
- A: I cut in-flight retries to one, with backoff, and lowered the client timeout so the thread came back instead of piling up.
- A: I capped the HTTP client pool so new work queued instead of opening more slow calls.
- R: Timeouts stopped climbing within the incident window; checkout error rate went back to its pre-spike baseline on the same dashboard.
- R: I opened a follow-up change: retry budget and pool cap in config, with the trace as the justification. Not a new framework.
- R (optional spoken close): If I did it again, I'd put the retry budget in before the next peak, not during it.
At a normal speaking pace, lines 1 and 2 take about 15 seconds, the Action lines fill the middle, and the last three fit in the final 20 seconds. If you're short on time, line 8 can fold into line 6 or 7. The card isn't a resilience tutorial or production code, either. It only trains the shape of the answer.
Three checks before you record
| Check | Passes when | Typical failure | Where the guidance comes from |
|---|---|---|---|
| Action in first person | Every Action line starts with "I" plus a verb the interviewer can picture (captured, cut, capped) | "We aligned with the stakeholders" | Glasgow and the Amazon recruiter: "I", not "we"; UW: talk about what you did |
| Observable Result | The Result names a dashboard, a baseline or a follow-up artifact | "It calmed down", "it went well", "I learned a lot" | Duke: the result is critical; UW, Amherst and Amazon: quantify when you can |
| Task without a backstory saga | The Task fits in one sentence (restore X without Y); the Situation in two at most | Org charts, ticket archaeology, the war room in chapters | Duke: keep the setup brief; Northwestern and Illinois Tech: Action is the longest part, and the Situation is what you cut when you run long |
The "I" only applies to the actions that were actually yours. The system and the team can show up in the Situation. What doesn't work is "we" from start to finish, because then the interviewer walks away with nobody to hire.
If you don't have a number, don't make one up. Describing the observable change ("back to baseline on the same dashboard") is more convincing than a percentile invented to sound senior.
Tomorrow's experiment: 90 seconds on the recorder
Do this before your next interview or your next career 1:1. It's an editorial protocol, and all you need is a phone.
- Pick one incident or delivery you really lived through and strip out the names. Don't borrow the card above as if it were yours.
- Write your own eight-line card and run it through the three checks in the table.
- Record a 90-second voice memo telling the story.
- Listen once and note three timestamps: when the Situation ends, when the Action starts and when the Result starts.
- Pass if the Result is spoken in the last ~20 seconds, the Action is in first person, the Task is one sentence and there was no chronological dump. Fail if the Result starts after time is up or never shows, if the Action turned into "we", or if you're still in the Situation at 0:45.
- Rewrite once, record a second take, and stop.
Stopping at the second take is deliberate. From the third take on, the card becomes a memorized script, which is exactly what Amherst and the Amazon recruiter warn against. If a colleague is nearby, play them the recording and ask one question: "When did the result start?"
When to use the card, and when not to
Use the card when the question is behavioral: "tell me about a case…", "describe a time when…". It won't diagnose your seniority and it won't teach you a stack. If the question is "how would you design this?", you're in a different conversation and the card won't help.
It isn't a career review either. Technical career in 2026: the next step is not another framework looks for verifiable evidence of seniority. The problem here is much narrower: getting the result to fit into the last 20 seconds of an answer.
So the recommendation is conditional. If your stories tend to run long and the interviewer keeps having to ask "so what happened in the end?", write the card and do the two recordings. If your first take already puts the Result in the last 20 seconds with first-person Action, you don't need the card. Leave it there before it turns into a script. Either way, no card guarantees an offer. What it does guarantee is that when time runs out, the interviewer has already heard what you did and what changed because of it.