In this article
Before you start
This page assumes no management experience. For the wider set of questions, see the engineering manager interview questions guide.
Why interviewers ask this
The question tests whether you can see your own errors as a leader and turn them into a change. A mistake as a manager is different from a personal slip: it affects other people's work, so the story shows how you treat them under pressure.
Harvard Business Review (2023) advises that the recruiter wants less your story of failure than what you learned. A career expert quoted in December 2025 warns that seeming defensive or passing blame to others could raise red flags.
A weak answer picks a fake flaw or blames the team. A strong answer picks a real error, states it plainly and shows a lasting fix. We found no public scoring rubric for this question, so treat the above as advice, not a scoring rule.
How the biggest-mistake answer works, from first principles
- Mistake story
- A mistake story is a short, true account of one error you made as a leader, told in four parts (situation, task, action, result) so that the interviewer sees what you did and what changed.
- Correction
- A correction is the change you made after the mistake, ideally a rule, habit or process that keeps working when you are not paying attention, as opposed to a promise to try harder.
- Preventable failure
- A preventable failure is a mistake in a predictable, well-understood process that a known step would have stopped, one of three failure types described by Edmondson (2011).
In plain words
Think of a pilot's debrief after a rough landing. The pilot says what happened, what was theirs, and which checklist line changes. Nobody wants a speech about guilt. The analogy breaks in one place: an interview debrief is also a performance, so you choose the story and the length.
In one precise sentence, the answer is a true, bounded mistake in your leadership, owned without blame, followed by a correction that outlasts the story.
Edmondson (2011) argues that many executives believe all failure is bad and that learning from it is straightforward, and that both beliefs are misguided. She sorts mistakes into three types: preventable, complexity-related and intelligent.
Step 1: Choose a real, bounded mistake and say what happened
Pick a mistake that was yours, real and affected people, but that you could fix. The Situation and Task come first: where you were, what you were responsible for, in two or three sentences. The interview frame asks you to describe one specific event, not a general habit, and to keep the focus on you.
Good sources of mistakes line up with recognised manager behaviors. Google's Project Oxygen listed 10 behaviors of effective managers, drawing on more than 10,000 data points, including being a good coach, empowering the team without micromanaging, communicating effectively, and supporting career development. Micromanaging, a skipped career conversation and a vague message map to those items. That mapping is our framing, not a claim by Google.
You now know what to choose: a real error, one event, your part in it.
Step 2: Own the mistake without blame
State what you did wrong in one or two plain sentences. The career expert's advice is to plainly state the facts without glossing over the mistake or dwelling on it. Blame has a second cost: Edmondson (2011) notes that failure and fault are virtually inseparable in most organizations, which is why people hide errors.
Psychological safety is, in the words of Edmondson (1999), "a shared belief held by members of a team that the team is safe for interpersonal risk taking". In her study of 51 work teams it was associated with learning behavior, and learning behavior mediated between safety and team performance. A manager who blames the team in an interview signals the opposite of safety.
The sentence you say is "That was my decision, and here is what it caused." Now you have a mistake that is owned. The next step decides the level of the answer.
Step 3: Name the correction that outlasts the story
The correction is what separates levels: a rule, habit or process change you made and can show working. Harvard Business Review (2023) advises emphasizing the correction and letting it take the spotlight, so the failure does not linger and damage your reputation. It also asks you to articulate both the learning and the improvement, so the interviewer sees how you traveled from failure to learning to improvement.
"I learned to delegate" is a lesson. "Any two reviewers can now approve a change, and I check that a rule still works when I am away" is a correction. The test is whether the fix would still work if you forgot about it. The Result part of the story is the evidence that it did.
Step-by-step description
- Pick a real, bounded mistake.
- State it plainly, no blame.
- Name the lasting process change.
- The mistake is real and bounded.
- The correction is a process change that outlasts the story.
The mistake is real and bounded, and the correction is a process change that outlasts the story.
Examples of manager mistakes that work in an interview
Six common manager mistakes work well in an interview, each paired with a correction that keeps working. The pairings and the behavior mapping are our judgment, not a source's list; the behaviors are the Google ones quoted in Step 1.
- Acted too late on a low performer (coaching): a fixed check-in date for every concern.
- Hired for speed (focus on results): a written bar for each role before interviews start.
- Skipped career conversations (career development): a growth one-on-one every quarter.
- Announced a change without consulting the team (communicating effectively): a written plan and a window for objections.
- Over-committed the roadmap (focus on results): a capacity buffer in every plan.
- Became the review bottleneck (empowering without micromanaging): the shared approval rule in the worked example below.
Pick the one that is true for you; do not invent a mistake to fit the list.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
An illustrative story shows the shape: a new team lead of six engineers reviewed every pull request (a proposed code change waiting for review) personally. Waits grew, and people stopped sending small changes until the lead was free. After the lead owned the problem, the team wrote down what a change needs to merge and let any two reviewers approve.
The review waits are illustrative, eight changes before and eight after. The median wait fell from 31.5 hours to 10.5 hours, a drop of 21.0 hours, or 66.7%.1 These are invented numbers for the example, not a benchmark.
| Quantity | Value (illustrative) |
|---|---|
| Median review wait before | 31.5 hours |
| Median review wait after | 10.5 hours |
| Drop in median wait | 21.0 hours (66.7%) |
| Answer length | 120 seconds |
| Situation | 18 seconds |
| Task | 12 seconds |
| Action | 48 seconds |
| Result | 42 seconds |
| Words at 130 words a minute | 260 words |
The time split is a rule of thumb. Commercial prep sites give different splits, so no source here treats one as a standard. In the illustrative two-minute answer the action takes 48 seconds and the result 42 seconds, and the situation and task together take 30 seconds.1 At 130 words a minute (illustrative) that is 260 words in total.1
Text description of the diagram
- In the illustrative two-minute answer the action takes 48 seconds and the result 42 seconds.
- The situation and task together take 30 seconds.
A weak and a strong answer side by side
Both answers below are an illustrative example, written as third-person composites, not real people. The difference lies in the specific words.
| Part | Weak answer (illustrative) | Strong answer (illustrative) |
|---|---|---|
| Situation | A manager says his team sometimes missed deadlines. | A new lead of six engineers reviewed every change herself. |
| Mistake | He says he is a perfectionist. | She says she made herself the bottleneck. |
| Ownership | The team was not ready, so he pushed them. | She says it was her decision and names what it caused. |
| Correction | He says he will try to be more relaxed. | She wrote down what a change needs to merge and let any two reviewers approve. |
| Result | Nothing is said. | Waiting time dropped, and she checks that new rules work when she is away. |
How the answer is judged
| Dimension | Weak | Strong | Staff |
|---|---|---|---|
| Ownership | Blames the team or says "we" throughout. | Says "my decision" and what it caused. | Also names what they failed to notice at the time. |
| Specificity | A general habit with no event. | One event, with the people and the situation described. | Picks the event that matches the scope of the role. |
| Correction | A promise to try harder. | A rule or process change. | A change others can run without the manager. |
| Evidence | None given. | One observed result after the change. | A later check of the result, and how it was done. |
| Follow-up readiness | Stalls when asked what else could have been done. | Answers "what would you do differently". | Explains alternatives and why they were rejected. |
This rubric is our own judgment from the advice above; it is not any company's rubric.
Trade-offs and edge cases
The main tension is between owning the mistake fully and not dwelling on it. One source tells you to state the facts without glossing over the mistake, and another to let the correction take the spotlight. Both fit one rule: say the error in a sentence or two, then spend your time on the fix.
Choosing the type of failure also matters. Edmondson (2011) describes preventable, complexity-related and intelligent failures. A preventable failure happens in predictable operations. Complexity-related failures happen in complex systems. An intelligent failure happens at the frontier. Which correction sounds credible depends on the type; the table suggestions are our judgment, not Edmondson's.
Text description of the diagram
- A preventable failure happens in predictable operations.
- An intelligent failure happens at the frontier.
Edge cases: a trivial mistake reads as an evasion, and a catastrophic one needs care, so pick something real but recoverable. Keep other people's names and confidential details out. If the mistake involved a low performer, the low-performer answer shows how to describe it fairly; for difficult conversations see one-on-ones and hard feedback.
How to answer it in an interview
What is the biggest mistake you have made as a manager?
Early as a team lead I reviewed every pull request myself because I wanted quality to stay high. Reviews queued up, my engineers stopped sending small changes until I was free, and two of them told me they felt I did not trust them. That was my mistake: I made myself the bottleneck. I owned it at our next team look-back meeting, we wrote down what a change needs to merge, and any two reviewers could approve. Waiting time dropped from just over a day to about half a day, and I now check whether a rule I write will still work when I am away.
The spoken structure: one sentence of context, one sentence owning the error, then the correction and its evidence. This is an illustrative answer; use your own true story. The block above is the condensed core of the two-minute answer; the full version expands the Action and Result parts. See the people management round for the wider set of questions, and your management philosophy for the principle your correction should reflect.
Common mistakes
- "My biggest mistake was working too hard." (wrong) A trivial flaw dodges the question, and the advice is to focus on what you learned. (right) "I made myself the bottleneck, and here is the rule I changed."
- "The team missed the deadline because they were not ready." (wrong) Blame is a red flag and mirrors the blame culture that makes people hide errors. (right) "I set the deadline without asking the team, and that was mine."
- Ten minutes on how bad it felt. (wrong) The failure should not linger. (right) One sentence on the error, then the fix.
- "I learned to communicate better." (wrong) A lesson with no change cannot be checked. (right) "We now send a written plan before any reorg (a change to who reports to whom), and I ask for objections."
Follow-up questions
What's your biggest mistake supporting people?
Pick a story about coaching, feedback or career growth, such as a skipped career conversation, and show the correction as a habit. Google's list includes coaching and career development, so these map to recognised behaviors; the pairing is our inference. The growing engineers guide has more.
What if my biggest mistake was recent?
A recent mistake is fine if you can show the correction already working, even briefly. This is our judgment, tied to the advice to demonstrate the improvement. If the fix is untested, say what you will measure and when you will check.
Which kind of mistake should I pick?
Pick one you can classify. A preventable failure suits a missed process step, a complexity-related one suits a surprise in a tangled system, and an intelligent failure suits a reasoned bet that did not pay off. The team health guide shows what to measure afterward.
How long should the answer be?
Aim for about two minutes spoken, which fits the illustrative split above. Sources on exact percentages disagree, so use the split as a rule of thumb and shorten the situation first.
What would you do differently?
Answer with the correction, in the present tense: what you do now. A change you already made is stronger than a wish.
- The question asks for one real, bounded mistake, owned plainly, with a correction that lasts.
- Spend a sentence or two on the error and most of the answer on action and result.
- Blame and trivial flaws are the two classic ways to lose the point.
- Classify the failure as preventable, complexity-related or intelligent so the fix sounds credible.
- A correction you can show working beats a lesson you only describe.
Sources
- Following the data: The research behind great managers — Google re:Work, 1 Aug 2025
- Psychological Safety and Learning Behavior in Work Teams — Administrative Science Quarterly (Edmondson), 1 Jun 1999
- Strategies for Learning from Failure — Harvard Business Review (Edmondson), 1 Apr 2011
- How to Answer "Tell Me About a Time You Failed" in a Job Interview — Harvard Business Review, 1 Jan 2023
- How to answer "Tell me about a time you failed", says a career expert — CNBC, 12 Dec 2025
