Behavioral Scenario #18
The Design Review Veto
“You've reviewed a PR with 6 weeks of work in it. It works. But the pattern it introduces will be a scaling problem in 6 months. The engineer disagrees. What do you do?”
The Situation
You're a Senior Android engineer reviewing a PR from a Staff engineer on another team. The PR introduces a new real-time data sync pattern using a singleton shared StateFlow with no scoping or lifecycle binding. It works for the current use case — one screen, one consumer. But you know from experience that this pattern scales badly: once other screens consume it, you'll have cross-screen state mutations that are nearly impossible to debug. The Staff engineer believes your concern is theoretical and unlikely given the product roadmap.
Context
- The PR represents 6 weeks of work by the Staff engineer and their team
- Your concern is about future scaling — the current implementation is bug-free and passes all existing tests
- The Staff engineer has more seniority than you and has shipped this pattern successfully at a previous company
- Blocking the PR unilaterally would require manager escalation on both sides
- The product roadmap does show 2 additional screens planned to use this sync layer in Q4
The Question
“Tell me about a time you identified a technical risk in another engineer's work that they didn't agree was a risk. How did you handle it?”
Response Options
One of these is the strongest response. The others reflect common approaches with real trade-offs.
I left detailed comments explaining the scaling risk with code examples, but approved the PR with a note that I disagreed with the pattern.
I requested a 30-minute sync with the Staff engineer, came with a concrete alternative (a scoped StateFlow bound to a ViewModel lifecycle per screen), demonstrated the Q4 scaling problem with a specific example from the roadmap, and offered to pair on migrating the current implementation to the safer pattern if they agreed it was worth it. If they still disagreed after the sync, I documented my concern in the PR and suggested we bring in a third engineer for a tiebreak.
I escalated to both of our managers and asked them to resolve the technical disagreement since we couldn't align ourselves.
I deferred to the Staff engineer's judgment given their seniority and previous experience with the pattern.
The Debrief
Why the Best Response Works
Answer B works because it creates the conditions for a real technical conversation rather than a political one. The concrete alternative removes the zero-sum framing — you're not saying 'no,' you're saying 'yes, differently.' The Q4 roadmap example transforms the theoretical risk into a specific, credible scenario. The pairing offer removes the switching cost objection. And the tiebreak path gives you a professional escalation option that doesn't involve managers — which matters when the disagreement is purely technical.
What to Avoid
Approve-with-concerns is the most common response, and the most common way to let a known risk ship while protecting yourself from blame. The comment disappears into PR history. The pattern becomes the team standard. The Q4 engineers build on it without knowing about the concern. Your job as a reviewer is not to protect yourself — it's to protect the system.
What the Interviewer Is Probing
The interviewer is evaluating your technical advocacy: can you raise a real concern with a more senior engineer without being politically aggressive? Can you make the abstract risk concrete? Can you offer a solution rather than just a block? These are the skills that make technical disagreements productive rather than territorial.
SOAR Structure
**Situation:** 6-week PR with singleton StateFlow pattern that scales badly; Staff engineer disagrees the risk is real; Q4 roadmap shows 2 additional consumers. **Obstacle:** Seniority gap; large PR; working implementation; Q4 risk not yet visible. **Action:** Requested sync; presented scoped ViewModel alternative with Q4 roadmap example; offered to pair on migration; after continued disagreement, proposed third-engineer tiebreak; third engineer agreed the scoping risk was real. **Result:** Pattern migrated to scoped approach before merge; Q4 screens built without debugging the cross-screen mutation bug.
The Learning Arc
"This taught me that the strength of a technical concern is not in how loud you raise it — it's in how specific you make it. 'This will scale badly' got ignored. 'In Q4 when the profile screen and the messages screen both consume this StateFlow, here's exactly what will happen' created a real conversation. Specificity is the currency of technical credibility."
IC Level Calibration
Request a sync, bring a concrete alternative and a specific Q4 roadmap example, offer to pair, and define a professional tiebreak if alignment fails. Document the concern regardless of outcome.
Same as senior, plus: if the pattern ships, write the architectural decision record (ADR) documenting the tradeoff. Make the Q4 engineers aware before they build on it. Propose a refactor as part of the Q4 scope.
Same as staff, plus: recognize this as a pattern-setting moment. If this pattern ships unquestioned, other teams will adopt it. Drive a cross-team architectural review for new sync patterns. Make 'lifecycle-scoped vs. singleton state' an explicit architectural standard in the engineering docs.
Company Calibration
Googleyness: intellectual humility + willingness to disagree productively
Nvidia
Intellectual honesty: raise concerns with evidence, not just opinion
Amazon
LP: Have Backbone; Disagree and Commit — advocate, then accept the outcome
Airbnb
Belonging: every engineer's concern deserves a real hearing
Want to pick your response and see the full analysis?
Practice This Scenario Interactively