Tell me about a time you gave someone difficult feedback.
answer
- name the behavior, not the person
- the impact — why it mattered
- privately, and soon after
- what they said back
- the change you can point to
basics
~10 sTests whether you can say a hard thing kindly and precisely. Name one observable behavior and its impact, show you said it privately and soon after, and end with evidence the behavior actually changed.
how to answer
6 beats- the behavior and what it was costingOpen with the specific, observable thing the person did and the consequence you could see, in about fifteen to twenty percent of your airtime. Resist explaining the whole system; give only the context needed for the cost to land.
- how you set the conversation upSay where and when you chose to have it and why — private, soon after, enough time to hear a response. If you nearly said it somewhere public and did not, say that; the choice is itself the signal.
- the sentence you actually saidQuote yourself. Behavior, then impact, then a question rather than a verdict. This beat plus the next two carry the bulk of your airtime, and it is the beat most candidates skip entirely.
- how they responded and what you agreedReport the real reaction, including pushback, and any reason they gave that you had not known. End on one concrete thing they agreed to try and one thing you agreed to do.
- the change, with evidenceClose with something observable that moved — a count, a turnaround time, a behavior a third party could see. Say how long afterwards you checked; verifying is part of the skill, not an afterthought.
- what you would do differentlyOne honest edit, usually about timing or brevity. Keep it to a sentence or two; a long apology reads as lack of conviction rather than reflection.
your answer
5 story prompts- Pick feedback you delivered yourself, not one you asked a manager to pass on.
- Choose a case where you can state the behavior in one sentence with no adjectives.
- Find one observable piece of evidence that the behavior changed afterwards.
- Prefer a story where the person had a reason you had not considered.
- This can be your mentoring story re-angled to the hard conversation inside it.
draft and rehearse your own answer in a learn session
go deeper
This probes whether you can hold someone accountable without damaging the working relationship — the core of influence without authority. Interviewers look for specificity over character judgement, a private and timely setting, and evidence that behavior actually changed. Avoidance and bluntness both read as risk on a team that has to critique each other's work daily.
I was about six months in, on a four-person pod at a build agency shipping a quote form for an insurance client. A teammate who joined a month after me was hand-rolling validation instead of using the shared form utilities the agency maintained, and two of his branches went out with unhandled promise rejections. On our client-side error dashboard, sessions hitting a JavaScript error on that form sat at 4.2%, and most of them traced back to those two files. My first instinct was to write it as a review comment, and I stopped, because that would have been correcting him in front of the pod on a thread everyone reads. I asked for fifteen minutes at the end of the day and said one thing: when validation is hand-rolled we lose the shared error boundary, so the client sees blank fields instead of a message. I put the dashboard on the screen rather than my opinion of his code. He said he had never been shown the utilities existed — nobody had walked him through them — so we paired for an hour on his next ticket and I added a pointer to the pod's README. Over the next three sprints, errored sessions on that form dropped to 1.1%. What I would change: I sat on it for nine days first. Quiet and same-day beats well-worded and late.
The signal here is the delivery choice — moving off the public thread, one behavior, a dashboard instead of an opinion — plus a hypothesis about why it was happening that turned out to be right. It would downlevel if the speaker had escalated to a lead first, or ended the story before checking whether anything changed.
I was running a five-person pod on a booking flow for a travel client. Our fastest engineer left review comments like "no" and "this is wrong, redo it", and I noticed both juniors had stopped opening branches during the day — they were holding work until he logged off. That was showing up as delivery drag, but I opened it as a behavior conversation, not a throughput one. I took him for a coffee and used one review as the example: three comments with no reasons in them, plus a rewrite he had pushed onto someone else's branch himself. I told him the effect I could see, that the two of them had gone from a branch a day to one every third day, and asked whether that was what he intended. He was genuinely thrown; he had read terse as efficient, and nobody had ever told him otherwise. We agreed on two things to try for five weeks: every blocking comment carries a reason, and nothing gets rewritten on someone else's branch without asking first. Whenever he wrote a good version of a comment I forwarded it back to him. By the end of that window, junior merges went from four a sprint to eleven, and those two picked up the instrumentation work that took the flow from 3.6% of sessions erroring down to 1.4%. He now runs our review onboarding.
Strong because the feedback is about behavior toward people rather than code quality, the ask is small enough to actually try, and the verification is a number a third party could see. It would downlevel if the speaker had only complained about tone with no observed cost, or had gone to a manager before speaking to him.
Your scope is a peer and a shared codebase habit. The bar is that you said it yourself, to their face, rather than routing it to a lead — and that you went back later to see whether anything changed.
Pitch it at feature and pod scope: feedback about how someone works with others, not just what they typed. Show the mechanics — private setting, two or three concrete instances, one thing you asked them to try, an agreed check-in.
You should be carrying the consequence — delivery slipping, quality dropping — and the feedback should be one of several levers you pulled. Say what you changed in how the team works so the same feedback was less necessary next time.
Talk about the mechanism, not the conversation: how feedback reaches people across teams without routing through you, how you calibrate managers and leads who deliver it, and what you do when a norm rather than a person is the problem.
saying these in an interview costs you the question
- Describing the person's character or attitude instead of one observable behavior
- Delivering the correction in a group channel where it reads as public shaming
- Waiting months, so the example is stale and the person is blindsided
- No evidence the behavior changed, and no attempt to check
- Casting yourself as obviously right and the other person as the problem
- Softening so heavily that the actual message never gets said out loud
- How did they react in the moment?Give the real reaction, including defensiveness or silence, then what you did with it. Interviewers distrust a story where someone thanks you immediately. Show that you let them respond, asked whether your read matched theirs, and did not argue them into agreement.
- How did you know the behavior actually changed?Point to something observable you would have seen anyway — review turnaround, error counts, who is speaking up in a meeting — rather than your own impression. If you agreed a check-in, say when it happened and what you found.
- What would you say differently if you gave that feedback again?Pick a real edit: earlier, shorter, one instance instead of five, in person instead of written. Avoid answering that you would do nothing differently. The reflection is where junior and mid answers separate most visibly.
- What did you do when the change did not stick?Describe a second, more direct conversation with a clearer ask, and be honest about when you brought their manager in. Escalating is not a failure if you tried directly first and said out loud that you were going to do it.
## One question, several wordings This prompt appears in almost every loop, under several wordings: - "tell me about a time you had to have a difficult conversation with a teammate" - "a time you had to correct someone's work" - "how do you handle it when a colleague is doing something wrong" - and the manager-flavoured "a time you gave feedback that was hard to hear". They are one question. The interviewer is not testing whether you were right; they are testing whether you can carry a hard message to a person without either avoiding it or bruising them. ## The structure that survives probing Most engineers can describe the problem and skip the conversation. Force yourself to say the sentence you actually used. A useful frame is **situation-behavior-impact**: - the moment it happened, - the specific thing they did, - and the consequence you could observe. "In Tuesday's review you pushed a rewrite straight to their branch, and they stopped opening PRs before you were offline" is feedback. "You're too blunt with juniors" is a verdict wearing feedback's clothes. The difference is that the first one can be disagreed with on facts and the second can only be disagreed with on identity. ## Airtime Setup and stakes should take fifteen to twenty percent of your telling. The bulk — sixty percent — is **delivery**: how you chose the setting, what you said, what they said, what you agreed. The last quarter is result and reflection. The commonest failure is a ninety-second explanation of the codebase followed by "and then I told them and it was fine". ## Weak versus strong on the same facts **Weak:** "A teammate kept writing sloppy code so I flagged it in the team channel and eventually my lead had a word with him." **Strong, same facts:** "I saw the same class of bug in three of his PRs, so I asked for ten minutes, showed him the three, told him what it cost us on-call, and asked what would make the shared utilities easier to find. He hadn't known they existed. We paired once, and the pattern stopped." The second answer contains a **hypothesis about *why* the behavior existed**, which is the single strongest signal in the family — feedback that assumes malice or laziness rarely changes anything. ## Evidence types, in rough order of persuasiveness 1. a number you would have been tracking anyway; 2. a behavior a third party could see change; 3. a thing the person later did unprompted; 4. your own impression. Do not stop at the last one. If you truly have no evidence, say so plainly and say what you would measure now — that is a better answer than an invented outcome, and interviewers can hear the invention. ## How the bar moves - **At junior level**, saying it directly at all is most of the signal; nobody expects you to have changed a team's culture. - **At mid**, the interviewer wants the mechanics: private setting, specific instances, an ask small enough to act on, a follow-up you actually kept. - **At senior**, they want to see that you owned the outcome the behavior was damaging and that you fixed the environment too — a missing convention, an unclear ownership line, a review norm — because feedback that has to be repeated to every new hire is a system problem. - **At principal**, the story is about how hard messages travel through an organisation without you in the room. ## Two traps 1. The first is choosing a story where you were right and they were wrong in an obvious way; it teaches the interviewer nothing about your judgement. The stronger choice is one where you were partly wrong, or where the person had a reason you had not considered. 2. The second is praising publicly and correcting publicly. If your story has the correction happening in a channel or a standup, expect that to become the whole follow-up conversation.