Behavioral Scenario #10
The Junior Engineer Who Was Right
“You dismissed a junior's concern during review. Six weeks later, it caused a production incident. The team knows.”
The Situation
You're a Senior Android engineer. Six weeks ago, a junior engineer raised a concern during your code review — they questioned whether a particular cache invalidation approach could cause stale data in low-memory conditions. You dismissed it confidently, citing your experience with similar patterns. The PR merged. This week, that exact scenario caused a production bug affecting premium users. The incident is fully documented in the postmortem.
Context
- The junior engineer's concern was technically precise — their hypothesis in the code review matched the root cause in the postmortem exactly
- The bug affected premium users specifically during memory pressure (OOM scenarios on low-end devices) — a narrow but high-value segment
- Your confidence in dismissing the concern was visible in the review comments — you used language like 'this won't be an issue in practice'
- Two other engineers saw your dismissal in the review and stayed quiet, even though one later said they had a similar concern
- The junior engineer has not raised any concerns in code review since the incident
The Question
“Tell me about a time you were wrong. How did you handle it?”
Response Options
One of these is the strongest response. The others reflect common approaches with real trade-offs.
I acknowledged the bug in the postmortem, fixed the code, and moved on — mistakes happen in software engineering and the team understands that.
I privately apologized to the junior engineer and thanked them for catching what I missed, then addressed the pattern in my own code reviews going forward.
I opened the next team sync by naming what happened directly: I dismissed a technically correct concern with false confidence, and it caused a production incident. I thanked the junior engineer publicly, and proposed a team norm: any engineer who raises a concern in review gets explicit engagement — no dismissals, only discussion. I also asked the junior engineer to walk us through their original reasoning as a learning for the team.
I updated our code review checklist to add a section on cache invalidation edge cases, so future reviews would catch similar issues.
The Debrief
Why the Best Response Works
Answer C works because it repairs trust at the right scope. The dismissal was public, so the acknowledgment must be public. But more importantly, it converts a failure into a demonstration of exactly the behavior the team needs to see: that being right matters more than being senior, and that junior engineers' technical judgment is valued regardless of experience level. The teaching inversion (asking the junior to walk through their reasoning) is the most powerful part — it reverses the original power dynamic visibly.
What to Avoid
The checklist fix is the most common response — it solves the wrong problem. The real problem isn't that the review process missed a cache invalidation edge case. The real problem is that a junior engineer raised the right concern and was dismissed with false confidence, and now they're not raising concerns anymore. That silence will cost you more than any single bug.
What the Interviewer Is Probing
The interviewer is measuring intellectual humility and psychological safety leadership. Can you be publicly wrong without ego defense? Can you recognize when your mistake has damaged someone else's confidence? Senior engineers create the environment where junior engineers feel safe being right — especially when it means the senior engineer was wrong.
SOAR Structure
**Situation:** Dismissed a junior engineer's technically correct concern in code review; six weeks later, exact failure mode caused a premium user production incident. **Obstacle:** Public confidence of the dismissal; junior engineer had stopped raising concerns; other engineers had gone quiet too. **Action:** Named it publicly in next team sync; thanked junior engineer by name; proposed review engagement norm; invited junior to walk through their original reasoning as a team teaching moment. **Result:** Junior engineer raised 3 concerns in the following sprint; other engineers began commenting more actively in reviews; team discussed psychological safety in next retrospective.
The Learning Arc
"This taught me that experience creates a tax on junior engineers. Every time I dismiss a concern with confidence, I'm implicitly telling them that their judgment matters less than my experience. After this incident, I changed my code review language completely — I don't say 'this won't be an issue.' I say 'walk me through why you think this could be a problem.' The question costs me nothing. The dismissal cost a production incident and a junior engineer's voice."
IC Level Calibration
Public acknowledgment that matches the publicity of the original dismissal. Thank the junior engineer specifically and by name. Propose a concrete team norm to prevent recurrence. Invite the junior engineer to teach.
Same as senior, plus: recognize that one person going quiet is a signal of a broader psychological safety problem. Audit recent reviews for other instances where concerns were dismissed. Make 'intellectual humility in review' an explicit team value in your engineering standards doc.
Use this incident as a company-level teaching moment (with the junior engineer's permission). The failure is not individual — it's a symptom of how seniority creates silence in code review. Propose a cross-team blameless review culture initiative. Make psychological safety in code review a measurable engineering health metric.
Company Calibration
Googleyness: Intellectual humility + psychological safety
Airbnb
Belonging: creating an environment where everyone can contribute
Amazon
LP: Learn and Be Curious + Hire and Develop the Best
Nvidia
Intellectual honesty + togetherness
Want to pick your response and see the full analysis?
Practice This Scenario Interactively