How do you give and receive feedback?
Company: Netflix
Role: Software Engineer
Category: Behavioral & Leadership
Difficulty: hard
Interview Round: Onsite
Behavioral questions about feedback:
1) Tell me about a time you had to give constructive feedback to a teammate or cross-functional partner (e.g., PM, DS, designer) when something wasn’t going well.
- What was the situation?
- How did you deliver the feedback?
- What was the outcome?
2) Tell me about a time you received critical feedback.
- How did you respond?
- What did you change afterward?
Assume the interviewer will probe for specificity, ownership, and impact.
Quick Answer: This question evaluates a software engineer's interpersonal competencies, specifically the ability to give and receive constructive feedback, demonstrate emotional intelligence, take ownership, and collaborate across cross-functional teams.
Solution
### What a strong answer looks like
Interviewers usually score feedback stories on: **clarity**, **empathy**, **directness**, **ownership**, **follow-through**, and **measurable outcome**.
### 1) Framework for giving feedback (use a concrete structure)
Use **SBI** (Situation–Behavior–Impact) + **request**:
- **Situation:** when/where it happened (specific meeting, sprint, incident).
- **Behavior:** observable actions (avoid judging intent).
- **Impact:** effect on users, team, timeline, quality.
- **Request / next step:** what you want to change, and how you’ll help.
Example phrasing:
- “In yesterday’s oncall handoff (S), you merged the fix without running the regression suite (B). It caused a second outage and woke up APAC oncall (I). Next time, can we agree to run the 10-minute smoke tests or ask for a second reviewer even if we’re rushing? I can help automate the checks (Request + support).”
Key choices to mention:
- Prefer 1:1 for sensitive feedback; public only for process/system issues.
- Ask questions first (“What constraints were you under?”) to avoid misattribution.
- Align on a **shared goal** (shipping safely, meeting SLA, etc.).
- End with an explicit agreement and a time to revisit.
### 2) Handling disagreement or defensiveness
Show you can de-escalate:
- Acknowledge feelings: “I see this is frustrating.”
- Re-anchor to facts and impact.
- Offer options: pair-programming, written follow-up, involving a neutral third party.
- If it’s a repeated pattern, explain escalation thoughtfully (manager involvement) with documented examples.
### 3) Framework for receiving feedback
Use **listen → clarify → reflect → act → close the loop**:
- Don’t rebut immediately; ask for examples.
- Confirm understanding: “What would good look like next time?”
- Pick 1–2 concrete behaviors to change.
- Follow up later with evidence of change.
Example elements to include:
- You thanked them and asked for specific instances.
- You created an action plan (e.g., design doc reviews earlier, weekly stakeholder updates, adding tests).
- You measured improvement (fewer escalations, faster cycle time, improved stakeholder NPS, etc.).
### 4) Mistakes to avoid
- Vague story (“communication issues”) without a clear behavior.
- Blaming the other person; no ownership.
- No outcome or learning.
- Feedback delivered as a surprise (no prior expectations set).
### 5) How to present your story (STAR)
- **S/T:** 2–3 sentences, include stakes.
- **A:** emphasize your wording, channel (1:1), and collaboration.
- **R:** outcome + what you’d do differently next time.
If you share one strong “gave feedback” story and one strong “received feedback” story with measurable outcomes, you cover most feedback-focused behavioral rounds.