How to Answer “Tell Me About a Time You Received Critical Feedback” When It Was Only Partly Right

Feedback that was only partly right can still answer “tell me about a time you received critical feedback.” You need a fixed order. First, name the part that was right and own it. Second, spend most of the answer on what you changed because of it. Third, give the part you disagreed with one or two sentences. Frame it as a point you raised and settled at the time. Last, close on the result. This order works because the question checks one thing above all. Can you hear criticism and change because of it? A mixed story passes that check if the change comes first. It also shows something a clean story can’t. You can separate a valid criticism from a bad suggestion. Told in the reverse order, the same story sounds defensive. The rest of this post builds one complete answer and explains each part.

The example: a review comment that named a real problem and the wrong fix

Every section below uses the same story. You’re an Android engineer. You built a small custom cache for the app’s feed. A senior engineer reviews your pull request. Their comment says to delete the custom cache and use a standard library instead.

The suggested fix was wrong. Your app needed entries to expire per user. The library couldn’t do that. You had checked this before writing the cache. But the comment still exposed a real problem. Nothing in the code said why the custom cache existed. The reviewer couldn’t tell, so the next reader wouldn’t either.

That gives you two findings in one comment. The design held up. The way you explained it didn’t. The second finding is what your answer is about.

Find the part that was right before you prepare anything else

Most mixed feedback splits this way. The suggestion is wrong. The reason someone made it is real. Google’s public code review guide makes the same point about handling reviewer comments. If a reviewer doesn’t understand your code, the guide says to clarify the code first. A reply in the review tool comes last. Its reasoning is that future readers will probably be confused in the same place. The reviewer’s confusion is evidence even when their proposed fix is not.

Feedback about how you work splits the same way. Say a manager told you that you ship too slowly. The main cause may have been a review queue that blocked you for days. But you may also have stayed quiet about the blocks. The part you own is usually smaller than the criticism. It is still the part to build the answer on.

If you can’t find a real valid part, this is the wrong story. A review that was “all wrong except a typo” gives you nothing to change.

A complete sample answer to tell me about a time you received critical feedback

I built a small cache for our feed screen. In review, a senior engineer asked me to replace it with a standard library. They were right about the underlying problem. Nobody reading that code could tell why a custom cache existed. That was on me.

So I fixed the explanation first. I added a short comment at the top of the class. It explains that the library can’t expire entries per user. It also links the ticket where we found that. Then I added a one-page design note for the module. After that, I started adding a ‘why’ section to any pull request with a non-obvious choice. Over the next few months, reviewers stopped asking why things existed. A new teammate later took over that module without needing a walkthrough from me.

On the library itself, I disagreed. I showed them the per-user expiry requirement and asked if they saw the tradeoff differently. They agreed the library didn’t fit, so we kept the cache.

What I took from it is simple. A reviewer’s confusion is a bug report on my code, even when their suggested fix is wrong.

Why each part of that answer is there

The first paragraph concedes early and in the first person. “That was on me” comes before any mention of disagreement. So the interviewer hears everything after it as coming from someone who took the point.

The second paragraph is the longest on purpose. It names specific changes and gives evidence that they lasted. Reviewers stopped asking. A new teammate didn’t need a walkthrough. GitLab’s handbook guidance on receiving feedback says to reflect, then act on the most impactful changes. It lists overdoing the response as a pitfall. A few changes that stuck beat a long list.

The third paragraph handles the disagreement in three sentences. It follows the tone Google’s guide recommends. You explain the tradeoff you weighed and ask whether the reviewer weighs it differently. The disagreement is resolved inside the story, so nothing is left open.

The last line states the lesson in one sentence. It’s specific to this story, so it doesn’t sound rehearsed.

As a rough split for a two-minute answer, give the concession about 20 seconds. Give the change about 60 seconds. Keep the disagreement to about 20 seconds and the result to about 10.

If the disagreement didn’t end in your favor

Suppose the reviewer insisted and your lead sided with them. Say so plainly, then say what you did next. Maybe you adopted the library and added a workaround for per-user expiry. Maybe it worked better than you expected. Either ending works if you committed once the decision was made.

Two endings don’t work. One is an ending where the argument still sounds open, as if you’re still making your case. The other is an ending where you said nothing at the time and went along. The first sounds like a grudge. The second suggests you won’t raise a concern when it matters.

What to say when the interviewer asks “did you agree?”

Interviewers often follow up by asking whether you agreed. A mixed story lets you answer honestly:

Mostly. The core point was right. I changed how I document decisions because of it. One suggestion didn’t fit a requirement we had. I raised that at the time. We kept the original design.

That takes about ten seconds and doesn’t reopen the argument.

A candidate who answers “completely” to every piece of feedback can start to sound scripted under probing. Our post on behavioral interview follow-up questions covers how that probing works.

Three signs to pick a different story

A mixed story fails in three situations. Check yours against each.

• The disagreement takes up half the answer. At that point you’re telling a conflict story. Conflict has its own question.
• You can’t describe the other person fairly. A story that needs a bad reviewer to make sense reads as blame.
• Nothing about how you work changed afterward. Without a change, there’s no answer to the question.

Before the interview, say your version out loud and time each part. Then ask a friend what they remember. If they remember the argument before the change, move time from the third part to the second.