STAR method interview examples

Published by MockReps.

The STAR method is a simple way to answer behavioural interview questions such as “Tell me about a time when…”. You describe the situation, your task, the action you took and the result. It helps the interviewer follow a real experience and understand your part in it.

STAR organises facts you already have. It does not make a weak or invented story stronger. Start with something that actually happened, then use the structure to decide what to say first and what to leave out.

What each part of STAR should do

• Situation: one or two sentences of context. Say what was happening and why it mattered. Most answers spend too long here.
• Task: what you were responsible for. Make the boundary clear, especially when a team shared the work.
• Action: what you personally did, and why. This is usually the longest part. Use “I” for your decisions and “we” for shared work.
• Result: what changed and how you know. Include what you learned. If you cannot share or verify a number, describe the outcome honestly instead.

A useful habit is to answer in about two minutes, then let follow-up questions draw out more detail. Interviewers differ, so treat that as a starting point rather than a rule.

Three fictional STAR examples

The following people, projects and answers are invented for teaching. They are not customer results, actual MockReps outputs or stories to present as your own. Use them to see the structure, then write your own from real notes.

Example 1: a disagreement with a colleague

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

• Situation: A teammate wanted to release a new search feature on Friday. I had seen error rates rise in testing.
• Task: I was responsible for the release checks, not for the release date.
• Action: I shared the test results with them privately, proposed releasing to a small group of users first and offered to watch the error dashboard during the rollout.
• Result: We agreed on the smaller release. It surfaced one bug, which we fixed before the wider launch the following week.

Spoken answer: “A teammate wanted to release a search feature on a Friday, but I had seen error rates rise in testing. The release date wasn't my decision, but the release checks were. Rather than argue in the team channel, I showed them the test results and suggested releasing to a small group first, and I offered to watch the error dashboard while it went out. They agreed. The smaller release found one bug, we fixed it, and the full launch went out the next week. I learned that a disagreement goes better when I bring evidence and a workable alternative, not just an objection.”

Why it works: it shows respect for the colleague, separates the decision from the evidence and ends with a modest, believable result.

Example 2: a mistake you made

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

• Situation: I changed a configuration value and deployed it without a second review because it looked trivial.
• Task: I owned that change and needed to limit the impact.
• Action: When alerts fired, I rolled the change back, told the team what I had done and wrote up what happened. I then suggested that configuration changes go through the same review as code.
• Result: Service recovered after the rollback. The team adopted the review rule, and I now ask for a review on every change, however small it looks.

Spoken answer: “I once deployed a configuration change without a review because it looked trivial, and it caused errors for some users. I owned the change, so I rolled it back as soon as the alerts fired and told the team straight away what I had done. Service recovered after the rollback. Afterwards I wrote up what happened and suggested that configuration changes get the same review as code, which the team adopted. I still ask for a review on small changes, because the ones that look trivial are the ones I'm most likely to rush.”

Why it works: it admits the mistake plainly, shows a calm response and describes a lasting change in behaviour. It does not blame anyone else or claim the mistake was secretly a success.

Example 3: leading without authority

Question: Describe a time you led a piece of work without being the manager.

• Situation: Three teams each kept their own copy of the same date-formatting code, and it produced inconsistent results in reports.
• Task: Nobody had asked me to fix it, but I wanted the reports to agree.
• Action: I listed the differences, shared a short proposal for one shared module and asked each team for one reviewer. I wrote the first version and helped each team switch over.
• Result: Two of the three teams moved to the shared module that quarter. The third planned it for later, and reports from the first two now match.

Spoken answer: “Three teams had their own copies of the same date-formatting code, and our reports disagreed because of it. No one had asked me to fix it, so I started by listing exactly where the copies differed and sent a short proposal for one shared module. I asked each team for a reviewer, wrote the first version and paired with each team on the switch. Two teams moved over that quarter, and their reports now match. The third team scheduled it for later. It taught me that people support a change more readily when they help shape it.”

Why it works: the result is partial and stated honestly. A real outcome that is incomplete is more convincing than a perfect one.

Common STAR interview questions to practise

1. Tell me about a time you disagreed with a colleague or manager.
2. Describe a mistake you made and what you did next.
3. Tell me about a time you had to meet a tight deadline.
4. Give an example of leading without formal authority.
5. Tell me about a decision you made with incomplete information.
6. Describe a time you received difficult feedback.
7. Tell me about a project that did not go to plan.
8. Give an example of explaining something technical to a non-technical person.
9. Tell me about a time you changed your mind.
10. Describe the piece of work you are most proud of, and your part in it.

One real experience can often answer several of these questions. Prepare a handful of strong stories and practise adapting each one, rather than memorising a separate script for every question.

Common STAR mistakes

• A long situation: if the background takes a minute, the interviewer is still waiting to hear what you did.
• Only “we”: the interviewer is assessing you. Make your own decisions and actions clear.
• No result: stopping after the action leaves the story unfinished. Say what changed, even if the outcome was mixed.
• Invented numbers: a precise figure you cannot support may not survive a follow-up question. An honest qualitative result is safer.
• The wrong story: a polished story that does not answer the question is still the wrong answer.

A STAR preparation worksheet

For each experience, write short notes under these headings before you write any sentences:

1. What happened, and why did it matter?
2. What were you responsible for, and what was outside your control?
3. Which options did you consider, and why did you choose this one?
4. What did you do yourself, and who did you work with?
5. What changed? What evidence do you have, and what is still unknown?
6. What would you repeat or do differently?

Remove confidential names, customer details and anything that is not needed to understand the example. Then say the answer aloud, because written answers often sound different when spoken.

Keep practising

The behavioural interview practice guide for engineers works through a technical decision in more depth, including follow-up questions. In MockReps, your Story Bank keeps your experiences organised under STAR headings so you can revisit them, and AI feedback can help you choose what to improve next. Free sample interview questions are available without signing in.