Receiving Critical Feedback
Practice this question in a realistic, spoken behavioral interview.
Tell me about a time you received critical or difficult feedback. How did you respond?
Pick feedback that was specific enough to sting and accurate enough to be hard to dismiss. Walk through what the person said, your honest first reaction, the clarifying question you asked, the behavior you changed afterward, and how you eventually checked whether the change had worked.
What the Feedback Story Needs to Prove
The story needs to connect feedback to changed behavior:
- You heard something real: Pick feedback that had substance, not a tiny style preference.
- You acknowledge the first reaction: Surprise, embarrassment, or defensiveness is human. The important part is what you did next.
- You translated feedback into action: Cite the specific behavior you changed, rather than saying you "took it seriously."
- You gathered evidence of improvement: Use later reviews, fewer comments, better outcomes, manager feedback, or a changed habit.
Getting defensive, or claiming you have never received critical feedback, makes you sound hard to manage and slow to grow.
Where This Answer Usually Goes Wrong
- A trivial feedback story: "Someone told me to put more comments in my code" does not show much. Pick feedback that changed something.
- Casting the giver as wrong: If the story ends with "and they realized I was right all along," you missed the question.
- No behavior change: Receiving feedback well includes acting on it. Show the action.
- "I disagreed but committed" with no specifics: This phrase has become a checkbox. Show what disagreement and commitment looked like.
- Pretending you welcomed it perfectly: It is fine to feel a small sting first. Naming that briefly builds credibility.
How to Show the Feedback Changed Something
The story needs a clear before and after. Spend less time proving you were gracious and more time showing what changed in your behavior.
- Set the Context: Choose feedback that had enough substance to change your behavior. "I work too hard" sounds fake; a comment about confusing PRs, defensive design reviews, or missed stakeholder updates gives the story something real to work with.
- Name Your Initial Reaction and Your Conscious Response: A little defensiveness is believable. The important part is the choice you made next: asking for an example, writing down the feedback, or taking time before responding.
- Detail Your Actions: Walk through the concrete steps you took because of the feedback. A vague "I took it seriously" is not enough; the steps are the evidence that you heard it.
- Show the Behavior Change: Connect the feedback to later work. Closing the loop with the person who gave the feedback adds weight, but only if you can point to what changed.
Answer Comparison
Polite Acceptance
"My manager once told me my code comments weren't very good. So I started writing better comments. It's all good now."
This version accepts the feedback too quickly and too vaguely. A stronger answer shows the initial reaction, the specific change, and evidence that the feedback altered behavior.
Changed Behavior
Set the Context
"In my first year as a mid-level engineer, my tech lead, Sarah, was my main code reviewer. In one of our 1-on-1s, she gave me some tough feedback. She said that while my code was functionally correct, it was often 'too clever' and difficult for other engineers to understand quickly. She pointed out that I was using a lot of complex one-liners and obscure language features, which would make the code hard to maintain in the future."
Reaction and Response
"My initial internal reaction was a bit defensive. I was proud of my technical skills and thought being 'clever' was a good thing. But I made a conscious effort to pause that feeling and listen. Sarah was a top engineer, and her feedback was coming from a place of experience. Instead of arguing, I asked a clarifying question: 'Could you show me an example of what 'good' looks like in this situation?'"
Detail Your Actions
"Her feedback prompted several specific actions. First, Sarah pointed me to our company's official style guide, which I had only skimmed before. I read it cover-to-cover that night. Second, I started optimizing my code for readability, not cleverness. I would ask myself, 'Could a new engineer understand this in 30 seconds?' If the answer was no, I'd refactor it to be simpler, even if it was a few more lines of code. Finally, in my next few code reviews, I added a comment asking Sarah, 'Is this implementation clearer and easier to follow?'"
Show the Positive Outcome
"Within a couple of months, the feedback on my code reviews changed from 'This is hard to follow' to 'This is clean and easy to understand.' More importantly, it changed my philosophy of software engineering: from solving a problem to building maintainable, long-lasting solutions for a team. In a later 1-on-1, I thanked Sarah for that feedback and told her it was one of the most important lessons I had learned that year. It strengthened our working relationship."