Lesson 1 of 5
Giving & Receiving Feedback
"Feedback is a gift. It's also a skill — and most people are giving it wrong and receiving it worse." — a staff engineer who runs her team's calibration reviews
Somewhere on every team is a quietly decisive fact: the engineers who grow fastest are not the smartest ones. They're the ones who can hear "here's what you did that didn't work" without their face closing over — and who can say the same to a peer without lighting a fuse. Feedback is the mechanism by which a career compounds. Turn it off and you stop improving the day your last honest manager leaves.
Interviewers know this, which is why feedback shows up as its own family of behavioral questions: tell me about feedback you received; a time you gave someone difficult feedback; a time you disagreed with feedback you were given. These questions are a coachability probe wearing a disguise. A candidate who takes feedback well is a candidate who will keep getting better after you hire them. A candidate who gets defensive in a low-stakes interview will get defensive in a high-stakes retro.
This chapter is about feedback in both directions — the giving and the receiving — because they're the same muscle worked from two ends. By the end you'll have a framework for delivering hard truths without bruising egos, a discipline for receiving them without flinching, and two worked model answers you can adapt.
When an interviewer asks about feedback you gave or received, what are they really trying to learn about you — and why does how you handle a single critical comment predict how your whole career will go?
Why feedback is the coachability signal
Every hiring manager is secretly asking one question that no rubric prints: will this person still be improving in two years, or will they plateau the moment I stop pushing? Coachability is the answer, and feedback is where it becomes visible.
Think about what receiving feedback well actually requires, all at once, in real time: you have to override the reflex to defend yourself, stay curious about a version of events that makes you look worse, extract the useful signal from a possibly clumsy delivery, and then change something. That's emotional regulation, humility, and follow-through in a single moment. It's rare. And it's exactly the bundle of traits that makes someone worth investing in.
How it plays out In a promotion calibration, the sentence that quietly sinks a strong engineer is: "Technically excellent, but you can't tell them anything — every piece of feedback turns into a debate." The sentence that quietly lifts someone: "I mentioned once that her design docs were too dense, and the very next one led with a one-paragraph summary. You give her feedback once and it sticks." Managers talk to each other. The reputation of being coachable travels faster than your commits do.
Giving feedback: care personally, challenge directly
The two failure modes of giving feedback are opposite and equally common. Some people care so much about the relationship that they soften the message into mush — the recipient leaves the conversation feeling fine and having learned nothing. Others deliver the truth like a citation, technically accurate and humanly brutal. Kim Scott named the sweet spot Radical Candor: you earn the right to challenge someone directly by first showing you genuinely care about them. The two axes are independent, and where you land on both defines the quadrant.
| Challenge directly | Don't challenge | |
|---|---|---|
| Care personally | Radical candor — the honest, kind feedback that helps | Ruinous empathy — you're nice, they never improve |
| Don't care personally | Obnoxious aggression — right, but cruel; people stop listening | Manipulative insincerity — the silent shrug behind their back |
Most engineers drift toward ruinous empathy ("I didn't want to make it awkward") and mistake it for kindness. It isn't. Withholding feedback someone needs is a decision to let them keep failing where you could see it and they couldn't. The kind thing and the honest thing are the same thing.
The mechanics: SBI and the principles that make it land
Caring is the posture; you still need a structure so the words come out clean. The most reliable one is SBI — Situation, Behavior, Impact. You anchor to a specific moment, describe the observable behavior (not your interpretation of their character), and name the concrete impact it had. Then you stop and listen. SBI works because it stays on the ground floor of facts: a behavior can be changed and an impact can be understood, whereas "you're careless" is an attack on identity that only invites a defense.
| Principle | Do | Don't |
|---|---|---|
| Timely | Give it within days, while the moment is fresh | Save it up for the performance review "ambush" |
| Specific | "In yesterday's review, three comments were one-word rejections" | "Your reviews are kind of harsh sometimes" |
| Behavior, not person | "You pushed to main without a review" | "You're reckless" |
| Actionable | Name the concrete change you're asking for | Describe the problem and leave them stranded |
| Kind and direct | Say the hard thing, warmly and plainly | Bury it in so many qualifiers it disappears |
SBI in the wild — a worked script. A teammate, Lena, has twice pushed hotfixes straight to main during incidents, skipping review. Here's the whole thing, delivered privately, in under a minute:
Situation: "During Tuesday's incident, and again last Thursday when the search index fell over —"
Behavior: "— you pushed the fix directly to main without opening a PR or pinging anyone."
Impact: "I get why in the moment — you wanted it fixed fast. But Thursday's fix quietly reintroduced a bug we'd already patched, and afterward none of us were sure what state main was actually in. It cost us an hour of confusion the next morning."
The ask + the door: "Could we agree that even during incidents, we get a second pair of eyes — even a 30-second async review after the fact? I'd rather we're both slightly slower and sure. What's it look like from your side?"
Notice the shape: specific moments, observable actions, real impact, a concrete ask, and then a genuine question that hands them the floor. No character verdicts. No pile-on. She can say yes to this.
Feedback in code review, without the ego bruises
Code review is where most engineers give and receive the most feedback — and where it most often goes wrong, because text has no tone and a reviewer's terse "why?" reads as contempt at 5 p.m. A few habits keep the ego intact while keeping the bar high:
- Review the code, not the coder. "This function does X" not "you always do X." The PR is the subject, never the author.
- Separate blocking from optional. Prefix nits with
nit:oroptional:so the author knows what actually gates the merge. A wall of undifferentiated comments feels like a wall of rejection. - Ask, don't decree. "What do you think about pulling this into a helper?" invites a conversation; "extract this" issues an order. You're often the one who's missing context.
- Say what's good. A "nice — this is much cleaner than the old path" costs nothing and buys enormous goodwill. Reviews that are 100% criticism train people to dread your name in the reviewer list.
And the oldest rule in management, which survives because it's true: praise in public, correct in private. Celebrating someone in the team channel multiplies the good feeling; correcting them there multiplies the sting and adds an audience. Move the hard conversation to a DM or a call. The only feedback that belongs in public is the kind you'd be happy to receive there.
Receiving feedback: the harder skill
Giving feedback well is a craft. Receiving it well is a discipline, because it happens to you, often when you're tired, and every instinct you have is wrong. The instinct is to explain, to contextualize, to establish that it wasn't really your fault — and all of that reads as "I'm not listening." The move that separates senior engineers from junior ones is the ability to sit in the discomfort for a few seconds longer than feels natural.
| When you get feedback | Weak response | Strong response |
|---|---|---|
| First reaction | Defend, explain, counter-example | "Thank you — let me sit with that" |
| Understanding it | Assume you know what they mean | "Can you give me a specific example?" |
| The emotion | Take it as a verdict on your worth | Take it as data about one behavior |
| After the conversation | Nod, then change nothing | Pick one thing, change it, close the loop |
Four moves, in order. Say thank you — genuinely, because someone spent social capital to help you and most people won't. Listen for the truth in it, not the 10% that's unfair; even feedback delivered badly usually has a real signal buried inside, and your job is to mine it, not to litigate the delivery. Ask clarifying questions so you're changing the right thing — "when you say I dominate design reviews, is it that I talk too much, or that I shut down other options too fast?" Then act, and close the loop — go back weeks later and say "you told me X; here's what I changed." That last move is disproportionately powerful. It tells the giver their feedback mattered, which makes them far more likely to invest in you again.
Analogy Getting feedback is like a code review of you. When a reviewer flags your PR, you don't argue that the bug is unfair or that you had good reasons — you look at whether the code is actually broken, you fix it, and you thank them for catching it before prod. Feedback on your behavior deserves the same reflex: is the observation true? Then patch it. The engineers who argue every review comment are exhausting; so are the ones who argue every piece of personal feedback.
Two worked model answers
Model answer 1 — "Tell me about a time you gave someone difficult feedback."
Situation: "On my last team we had a senior engineer — I'll call him Marcus — who was genuinely brilliant and also the most feared code reviewer on the team. His comments were technically right and tonally brutal: one-word rejections, sarcastic 'did you even test this?' notes. I noticed our newest engineer, Dayo, had basically stopped opening PRs — he'd gone almost two weeks without one, and I realized he was sitting on finished work to avoid a Marcus review."
Task: "Marcus was more senior than me and this wasn't my code or my report — it would've been easy to leave it to a manager. But I liked Marcus, I could see he had no idea of his impact, and Dayo was quietly stalling. I decided to give Marcus the feedback directly and privately."
Action: "I grabbed him for a coffee, not a formal meeting, and used a plain structure. I named specific comments from that week — the observable behavior, not 'you're harsh as a person.' Then the impact: I told him Dayo had stopped shipping and I believed the review tone was why, and that his standards were actually a gift the team was starting to route around. I made one concrete ask: keep the exact same technical bar, but split comments into blocking versus optional, ask a question before rejecting, and note one thing that was good. Then I shut up and let him react. He was quiet, then said he'd genuinely never connected his comments to anyone's behavior."
Result: "Marcus changed almost overnight — his next reviews had 'nit:' prefixes and an actual 'nice cleanup here' on Dayo's first PR back. Dayo was opening a couple of PRs a week again within a month, and later told me that review was the one that made him feel safe. My part was seeing it early and being willing to give a senior peer hard feedback kindly rather than complaining about him sideways. What I took from it: the highest-leverage feedback is often the one nobody wants to deliver upward or sideways."
Model answer 2 — "Tell me about tough feedback you received and what you did with it."
Situation: "In a 1:1, my manager relayed something from a peer round of feedback that stung: several people found me dismissive in design reviews. The specific pattern was that the instant someone floated an idea, I'd jump in with why it wouldn't work. I was usually right — but people had started routing designs around me to avoid the wall."
Task: "My first instinct was to defend myself — I was catching real problems early, wasn't I? I caught that instinct. Whatever my intent, the impact was that good engineers were choosing not to get my input, which was bad for them and worse for me."
Action: "I did three things. First, in the moment, I said thank you and asked a clarifying question — was it that I objected too much, or too fast? He said too fast: I killed ideas before they were fully formed. That was the real signal. Second, I changed one concrete behavior: in reviews I made myself ask a genuine question before raising any objection, and I adopted a 'what would have to be true for this to work?' framing instead of a flat 'that won't work.' Third, a month later I went back to two of the people I knew had felt shut down and asked, directly, whether it was any better."
Result: "It was. One of them — a junior engineer — told me she'd started bringing me half-formed ideas again because it no longer felt like walking into a buzzsaw. Over the next quarter the number of design docs where teammates tagged me as a reviewer roughly doubled. I didn't lower my technical bar at all; I just moved my critique later in the conversation. The feedback that stung the most turned out to be the most useful I got that year — and closing the loop with the people it affected mattered as much as the change itself."
Notice what both answers do: clear "I," a real behavior (theirs or mine) that needed changing, a specific action, a measurable result, and — crucially — no villains. Marcus isn't a monster; I'm not a genius. They're two stories about behavior changing because someone was honest.
Common Mistakes
- The compliment sandwich. Praise-criticism-praise trains people to brace at every "nice work" and to miss the real message hidden in the middle. Be warm, then be clear, in that order — don't smuggle the point.
- Feedback about the person, not the behavior. "You're careless" gives someone nothing to change and everything to resent. Anchor to a specific action and its impact — that's what SBI is for.
- Saving it up. Feedback delivered three months late in a review is an ambush; the moment is cold and unfixable. Timely and small beats comprehensive and delayed.
- On the receiving end, defending instead of absorbing. Every "but the reason was…" reads as "I'm not listening." Say thank you first; you can add context later, if at all.
- Arguing the 10% that's unfair. Even clumsy feedback usually contains a real signal. Litigating the delivery lets you dodge the message — and marks you, correctly, as uncoachable.
- Nodding and changing nothing. The most expensive mistake. Feedback you don't act on is worse than none, because now the giver knows telling you is pointless — and they'll stop.
Grade your own answer Think of the last piece of critical feedback you got. Replay your actual response in the first ten seconds. Did you say "thank you," or did you say "well, the reason was…"? Did you ask what specifically they meant, or assume you already knew? And here's the real test: can you name one concrete thing you changed because of it — and did you ever tell them? If you can't, you have a story you haven't finished living yet. Finish it before your interview; the ending is the point.
Hands-on Build both sides of your feedback story bank right now.
Giving: Pick a real moment you gave someone hard feedback (or wish you had). Draft it as SBI: Situation (the specific moment) → Behavior (what they observably did) → Impact (the concrete effect) → the ask (one clear change) → the door (a question that hands them the floor). If you can't find a real one, you have your next assignment at work.
Receiving: Write the answer to "tell me about tough feedback you received" using this skeleton — "I got feedback that ___. My first instinct was ___, but I recognized ___. I asked ___ to understand it, then I changed ___. The result was ___, and I closed the loop by ___." The two lines that make it land are the specific change and the closed loop. If either is blank, the story isn't ready — go make it true.
Summary
- Feedback is the mechanism careers compound through, and interviewers probe it because it's the clearest coachability signal they have — how you handle one critical comment predicts how you'll handle a career of them.
- Giving well means care personally and challenge directly (radical candor); the mush of ruinous empathy isn't kindness, it's abandonment with a smile.
- Use SBI — Situation, Behavior, Impact — and keep feedback timely, specific, about behavior not the person, and actionable. In code review: separate blocking from optional, ask rather than decree, and note what's good.
- Praise in public, correct in private. The only feedback that belongs in front of an audience is the kind you'd be glad to receive there.
- Receiving well is a discipline: say thank you, listen for the truth, ask clarifying questions, then act and close the loop. The closed loop is what makes people invest in you again.
- The strongest interview answers show a real behavior changing — yours or someone else's — with a metric and no villains.
Feedback is the private, one-to-one edge of a larger skill: shaping what a group does without holding authority over it. Next we turn to influence and persuasion — moving people and decisions when "because I said so" isn't available to you.
Editorial reflection There's a version of you that treats every piece of feedback as an attack to be repelled, and a version that treats it as free information about the gap between how you land and how you mean to. The second version is not more talented than the first — it's just less afraid. The whole discipline of feedback, given and received, rests on a single unglamorous belief: that you are a work in progress and that's good news, not a verdict. Hold that, and the hardest conversations in your career stop being threats and start being the fastest way you'll ever grow.
Q&A · 0
Enrol to ask questions and join the discussion.
No questions yet — be the first to ask.