Tell me about a time you got harsh or blunt feedback on a code review.
answer
- name the comment and its bluntness
- what you felt versus what you did
- asked for the reasoning, not the verdict
- the change you actually made
- the relationship and habit afterwards
basics
~10 sTests whether criticism of your code lands as criticism of you. Answer with one blunt comment, what you did to understand it before replying, the change you made, and the working relationship afterwards.
how to answer
5 beats- the change and who reviewed itTwo sentences: what you were building and who was reviewing, enough that the comment lands. Setup plus stakes should take about fifteen to twenty percent of your airtime — resist explaining the whole system.
- the comment, in their wordsQuote it or paraphrase it closely, including the bluntness. Sanding it down removes the difficulty the question is asking about, and a real quoted line is the most memorable thing in the answer.
- what you did before you repliedThis is where the signal lives. Name the pause, the re-read, the reproduction, the request for the mechanism. Say honestly what you did not understand at the time rather than implying you knew all along.
- what you changed, and what you asked forGive the concrete fix and any guardrail that came with it — a test, a smaller PR, a check. This beat plus the previous one should carry roughly sixty percent of the answer.
- where the working relationship ended upClose with the outcome and the durable habit in about twenty percent of the airtime. The strongest ending is evidence you now seek that reviewer out rather than avoid them.
your answer
5 story prompts- Pick a review comment that stung and turned out to be right — vindication stories fail this question.
- Write down the harshest sentence as close to verbatim as you can remember it.
- Name one thing you did not understand at the time and how you closed that gap.
- Find the guardrail that came out of it: a test, a smaller change, a checklist item.
- Note where the relationship stands now — that is your closing line.
draft and rehearse your own answer in a learn session
go deeper
Interviewers use this to test coachability and ego under direct criticism: whether you can hear a claim about your code as a claim about your code. A strong answer shows you sought the reasoning before defending, acted on it concretely, and kept the working relationship — evidence that review feedback on this hire will produce fixes rather than friction.
I was a few weeks into my first job, on a four-person team moving our services off hardcoded database credentials and onto a managed secret store. My first real change was the helper every service would use to fetch and cache its credential. The review came back with seventeen comments, and the first one said my cache would hand out revoked secrets, so this change would open a security hole rather than close one. It felt personal, so I did not reply that day. The next morning I read it again as a technical claim and realised I could not actually explain why my expiry logic was safe. I asked the reviewer for fifteen minutes and said plainly that I understood the objection but not the mechanism, and could they walk me through how a lease is revoked. They drew it out: the store can revoke a lease before my own timer expires, so I had to honour the lease's expiry rather than one I invented. I rewrote the helper to refresh on the lease and added a test that forces an early revocation. It merged on the second pass. The first six services cut over on that helper, and their rotation lag dropped from forty-one days to under three. Since then I ask for the mechanism first and argue second, and that reviewer is one I now request on purpose.
The signal is the pause plus the admission of what was not understood, followed by a concrete guardrail — the revocation test — rather than only a code change. Cutting the closing habit and the relationship line, or softening the quoted comment, would downlevel it to a generic feedback story.
By the second half of that credentials migration I owned the cutover for our batch-processing services. I opened the rollout as a single change: the injection path, the config for twenty-three services, and the deletion of the old credential file. A reviewer from the platform-security group left one line — this is not reviewable, and I am not approving a change that touches auth on twenty-three services at once. No detail, no nits, just a block. I was irritated, because I had sized it that way deliberately to keep the cutover atomic. But re-reading it, the objection was about their ability to verify, not about my design, and that is a legitimate reason to block. So I replied that I would split it and asked one question: what shape could they review confidently. Their answer was the injection path alone, then services in tiers, riskiest last. I split it into four changes and each merged inside three days instead of sitting a week. The tiering also caught something I would otherwise have shipped: two batch jobs read their credential once at start-up, so they would have run for days on a stale one after a rotation. Worst-case staleness on that fleet finished at four days, down from thirty-eight. Now I ask reviewers what size they can review before I open the change, not after.
Strength here is separating the reviewer's real concern (verifiability) from the tone, then converting the block into a design question with one clarifying ask. The near-miss the split uncovered is what proves the concession was correct; dropping it would leave a compliance story with no payoff.
One PR of your own, one comment, and proof you went after the mechanism rather than the verdict. Naming what you did not understand is a strength here, not an admission.
Show that you sorted the comment into defect, risk or preference before responding, and that the fix generalised — a test, a checklist item, a smaller PR next time.
The feedback should touch a decision you owned, not a line you wrote, and the answer should include what changed in how your team reviews or how you scope changes afterwards.
Talk about receiving criticism when you are the most senior voice in the thread, where juniors are watching how you take it, and what you did to keep that channel open across teams.
saying these in an interview costs you the question
- Picking feedback that turned out to be wrong so you can be right
- Describing the reviewer as rude, junior-hostile or on a power trip
- Performing zero reaction — nobody believes blunt criticism felt like nothing
- Conceding instantly with no evidence you understood the objection
- Ending at 'I made the change' with no shipped outcome and no habit
- Choosing a trivial nit so the story costs you nothing
- How did you feel when you first read it?Name the reaction honestly and briefly — stung, defensive, embarrassed — then move straight to the gap between the feeling and the action you took. A flat 'I felt fine' reads as either untruthful or uninvested; two sentences of feeling plus a concrete first action is the whole answer.
- Was any of that feedback wrong?If part of it was, say so with the reason you gave the reviewer at the time and what happened next. Do not use the question as a trapdoor to relitigate the whole review. If it was all fair, say that plainly rather than inventing a partial win.
- How do you handle comments like that now?Give one durable, checkable habit rather than a sentiment. Something like asking for the mechanism before defending, waiting a beat before replying, or opening smaller changes. Tie it to a second occasion where you used it, if you have one.
### What is actually being probed This prompt is a coachability test wearing engineering clothes. The interviewer is not curious about the code. They want to know what your team's review threads will look like once you are hired: whether a blunt comment produces a fix, a sulk, or a fight. Almost every candidate says they welcome feedback. The story is what separates them. ### The variants You will meet this as 'tell me about a time you received difficult feedback', 'what is the most critical feedback you have ever received', 'tell me about a time someone criticised your work publicly', and the review-specific form. Prepare one story and re-angle the opening sentence; the beats do not change. If the question says 'the most critical feedback', pick the one that actually cost you something rather than the most recent one. ### Choosing the story — where most answers are lost Three bad choices are common. The first is picking feedback you were later proved right about, which turns a coachability answer into a vindication answer and reads as unable to be wrong. The second is picking something too small — a naming nit — so nothing was at stake and there is nothing to learn from. The third is picking feedback about a personal trait rather than work, which drags the answer into territory the interviewer did not ask about. The strongest choice is feedback that was correct, delivered badly, and about something you cared about. That combination is the only one where your composure is actually tested, and it lets you show two skills at once: separating the substance from the tone, and closing the technical gap the comment exposed. ### Weak versus strong A weak answer sounds like: the reviewer was harsh, I did not take it personally, I made the changes, and now we are fine. Every clause is unfalsifiable. A strong answer quotes roughly what the comment said, names the reaction honestly, then shows a specific act of investigation — re-reading it as a claim rather than an attack, asking for the mechanism, reproducing the failure the reviewer predicted. That act is the evidence. Everything before it is atmosphere. The second thing strong answers do is separate the tone question from the substance question and answer them in that order, briefly. 'The delivery was blunter than I would write it. It was also correct.' That single move shows you can hold both without either excusing rudeness or hiding behind it. ### Evidence that carries weight A quoted or near-quoted comment. A named thing you did not understand at the time. A test or guardrail you added because of it. A number attached to the outcome, even a small one. And a durable habit that has survived past that one review — the interviewer is buying future behaviour, and a habit is the only part of the story that predicts it. ### How the bar moves Early-career, the gap the feedback exposed is allowed to be a knowledge gap, and closing it honestly is the whole signal. Mid-level, the interviewer expects you to have triaged the comment — defect, risk, or preference — before responding, and to have generalised the fix. Senior, the feedback should land on a decision you owned rather than a line you typed, and the answer should show something in the team's process changing. Above that, the interesting version is receiving hard criticism from someone more junior than you, where the whole team is watching whether it is safe to send. ### The ending most people skip Say where the relationship went. The single most persuasive closing line in this family is that the blunt reviewer became someone you now request on purpose. It proves the criticism was processed rather than survived, and it costs one sentence.