STAR Method: 3 Complete Answer Examples

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.

Three complete STAR method examples

These are fictional teaching examples, not customer stories or achievements to borrow. Replace the circumstances, actions and outcomes with your own. Each one answers a different behavioural question.

Example 1: Resolving a disagreement

Question: Tell me about a time you disagreed with a colleague.

Situation: Our team was preparing a new account-setup flow. A designer wanted to launch the whole flow together; I was worried about changing the identity check and the interface in the same release.

Task: I owned the rollout plan and needed to protect existing customers without turning a reasonable concern into an indefinite delay.

Action: I wrote down the two failure scenarios I was worried about and asked the designer to walk through the customer impact with me. We agreed to release the interface behind a flag first, keep the existing identity check and review support tickets before changing the second part. I documented the rollback trigger and asked support to review it.

Result: We launched the interface, found a confusing error message in the first group and corrected it before widening the rollout. We then shipped the identity change separately. The disagreement became a sequencing decision rather than a contest over whose idea won.

Why it works: The answer explains the actual disagreement and the candidate's contribution. It does not turn the colleague into a villain.

Practise the follow-up: What evidence would have persuaded you to launch both changes together?

Example 2: Learning from a failure

Question: Tell me about a mistake you made at work.

Situation: I promised a weekly report to a sales team using an export I had only tested with a small sample.

Task: I was responsible for delivering the report before their account review. I should have checked the full dataset before committing.

Action: The full export failed on inconsistent account IDs. I told the sales lead immediately, explained which sections were reliable and delivered a smaller report for the review. Afterwards I added validation for the IDs, ran the process against a full export and changed my checklist so estimates include a data-quality check.

Result: The team had a usable report but had to postpone one part of the review. Subsequent runs passed the checks before I announced a delivery date. I learned to validate the dependency before promising the outcome.

Why it works: There is a real consequence, clear ownership and a specific change in working practice. It does not disguise a success as a failure.

Practise the follow-up: What would you do if the same issue appeared an hour before the next deadline?

Example 3: Leading without formal authority

Question: Describe a time you led a project without being the manager.

Situation: New support agents were receiving different setup instructions from three teams. Questions were bouncing between channels.

Task: I was an individual contributor asked to make the next onboarding cohort easier to support. I could propose a process but could not assign work to the other teams.

Action: I collected the repeated questions, drafted one checklist and asked each team to nominate an owner for its section. I ran a walkthrough with a new starter and used the points where they got stuck to revise the instructions. I kept unresolved decisions in one short document so owners could approve them asynchronously.

Result: The next cohort used a single checklist and knew which owner to contact for each step. We still had exceptions, but they were recorded in one place instead of being rediscovered in separate conversations.

Why it works: Leadership appears through coordination and decisions, without claiming authority or inventing an improvement percentage.

Practise the follow-up: What did you do when an owner did not respond?

A STAR answer template for your own experience

• Situation: What was happening, and why did it matter?
• Task: What were you personally responsible for?
• Action: What did you decide, do and change? Why that approach?
• Result: What happened, how do you know, and what remains unresolved?

Say the answer aloud, then ask yourself a follow-up about a decision you made. If you cannot explain it without adding invented detail, choose a different example. For questions that need another structure, use the greatest-weakness examples or the opening introduction guide.

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.

Build your own STAR outline

Use the free STAR story worksheet to separate the situation, task, action and result from your own work. Download your notes, then practise explaining them aloud.