You have a story ready for your next interview.
There’s a situation. A task. An action. A result.
You’ve cut the rambling introduction. Replaced “we” with “I” where appropriate. Practised until you can deliver it in two minutes.
Then someone asks:
“What did you actually decide?”
And suddenly, the answer you rehearsed doesn’t feel finished.
That question points to a gap in how we can end up using STAR. It helps us organise an answer. Filling in its four sections doesn’t automatically give someone enough evidence to evaluate our work.
You can describe a successful project in perfect chronological order and still leave your judgment almost entirely invisible.
An answer that ticks every box
Consider this fictional example:
“Our team needed to launch a CSV export feature before the end of the quarter. I was responsible for making sure it was ready. When we found a performance issue, I worked with product to adjust the scope, implemented validation, and helped us launch on time.”
It has all four parts:
- Situation: A feature needed to launch.
- Task: Get it ready.
- Action: Work with product, adjust scope, add validation.
- Result: Launch on time.
Now imagine you’re the interviewer.
Did this developer discover the issue or receive a ticket about it? Did they propose the change or implement someone else’s recommendation? Was the scope adjustment thoughtful, or did the team simply run out of time?
And what does “launched on time” tell you if you don’t know which customers could actually use the feature?
The answer may describe good work. You just can’t see enough of that work yet.
You could make the language more confident. “Worked with product” could become “drove cross-functional alignment.”
You would still have exactly the same unanswered questions.
Where STAR needs help
STAR gives you useful places to put information. You can absolutely include excellent reasoning and evidence inside it.
The mistake is treating a completed template as a completed answer.
A section labelled “Action” might contain a difficult decision, a routine implementation task, or a vague statement about collaboration. The label cannot tell you which one you’ve written.
Likewise, a “Result” can be measurable without establishing your contribution. A team shipped something. Revenue moved. A dashboard turned green. Those facts still need context.
If you only check whether all four sections are present, you can miss the weakness that matters most.
Before practising the delivery, inspect what the answer actually supports.
Meet PROOF
PROOF is Taleproof’s framework for checking the evidence in an interview story. It works alongside STAR.
The five checks are:
- P: Personal ownership. Which decisions and work were yours?
- R: Real stakes and resistance. What made this difficult or consequential?
- O: Options and tradeoffs. What other paths were available, and what did your choice sacrifice?
- O: Outcome and consequences. What happened, how do you know, and what remained unresolved?
- F: Follow-up readiness. Can you explain the details when someone probes your answer?
You don’t need to recite these letters in an interview. Use them while preparing, to find the information your summary has left out.
Let’s return to that export feature.
Recover the decision hidden inside the task
Here’s the fuller fictional scenario.
Four days before release, the developer tests an account much larger than the ones in the original test suite. The export fails because the service builds the entire CSV in memory.
The first proposed fix is to increase memory.
The developer tries that with a larger dataset. It buys headroom, but the test still doesn’t establish a safe operating range for the largest accounts.
Now there is a decision to make.
The team could delay the feature and change the implementation. It could proceed with more memory and accept the remaining uncertainty. Or it could support exports within a tested size limit while postponing larger ones.
The developer recommends the third option.
That recommendation has a cost: some customers waiting for the feature will still be unable to use it. Product needs to agree to that limitation. Support needs to understand it. The interface needs to explain it.
The developer implements the size check and boundary tests. A teammate handles the interface message. Product agrees to a limited trial with three smaller accounts.
All three complete their exports. Larger accounts remain unsupported.
Compare that with “I implemented validation.”
The code change is only one part of what happened. The interesting material is the investigation and recommendation that made the change necessary.
A stronger version of the same answer
With those details recovered, the answer becomes:
“Four days before our CSV export release, I found that a larger account’s export failed because we were building the file in memory.
“I tested the proposed memory increase with a larger dataset. It gave us more headroom, but we still hadn’t established what we could safely support.
“I recommended releasing with a tested size limit instead of delaying the whole feature or shipping without a clear limit. That meant leaving larger customers out, which I raised with the product lead before we agreed on a limited trial.
“I implemented the size check and boundary tests; a teammate handled the interface message. The three trial accounts completed their exports. We still had work to do for larger accounts, and I’d include those accounts earlier in the test plan next time.”
The project hasn’t become more glamorous.
The developer hasn’t claimed sole credit. The outcome hasn’t become a company-wide success. Nobody has invented a percentage.
But now you can discuss the developer’s contribution.
You can ask why they recommended a limit, what the tests established, and why they accepted excluding some customers.
That’s a much better place for an interview conversation to begin.
The question you should practise after your answer
Pick the strongest claim in your current story.
Maybe it’s “I led the migration,” “I improved reliability,” or “I influenced the roadmap.”
Ask yourself:
What would someone need to hear before they could reasonably believe that claim?
For “led the migration,” they might need to understand which decisions you owned, how responsibilities were divided, and what you did when the plan stopped working.
For “improved reliability,” they might need the original failure, the change you made, and the observations that support the improvement.
For “influenced the roadmap,” they might need to hear what was planned before your involvement and what changed because of your contribution.
Then ask one more question about your answer.
If you say you chose the safest option, safest for whom?
If you say the results improved, over what period?
If you say you convinced the team, what objection did you address?
You don’t need to cram every detail into your opening response. You do need to know whether the detail exists.
Don’t fill an evidence gap with a better sentence
Sometimes reviewing a story reveals missing wording. You did the work and simply forgot to explain it.
Sometimes it reveals missing information. You need to check an old project note or remind yourself what the actual result was.
And sometimes the story doesn’t support the claim you wanted to make.
That third possibility matters.
A small implementation task can be a useful example of careful execution. It doesn’t need to become a strategy story. A team outcome can be meaningful without being entirely attributable to you.
If the example is too thin for the question, choose another one. If you don’t know a number, don’t invent it. If a decision belonged to someone else, explain your contribution accurately.
The goal is an answer you can stand behind when the conversation moves beyond the version you rehearsed.
Try it on your own story
Take the answer you feel most confident about.
Before polishing another sentence, look for the decision you made, the difficulty you faced, the alternative you rejected, and the evidence behind your result.
Where you hesitate is where to investigate next.
Go to Taleproof.com/score-story and score that story. You’ll get a PROOF + STAR breakdown and specific feedback on what to strengthen. Your first complete assessment is free, with no account needed.
Use the feedback to revisit the actual experience, fill the gaps you can support, and choose a stronger example where necessary.
Then practise telling it.
The worked example is fictional.
Top comments (0)