Behavioral Scenario #02
The iOS Engineer Who Knew Best
“Your iOS counterpart is pushing an API schema that works perfectly for iOS — but breaks Android conventions. Deadline in 3 weeks.”
The Situation
You're a Senior Android engineer building a new push notifications feature. Your iOS counterpart has proposed a unified payload schema optimized for iOS's UNUserNotificationCenter. On Android, this forces awkward mapping against Firebase Messaging conventions and causes silent failures on specific Xiaomi and Huawei OEM devices that represent 18% of your user base.
Context
- The backend team prefers one unified schema to avoid maintaining two payload formats
- The iOS engineer is Staff level and has shipped several cross-platform systems previously
- OEM-specific failures surface on Xiaomi and Huawei ROMs — e.g., notification action keys that custom Android ROMs don't honor, or background process killing that breaks silent push delivery — harder to catch in standard CI testing.
- A full backend schema redesign would add 2 weeks to the timeline
- The deadline is fixed — a new feature must ship in 3 weeks for a marketing campaign
The Question
“Tell me about a time you had a technical disagreement with a peer. How did you resolve it?”
Response Options
One of these is the strongest response. The others reflect common approaches with real trade-offs.
I raised my concerns loudly in Slack, made it clear in the design doc that the iOS-centric approach was the wrong call, and asked the EM to make the final decision.
I implemented the iOS-favored schema to maintain team cohesion and filed a follow-up ticket to address the Android edge cases after launch.
I wrote a short technical memo quantifying the OEM failure rate (18% of users), proposed a minimal extension to the schema that satisfied both platforms, and scheduled a 30-minute sync with the iOS engineer and backend team to align before the decision was finalized.
I deferred to the iOS engineer since they had more seniority and cross-platform experience than me.
The Debrief
Why the Best Response Works
Answer C works because it converts a subjective disagreement into an objective problem. Once the OEM failure rate is quantified, the argument is no longer 'my platform preference vs. yours' — it's 'user impact we can avoid.' The schema extension proposal removes the zero-sum nature of the decision, and the sync ensures no one is blindsided.
What to Avoid
The most common mistake is either going too loud (Slack escalation) or too quiet (file a ticket and ship the broken thing). Both are forms of avoiding the hard conversation. The right move is making the hard conversation easy by coming with data and a solution.
What the Interviewer Is Probing
The interviewer is evaluating whether you can influence peers across seniority levels without using authority. This is a core Staff-readiness signal — can you resolve a technical conflict that your manager doesn't even know exists?
SOAR Structure
**Situation:** New notifications feature, iOS-proposed schema causes silent failures on 18% of Android devices. **Obstacle:** iOS engineer was more senior; backend wanted one schema; deadline was fixed. **Action:** Quantified OEM failure rate, proposed minimal schema extension, convened alignment sync. **Result:** Schema updated with Android compatibility layer; shipped on time with full device coverage.
The Learning Arc
"This taught me that most technical disagreements are actually information asymmetry problems. The iOS engineer wasn't wrong for their platform — I just had data they didn't have. Since then, I write a one-page impact brief before any cross-platform technical sync. It removes the ego from the room and makes the decision easier for everyone."
IC Level Calibration
Quantify the impact, propose a solution, and drive a three-way alignment sync before the decision is final. Own the Android platform perspective.
Same as senior, plus: identify this as a systemic gap in how cross-platform decisions get made at the company. Propose a lightweight cross-platform design review process to prevent the same conflict in future features.
Recognize this as an organizational pattern — iOS-centric decisions made without Android review. Establish a cross-platform API design guild or checklist. Ensure the fix becomes a standard that prevents this class of decision across all teams.
Company Calibration
Googleyness: Intellectual humility + collaborative problem-solving
Nvidia
Intellectual honesty + one team
NYTimes
Cross-functional collaboration + pragmatic problem-solving
Airbnb
Belonging: including all users + mission-driven decision-making
Want to pick your response and see the full analysis?
Practice This Scenario Interactively