Giving or Receiving Difficult Feedback

The question — "Tell me about a time you gave or received difficult feedback." Variants: "Describe a situation where you had to deliver critical feedback to a peer.", "Tell me about a time you received feedback that was hard to hear — how did you respond?"

What they're assessing — Directness paired with empathy; choosing the right timing and a private setting; framing feedback around behavior and impact rather than personality; when receiving, demonstrating non-defensiveness and genuine openness; concrete follow-up that shows the feedback actually changed something.

STAR-L scaffold

Fill in your own story:

• Situation — Describe the relationship (peer, report, or manager) and the behavior or pattern that prompted the feedback. If receiving, describe the context and what the feedback was. What were the stakes — project quality, trust, team dynamics?
• Task — What outcome did you need the feedback conversation to achieve? Were you trying to protect a relationship, prevent a recurring problem, or course-correct a deliverable?
• Action — How did you prepare and set up the conversation — use "I" and name specifics (e.g., asked for a private 1:1, wrote out specific examples beforehand, led with intent before content, asked for their perspective before stating yours)? If receiving, how did you respond in the moment and what did you do afterward?
• Result — What changed? Did behavior improve, the relationship strengthen, or your own work improve? Quantify if possible (e.g., the pattern stopped, we shipped without the recurring issue, my next code review came back clean).
• Learned — What did this teach you about giving or receiving feedback? What do you do differently now?

Pitfalls / red flags

• Avoiding the conversation entirely or describing a watered-down version that was so gentle it conveyed nothing.
• Being harsh or personal — feedback about character rather than behavior and impact signals low emotional intelligence.
• Getting defensive when receiving: dismissing the feedback, explaining it away, or blaming the giver.
• No follow-up or change afterward — the feedback conversation happened but nothing actually shifted.

Example (generic — replace with your own)

Situation: A peer engineer on my team was consistently submitting pull requests with minimal context — no description, no test coverage explanation, no link to the relevant ticket. Three other engineers had mentioned it in passing to me but no one had said anything directly. It was slowing down our review cycle and creating review fatigue.

Task: I wanted the pattern to stop without damaging a collaborative relationship — we worked closely and I valued the partnership.

Action: I asked for a short private 1:1, framed as a process check-in rather than a performance conversation. I came prepared with two specific PRs as examples and led with impact: "I've noticed our reviews on your PRs take about twice as long as average because reviewers spend the first 10 minutes reconstructing context. I wanted to bring it to you directly before it became a broader team norm." I then asked if there was something in our process making it harder to write descriptions. That question surfaced that they didn't know what we expected — we had no written standard.

Result: The conversation was easier than I expected. We co-wrote a one-page PR checklist the following week. Within a month, average review turnaround on their PRs dropped from 36 hours to 14. Two other engineers quietly adopted the same checklist.

Learned: I learned that specific examples with concrete impact land far better than general criticism. Now I keep a short private note of behavior patterns I observe so when I do raise something, I have two or three specific instances rather than a vague impression.