Giving and Receiving Feedback

you changed someone's work, or your own, because of what was said

What is scored: can you deliver a hard message without damaging the relationship, and can you take one in without getting defensive or performative about it?

The trap is a story about feedback that was actually praise, or a story where you delivered it and never found out whether it landed.

What the interviewer is looking for

This competency is really two, and most candidates only prepare one.

Giving it well:

You addressed something that mattered, not a nitpick used to prove you give feedback at all.
You said it directly, to the person, close to the event — not in a retro, not through a manager, not three weeks later when it reads as a grudge.
You separated the behaviour from the person and stayed specific: an action and its effect, not a character judgement.
You checked it landed, and ideally can say what changed afterward.

Receiving it well:

You did not get defensive in the room, even if your first instinct was to explain it away.
You separated the valid part from the delivery, if the delivery was poor — harsh feedback can still be correct feedback.
You actually changed something, not just thanked them and continued as before.

Most candidates have a giving story. The receiving story is rarer and is disproportionately valuable, because it demonstrates you can be managed and can improve — exactly what a panel cannot verify from a resume.

Weak and strong, same prompt

Prompt: tell me about a time you gave someone difficult feedback.

Weak.

"A junior engineer on my team was writing code that didn't follow our conventions. I pulled them aside and explained our style guide and why consistency matters. They took it well and their code improved after that."

No specific incident, no actual words exchanged, no sign of discomfort on either side, and "took it well" with nothing to support it. This reads as a policy statement about being a good mentor, not an event.

Strong.

"A engineer two levels below me, Sam, had shipped a change that removed an error handler because it was 'noisy in the logs.' The handler was catching a real failure mode — a downstream timeout — and removing it meant the failure would surface as a silent data gap three steps later, which is much harder to debug. I found it in review before it merged, so nothing broke, but the instinct behind it worried me more than the diff — Sam was optimising for quiet logs over correctness, and that's a pattern, not a one-off. I asked for ten minutes that afternoon rather than commenting in the PR, because I wanted it to be a conversation, not a correction on the record. I said what I saw — 'this removes the only signal we have for a real failure mode, and I think the actual problem is the logging is too noisy, which is a separate thing worth fixing' — and asked what had driven the change, rather than assuming. Sam said the noisy logs had genuinely made a different incident hard to triage the week before, which I hadn't known — so the instinct came from a real frustration, just aimed at the wrong fix. We fixed the logging noise properly instead, and Sam ended up owning that cleanup. I checked in two weeks later, informally, on an unrelated PR — the error handling there was solid, and Sam mentioned the earlier conversation unprompted, which is how I knew it had actually landed rather than just been endured."

A real incident with a name and a mechanism, feedback given close to the event and in person, curiosity about the cause before delivering a verdict, and a way of confirming it changed something rather than assuming it did.

The receiving side, weak and strong

Prompt: tell me about a time you received tough feedback.

Weak.

"My manager once told me my documentation could be clearer. I took the feedback on board and made sure to write clearer docs going forward."

Low stakes, no discomfort, no specifics about what changed. This is the behavioral equivalent of "my greatest weakness is I work too hard."

Strong.

"In a project retro, a peer said that I'd made a call on the database schema without looping in the two other services that read from it, and that her team had found out when their queries broke after I shipped it. My first reaction, which I didn't say out loud, was that I'd posted it in the team channel and technically anyone could have seen it. I sat with it overnight instead of responding in the room. Posting in a channel and actually looping someone in are different things, and I knew that — I'd told myself the channel counted because it was more convenient than messaging two people directly. That was the real feedback, once I separated it from my own defensiveness: I optimise for what's easy for me to do, not what's easy for others to notice. I messaged her the next day, said she was right and that 'I posted it' wasn't the same as 'I told you,' and asked how she'd want to be looped in on schema changes going forward. We agreed I'd tag the two consuming teams directly on anything touching shared tables. I've kept that since — it's now just part of how I make that kind of change."

The defensive reaction is named honestly rather than hidden, there's a real gap between "technically visible" and "actually communicated," and a concrete, still-current change in behaviour rather than a vague promise.

Question bank

Tell me about a time you had to give someone feedback they didn't want to hear.
Describe a time you received critical feedback. How did you respond?
Tell me about a time you disagreed with feedback you were given.
How do you approach giving feedback to someone more senior than you?
Tell me about a time feedback you gave did not land the way you intended.
Describe a time you had to correct a mistake someone else made, without a manager involved.

"Feedback you gave that did not land" is the pair to the main prompt and is rarely prepared — the honest answer is usually about timing, forum, or not checking for understanding, not about the other person being unreceptive.

Where these answers go wrong

The feedback was actually praise, or trivial. "I told them their code was really good" is not what this question is asking, and neither is a genuine nitpick inflated to sound hard. If it did not cost you anything to say, it is the wrong story.

No verification it landed. "They took it well" with no evidence is exactly as unverifiable as it sounds. A strong answer has a second data point — a later PR, a follow-up conversation, a changed pattern — not just the immediate reaction in the room.

The receiving story has no real discomfort in it. If your first instinct was gratitude rather than defensiveness, either the feedback was gentle or you are not being honest about the reaction. Interviewers can tell the difference between an honest "my first thought was to explain it away" and a sanitised version.

Correcting the behaviour but not naming what you personally got wrong. In the receiving version, "I improved my documentation" is weaker than "I realized I had been optimising for X when the actual requirement was Y" — the first is a task, the second is a real update to how you think.

Public correction of someone junior. A story where you corrected someone in a group setting, even gently, reads as a red flag about how you handle mentorship — the strong pattern is always a private, direct conversation first.

How to say it in the interview

"I told him directly, in private, the same day - not in the retro two weeks later where it would have been about the process instead of about him."

Checklist

The feedback given addressed something that actually mattered
It was delivered directly, in private, close to the event
You asked about the cause before delivering a verdict
You can point to evidence it landed, not just the reaction in the room
The receiving story includes a real, honestly-named defensive reaction
You separated what was valid in the feedback from how it was delivered
You can name a specific, still-current change in your behaviour
Any correction of someone junior happened in private

Practice this interactively