To answer “tell me about a time you received critical feedback”, choose a specific, real piece of criticism about your work — not a disguised strength — say who gave it and roughly what they said, admit your first reaction in one honest sentence, then spend most of the answer on the concrete change you made and the evidence that it stuck. Finish by closing the loop: you went back to the person, or later feedback showed the gap had closed. The interviewer is not judging the flaw; they are judging whether you are easy to coach.
This is a different question from “tell me about a time you failed”. A failure story starts with something going wrong; a feedback story starts with someone telling you something you didn’t see, so it tests how you take input rather than how you recover from a miss.
What the interviewer is checking
The question comes in many wordings — “What’s the toughest feedback you’ve gotten?”, “Tell me about constructive criticism you received,” “How do you handle criticism?”, “What would your last manager say you need to work on?” — and they all probe the same things:
- Coachability. Will feedback from your new manager and reviewers change your behavior, or bounce off?
- Emotional control. Can you hear something uncomfortable without getting defensive? Admitting a brief flash of defensiveness, then showing what you did instead, is more believable than claiming you felt nothing.
- Judgment. Did you check whether the feedback was right, and understand the reason behind it, before acting?
- Follow-through. A named habit or mechanism, not “I worked on it.”
- Self-awareness. Can you name a real gap that isn’t a dealbreaker for the role?
Amazon puts this in writing: its Earn Trust principle says leaders “are vocally self-critical, even when doing so is awkward or embarrassing,” and Learn and Be Curious says they “always seek to improve themselves” (Amazon Leadership Principles, checked October 2026). Microsoft loops probe the same signal through growth-mindset questions, covered in our Microsoft behavioral interview guide.
Pick feedback worth telling
The best stories involve feedback about how you work — something that affected teammates or the product — from someone with a reason to tell you. For engineers, it usually comes from one of these sources:
| Source | Example of the feedback | Why it works | Watch out for |
|---|---|---|---|
| Code reviewer | “Your pull requests are too big to review properly.” | Concrete, with an easy before-and-after | Style nits instead of a real pattern |
| Design review | “Your doc covers the happy path but not what happens when the dependency fails.” | Shows your engineering judgment growing | Too much architecture detail |
| Manager or performance review | “Your status updates bury the risks at the bottom.” | Ties to trust and communication | Re-arguing the review itself |
| A peer or someone junior | “In design meetings you jump to the answer and others stop talking.” | Upward feedback is a strong senior signal | Sounding put out by who said it |
| Incident postmortem | “We should have heard about the failing job hours earlier.” | Clear stakes and a mechanism fix | Drifting into a failure story |
| Mentor, professor or internship lead | “Your explanations skip steps.” | Fine for new grads with little work history | One-off or trivial comments |
Avoid humblebrags (“they said I work too hard”), feedback about a serious conduct problem, anything you never acted on, and comments so minor there was nothing to change. If the same gap is your answer to “what is your greatest weakness?”, that’s fine — tell it as a story here; our greatest weakness guide covers the other framing.
A five-step structure: feedback, reaction, check, change, proof
- The feedback. Who gave it, in what setting, and close to the words they used: “My tech lead told me in a 1:1 that my pull requests were too large to review well.” Specific wording makes it believable.
- Your first reaction, honestly. One sentence — “My first instinct was to explain why the feature had to be one PR” — then what you did instead, usually asking a question.
- How you checked it. You asked for examples, looked at your own history (PR sizes, review times, doc comments) or asked a second person. This shows you treat feedback as information, not as a verdict.
- What you changed. The bulk of the answer. Name the habit, checklist, template or routine, and when you started using it.
- Proof and closing the loop. What improved, who noticed, and how you followed up with the person who gave the feedback. Use only results you can back up.
About 90 seconds to two minutes is plenty. Steps 4 and 5 should take at least half that time; the most common mistake is a minute on the feedback and ten seconds on the change.
Example answers to “tell me about a time you received critical feedback”
These are example answers we wrote to illustrate the structure at three levels; they are not real candidates’ stories. Use your own feedback, your own changes and only numbers you can stand behind.
New grad: “Your pull requests are too big”
Feedback and reaction: “A few months into my first job, a senior engineer told me my pull requests were too big to review well and that reviewers were skimming them. My first reaction was to defend it — the feature really was one piece of work.”
Check: “I asked him which PR had been hardest to review, then looked back at my last ten. Most touched a dozen files, mixed refactoring with new behavior and took days to get approved.”
Change: “I started splitting work into stacked PRs — refactor first, then behavior, then tests — each small enough to review in one sitting, with a two-line ‘what to review first’ note in the description.”
Proof: “Most of my PRs started getting reviewed the same day, and a reviewer caught a real bug in one of the smaller ones. A month later I asked him whether it was better; he said yes and suggested I draft the PR template the team now uses.”
Mid-level: “Your designs don’t say what happens when things fail”
Feedback and reaction: “After a design review, a staff engineer told me my docs explained the happy path well but rarely said what happened when a dependency was slow or down. It stung, because the design had been approved.”
Check: “I asked for a specific example, and she pointed to a retry loop with no limit and no timeout. I reread my last three docs and found the same gap in two of them.”
Change: “I added a ‘failure modes’ section to my design template — dependency down, slow or returning bad data, and what the user sees in each case — and started walking drafts through with the on-call engineer before the formal review.”
Proof: “On my next design, that section surfaced a missing timeout before we built anything. The team added the section to the shared template, and I sent the staff engineer a note thanking her and pointing to the change.”
Senior: feedback from people you mentor
Feedback and reaction: “In a peer feedback cycle, two engineers I mentored wrote that in design meetings I jumped to a solution early and others stopped proposing ideas. My first reaction was that I was keeping meetings efficient.”
Check: “I asked one of them for a specific meeting, then paid attention in the next few discussions to who was talking. It was mostly me.”
Change: “I changed three things: I send a written pre-read and collect comments before the meeting, I ask each person for one concern before I give my view, and when a junior engineer owns a design, I give my critique privately first rather than in the room.”
Proof: “Within a couple of months, both of them were leading design reviews, and the next feedback cycle called out the meetings as a strength. I thanked them, and I now ask for feedback on how I run meetings every quarter.”
Weak vs. strong answers
| Part of the answer | Weak | Strong |
|---|---|---|
| The feedback | “My manager said I could communicate better.” | “My tech lead said my status updates buried the risk at the bottom.” |
| Kind of feedback | “They said I care too much about quality.” | A real gap that affected teammates or users |
| Your reaction | “I took it really well.” | “My first instinct was to defend it; I asked for an example instead.” |
| Checking it | Accepted or dismissed it without looking | Looked at your own PRs, docs or review history |
| The change | “I worked on it.” | “I split PRs into stacked changes with a review note.” |
| Proof | No outcome | A later result, and who noticed |
| The person who gave it | “He was pretty harsh about it.” | “It was fair, and I’m glad he told me.” |
If you disagreed with the feedback
A story where you didn’t fully agree can still work — it shows you take feedback seriously without being a pushover. Tell it in this order:
- Acknowledge what was true. Most critical feedback has a valid core even when the framing is off.
- Show you checked. You asked questions or looked for evidence before deciding.
- Act on the part that held up, and name the change.
- Explain the rest calmly: “We agreed the remaining piece was a trade-off, and I wrote down why I made it.”
What doesn’t work is a story whose real point is that the feedback was wrong. If that’s the message you notice, pick a different example.
Follow-up questions to expect
- “How did you feel when you heard it?” Honest and brief: surprised, a bit defensive, then curious.
- “Did you agree with it right away?” It’s fine to say no, as long as you explain what convinced you.
- “How do you know you actually improved?” Point to a later result, a review comment or a repeat situation that went better.
- “Have you gotten that feedback again since?” If yes, say what you are still working on.
- “What’s the most recent feedback you’ve received?” Your small, recent example.
- “How do you ask for feedback?” A concrete habit, such as one specific question for each reviewer or a standing question in 1:1s.
- “Tell me about feedback you gave someone else.” Prepare a short story from the other side.
How to practice this answer
- Collect candidates. Reread old performance reviews, code review threads and design-doc comments; the critical parts are where these stories live.
- Pick one or two you clearly acted on, ideally from different sources, such as a reviewer and a manager.
- Draft each in the five steps with the free STAR story builder, keeping the change and proof longer than the setup.
- Rehearse out loud and take the critique. A free AI mock interview in CoPilot Interview scores each spoken answer out of 10 with what to fix and a model answer — practice for this question, and a low-stakes rep at hearing critique and adjusting on the next try.
For the other prompts to prepare alongside this one, see our story-bank method for behavioral interviews and behavioral interview help.
Practice your feedback story out loud
Give the desktop app’s Mock Interview mode your résumé and the job description, pick a behavioral-heavy mix and answer each question out loud. You get critique on every answer — a score out of 10, what to fix and a model answer — on the free plan’s 15 minutes a day, no credit card.
Try a free AI mock interviewFAQ
What kind of feedback should I talk about?
Feedback about how you work that affected teammates or the product: code review habits, gaps in your designs, communication, or how you behave in meetings. Avoid disguised strengths and serious conduct issues.
Is it OK to admit I got defensive at first?
Yes. One honest sentence about your first reaction makes the story more believable, as long as the rest shows what you did instead: asked questions, checked the evidence and changed something.
How is this different from “tell me about a time you failed”?
A failure story starts with something going wrong because of your decision. A feedback story starts with someone else pointing out something you had not seen, so it tests how you take input rather than how you recover from a miss.
What if I can’t remember any critical feedback?
Look through old performance reviews, code review comments, design-doc threads and comments from mentors or professors. If you truly have nothing, ask a colleague for feedback now; a recent example is still valid.
How long should my answer be?
About 90 seconds to two minutes. Keep the feedback and your reaction short, and spend most of the time on what you changed and how you know it worked.
Can I use feedback from a code review?
Yes, if it pointed to a pattern rather than a one-off nit. A reviewer telling you your pull requests are too large or your tests miss edge cases is good material, because you can show a clear before and after.