How to Answer "Tell Me About a Time You Received Constructive Feedback" (With 4 Sample Answers)

This is one of the most commonly asked behavioural questions, and one of the most commonly bungled. Most candidates treat it as a question about a piece of feedback. It isn't. It's a question about what you did in the days and weeks after the feedback, and everything that matters in your answer happens after the criticism is delivered.

What the interviewer is actually testing

Interviewers ask this for three reasons, usually in this order of importance:

Are you coachable? Every new hire is wrong about something in their first six months. Your manager needs to know that telling you so will be a two-minute conversation rather than a three-week sulk.
Do you have accurate self-knowledge? Someone who can describe a real weakness precisely, without drama, is usually someone who has thought about their own performance seriously.
Do you close the loop? Plenty of people accept feedback gracefully and then change nothing. The interviewer is listening for evidence that behaviour actually changed and that somebody noticed.

There's also a quiet disqualifier running underneath. If you can't produce any example, or the one you produce is trivial, the interviewer concludes either that nobody has ever trusted you with honest feedback or that you didn't hear it when they did. Both are bad.

A structure that works

Use four beats. Aim for roughly 90 seconds — long enough to be concrete, short enough that they can ask a follow-up.

The feedback, stated plainly. Say what was actually said, in the words it was said in. "My manager told me my design reviews were slowing the team down" beats "I received some feedback around my communication style."
Your honest first reaction. One sentence. If it stung, say so. Candidates who claim they felt nothing sound rehearsed; candidates who admit a flash of defensiveness and then move on sound human and self-aware.
What you changed, specifically. This is the heart of it. Name the mechanism, not the intention. "I started sending a written summary the day before instead of presenting cold" is a mechanism. "I worked on communicating better" is not.
How you knew it worked. Evidence, ideally from someone else's mouth. A follow-up conversation, a metric, a changed outcome.

Choosing the right example

The best examples share three properties: the feedback was about something that genuinely matters at work, it was uncomfortable enough to be believable, and the fix is verifiable.

Avoid the two default choices most candidates reach for. Feedback from a university group project signals you have nothing more recent. Humblebrag feedback — "they told me I take on too much" — is transparent and interviewers hear it several times a week.

Pick something that costs you a little to say. Slow to delegate. Too blunt in code review. Over-engineered the first version. Buried the point in long emails. These are real, common, fixable, and none of them will cost you the offer.

Four sample answers

Sample 1 — mid-level software engineer

"About a year into my last role my tech lead told me in our 1:1 that my code reviews were holding the team up. I was leaving thirty or forty comments on a pull request, most of them style preferences, and people had started routing around me.

My first reaction was that I was being asked to lower the bar, and I was a bit stung, because I thought thorough reviews were the thing I was good at. But she pointed out that I was mixing 'this will break' with 'I'd have named this differently', and the important comments were getting lost in the noise.

So I changed how I reviewed. I started prefixing every comment with 'blocking', 'suggestion' or 'nit', and I capped myself at three nits per review. If I had more style opinions than that, it went to the team's linting config instead of a person's pull request.

Two months later the same lead told me my reviews had become the ones people specifically requested, and our median time-to-merge dropped from about two days to under one. I still use the blocking/suggestion/nit convention, and I introduce it on every team I join."

Sample 2 — early career, first job

"In my first six months as a marketing coordinator, my manager told me my weekly reports weren't useful to her. She said she was getting five paragraphs of what happened and nothing about what she should do with it.

I'd been proud of how thorough those reports were, so it took me a day to stop being defensive about it. Once I did, I asked if I could see a report she considered good, which turned out to be the most useful thing I did that year.

I rewrote the format: three bullets at the top — what moved, what I'm worried about, what I need a decision on — and the detail underneath for anyone who wanted it. She started forwarding it to her own director without editing it, which she'd never done before. I've written every status update that way since."

Sample 3 — senior individual contributor

"When I moved into a staff engineer role, my director gave me some feedback in my six-month review that I've thought about ever since. He said I was still operating like the most senior engineer on one team rather than an engineer who influenced several, and that I was solving problems personally that I should have been teaching other people to solve.

I didn't disagree, but I did think it was unfair at first, because I'd been fixing the things that were on fire and nobody had told me to stop. What he was really saying was that I'd become a bottleneck by being useful.

I changed two things. I stopped picking up urgent work directly and instead paired with whoever owned it, which was slower for about a month and faster after that. And I started writing up the recurring failures as short internal docs — we ended up with eight of them, and the on-call load dropped noticeably because people could self-serve.

At my next review he used the phrase 'force multiplier', which was the exact gap he'd named six months earlier, so I take that as the loop closing."

Sample 4 — career changer

"When I moved from teaching into customer success, my onboarding buddy told me after listening to a few of my calls that I was explaining too much. I'd answer a customer's question and then keep going for another two minutes, and I was losing them.

It was a hard one to hear because explaining things clearly was the skill I thought I was bringing with me from ten years in a classroom. But a customer on a support call isn't a student — they want the answer and their afternoon back.

I started giving the one-sentence answer first and then explicitly asking 'do you want the background on why?' Maybe a third of the time they said yes. My average call length dropped by about four minutes and my CSAT went from the middle of the team to the top three within a quarter."

What separates these from weak answers

Compare those to the version interviewers hear most often: "My manager said I should communicate more, so I made sure to communicate more, and it went well." Nothing in that sentence can be checked, pictured, or followed up on. Three tests your answer should pass:

Could the interviewer picture the specific behaviour that changed? If your change is a verb like "improved" or "focused on", it isn't specific yet.
Is there a number, a date, or a second person in it? Evidence someone else could corroborate.
Does it cost you anything to admit? If not, it reads as a rehearsed strength in disguise.

Common mistakes

Saying you can't think of an example. This is the single worst answer available and it's more common than you'd think. Prepare one.
Relitigating the feedback. Explaining why the criticism was unfair, even briefly, tells the interviewer exactly how you'll respond to their feedback.
Criticising the person who gave it. Even a mild "she wasn't very good at delivering it" reframes you as the difficult one.
Choosing something too small. Feedback about a typo in a slide deck signals you're managing the interview rather than answering it.
Stopping at "I took it on board." Without the change and the evidence, you've described listening, not growth.
Using a five-year-old example when you have a recent one. Recency suggests you're still receiving honest feedback, which suggests people trust you with it.

Follow-up questions to expect

A good interviewer will probe. The three that come up most:

"How did you feel in the moment?" — They want a real emotional response, not stoicism. Naming the discomfort and then describing what you did with it is the strong answer.
"Was there feedback you disagreed with, and what did you do?" — This one is a trap for people who over-index on agreeableness. The good answer involves asking for specifics, testing the claim, and either changing your mind or making the disagreement explicit and respectful. Blanket agreement is as much a red flag as defensiveness.
"How do you seek out feedback now?" — Have a real mechanism ready. Asking a specific question ("was that document too long?") gets useful answers; asking "any feedback for me?" almost never does.

Preparing your own version

Write out two examples rather than one, ideally from different jobs, so a follow-up doesn't leave you empty-handed. For each, write a single sentence for each of the four beats — feedback, reaction, change, evidence. Don't script it word for word; interviewers can hear a memorised paragraph, and it undercuts the authenticity the question is built to test.

Then say it out loud once and time it. If you're past two minutes, the detail you're adding is almost certainly setup rather than substance.