Behavioural interviews
“Tell me about a time you made a mistake”: how to answer
The awkward part of “Tell me about a time you made a mistake” is choosing a story. Pick something too small and there is little to explain. Pick a complicated incident and you can spend the whole answer describing the background.
A useful answer names a real mistake, makes your responsibility clear and explains what you did next. Give the consequence enough space to be understood, then describe the repair and what changed in your later work. The story does not need a perfect ending.
Choose an incident with something to learn from
Look for a decision or action you can explain from start to finish. Perhaps you estimated work before checking a dependency, sent a report without validating one of its inputs, or misunderstood who was responsible for a handover. The relevant detail is what you personally missed and how you responded.
Match the scale to the question. If you are asked about a significant failure, an inconsequential typo is unlikely to give you much to discuss. If the interviewer asks about a mistake, you do not need to search for the worst event of your career.
Keep confidential information out of the answer. You can say “a customer report” or “an internal service” without naming the client, exposing account details or describing a security weakness. Be truthful about the event while leaving out information the interviewer does not need.
Use STAR, with room for the repair
The STAR method gives you a useful outline, but this question needs a clear account of what went wrong. Avoid letting the setup take over.
- Situation and task: explain the work and what you were responsible for.
- Mistake: name the assumption, omission or decision that caused the problem.
- Action: describe how you raised it, helped put it right and involved others where needed.
- Result and learning: explain the outcome, including any remaining cost, and what you now do differently.
Make ownership precise. “We missed the deadline” does not tell the listener what you did. “I estimated the implementation without checking how long the approval would take” does. You can acknowledge a team problem without claiming sole responsibility for everything.
A fictional answer about a missed dependency
The following is an invented teaching example, not a customer story. Replace it with an incident you can discuss accurately.
“I was responsible for adding an export feature to an internal reporting tool. I estimated the work after checking the code changes, but I didn't confirm the review needed before the exported data could be shared. I only raised that dependency when the feature was nearly finished, and we missed the planned handover.
“I told the project lead that I'd left the review out of my estimate. I contacted the reviewer, prepared the information they needed and worked with the lead to agree a revised date. We delivered a week later than planned, so I wouldn't describe the recovery as avoiding the delay.
“After that, I added a dependency check before giving delivery estimates: who needs to review the work, what they need and when they are available. On the next export change, I booked that review before implementation. It gave us a more realistic plan and meant the reviewer could flag a requirement while we still had time to address it.”
Notice where the answer spends its time. There is enough context to understand the omission, followed by specific recovery steps. It acknowledges the late delivery instead of recasting the whole incident as a success.
Prepare for the questions behind the story
An interviewer might ask why you missed the dependency, who spotted the problem or whether the same thing happened again. These details are worth thinking through before you rehearse. They are often where a vague story becomes specific.
Try answering: “What information did I have at the time?” and “What could I reasonably have checked?” That distinction helps you separate an avoidable mistake from an outcome you could not have predicted. If the incident was mainly outside your control, it may fit a question about setbacks better than one about your own mistake.
Be ready to explain other people's contributions. You might have raised the issue and coordinated the repair while a colleague implemented part of it. Say so. Clear credit makes your own role easier to understand.
Show what changed after the incident
“I learnt to be more careful” is difficult to picture. A changed habit is easier: checking the source data before sending a report, confirming the handover owner or testing a rollback before a release. Describe the smallest real change that addressed the cause.
If you have not faced a similar situation since, be open about that. You can explain the process you introduced without claiming it has already prevented another failure. If you did repeat the mistake, explain what the first response failed to address and how you adjusted it.
For an early-career interview, a group project, part-time job or volunteering example can give you enough material. Choose it for the judgement it shows, rather than trying to make a student project sound like a large commercial launch.
Check whether your answer actually answers the question
Ask a listener to identify the mistake, your role and the change afterwards. If they cannot, trim the background and make those details explicit. Then try the same story in response to “What would you do differently?” so that you practise adapting rather than repeating a memorised paragraph.
Use the job description to select other examples too. Your introduction can highlight a strength, while this story shows how you respond when the work does not go to plan. Our interview introduction guide can help you keep those answers distinct.
Further reading: Oxford University's interview technique guidance discusses honest reflection on difficult questions and making your own actions clear. The worked example and practice prompts here are MockReps guidance.