Behavioral Scenario #22
The Junior's AI Incident
“A junior engineer's AI-generated code passed review, shipped, and caused a payment processing failure affecting 12,000 users.”
The Situation
A junior Android engineer on your team used Claude to generate the retry logic for a payment flow. The code looked correct, passed unit tests, and two senior engineers approved the PR. In production, the retry logic didn't respect idempotency — duplicate charges occurred for 12,000 users over 4 hours before it was caught. The junior engineer is devastated. Leadership is asking what happened.
Context
- The junior engineer disclosed AI use in the PR description — the tool choice was transparent
- Two senior engineers reviewed and approved the PR without catching the idempotency gap
- Unit tests used mocked network calls and didn't exercise the actual idempotency behavior
- 12,000 users received duplicate charges over 4 hours before the issue was caught and rolled back
- The junior engineer has expressed that they want to quit and feels responsible for harming users
- Leadership wants a postmortem delivered within 48 hours
The Question
“Tell me about a time a team member's mistake had significant customer impact and how you handled it.”
Response Options
One of these is the strongest response. The others reflect common approaches with real trade-offs.
I used it as a one-on-one teaching moment with the junior engineer, walking through what went wrong with the retry logic and what they should have checked before accepting the AI suggestion.
I ran a blameless postmortem that focused on the system failures: mocked tests didn't exercise real idempotency behavior, AI-generated code in payment flows wasn't flagged for heightened review scrutiny, and two senior engineers reviewed without a payment-specific checklist. I updated the review process to require real integration tests for payment retry logic and added AI-generated payment code to the trust matrix as a mandatory second-review category. I also publicly defended the junior engineer — the AI use was disclosed, the PR was approved by two seniors, and the system failed, not the person.
I implemented a new rule requiring AI-generated code to have 3 reviewers instead of 2 to increase scrutiny.
I restricted junior engineers from using AI tools for payment-related code until they demonstrate sufficient seniority to evaluate AI suggestions critically.
The Debrief
Why the Best Response Works
Answer B works because it finds the real causes: mocked tests that didn't exercise production behavior, and no heightened scrutiny category for AI-generated payment code. The junior engineer used AI correctly and disclosed it — the system around them failed. Fixing the system (test coverage + review category) prevents recurrence. Protecting the junior publicly preserves the psychological safety that makes transparent AI use — including disclosure in PRs — sustainable.
What to Avoid
Individual blame is the most common failure mode in incident response. The junior disclosed AI use, the PR was approved by two senior engineers, and mocked tests passed. Restricting the junior or coaching only the junior leaves every other contributing cause in place. The next incident will involve different people and the same system gaps.
What the Interviewer Is Probing
The interviewer is evaluating whether you can separate cause from blame under pressure — and whether you protect psychological safety when it's inconvenient. Blameless postmortems are easy to claim and hard to execute when leadership is asking who did it. The public defense of the junior engineer is the signal that tells the interviewer this is genuine, not performative.
SOAR Structure
**Situation:** Junior engineer's AI-generated retry logic caused 12,000 duplicate charges over 4 hours; engineer devastated; leadership demanding answers within 48 hours. **Obstacle:** Pressure to assign blame; mocked tests had passed; two senior reviewers had approved; AI use had been disclosed. **Action:** Ran blameless postmortem; identified mocked test gap and missing AI+payment review category as root causes; updated trust matrix; required real integration tests for payment retry logic; publicly stated that the system failed, not the engineer. **Result:** No further payment idempotency incidents in 18 months; junior engineer stayed and became the team's internal expert on AI-assisted payment code review.
The Learning Arc
"The hardest part wasn't finding what went wrong — it was standing in front of leadership and saying the junior engineer wasn't at fault when everyone wanted a person to point at. But that was the only honest answer, and the only one that would actually prevent it from happening again."
IC Level Calibration
Run the postmortem, identify the mocked test gap, fix the test coverage for payment retry logic, and brief the junior engineer on what happened and why it wasn't their fault alone.
Find the systemic gaps — mocked tests, missing AI+payment review category — and fix the system rather than the person. Protect the junior engineer's psychological safety publicly. Update the trust matrix so the category is formalized, not left to individual judgment.
Establish AI-generated code in high-stakes domains (payments, auth, data integrity) as a recognized risk category across the engineering organization — not just on this team. Make the review standards and test requirements explicit enough to be applied consistently without your involvement.
Company Calibration
Amazon
LP: Dive Deep + Earn Trust — COE process finds causes, not culprits
Stripe
API-first + idempotency as a first-class design concern
Error budgets + blameless postmortem culture
Shopify
BFCM resiliency: payment flows get extra scrutiny before high-stakes periods
Want to pick your response and see the full analysis?
Practice This Scenario Interactively