KMP or React Native

“Engineering says KMP. Product says React Native. The decision is yours to make in one week.”

The Situation

Your startup wants to share both business logic AND UI components between Android and iOS. The iOS team's contractor advocates for React Native for the full stack. The Android lead prefers Kotlin Multiplatform for logic sharing with native UIs on each platform. You're the senior Android engineer asked to deliver a formal recommendation in one week.

Context

The shared logic is pure business logic — no shared UI involved
Your Android team has no KMM experience but strong Kotlin skills; iOS contractor is a React Native specialist
The company has 3 Android engineers and 1 iOS contractor — team fit matters for long-term maintenance
The feature involves a real-time sync engine that will be performance-sensitive on mid-range devices
The recommendation will inform a multi-year platform decision, not just this one feature

The Question

“Tell me about a time you had to evaluate competing technical approaches under time pressure and make a recommendation with incomplete information.”

Response Options

One of these is the strongest response. The others reflect common approaches with real trade-offs.

I recommended KMM because it's the technically correct choice for sharing pure Kotlin business logic without introducing a JS bridge overhead.

I recommended React Native to avoid conflict with the iOS contractor and keep the team aligned.

I ran a structured evaluation: built 2-day proofs of concept for both approaches against the specific sync logic requirements, documented trade-offs across 5 dimensions — team fit, runtime performance, long-term maintenance, hiring reach, tooling maturity — and presented a recommendation with explicit assumptions. I recommended KMM for the pure logic layer, but noted that a full React Native migration would require a different analysis.

I deferred to the platform team's preference since they'd be maintaining it long-term.

The Debrief

Why the Best Response Works

Answer C works because it demonstrates the evaluation process, not just the conclusion. Anyone can have a preference — Senior engineers can show you how they got there. The 5-dimension framework, the PoC validation, and the scope caveat all signal structured thinking. The explicit assumptions documentation means the recommendation is defensible when circumstances change.

What to Avoid

Stating a preference without showing the evaluation process. At Senior level, 'KMM is the right choice because of the JS bridge overhead' sounds like an opinion, not an analysis. The interviewer wants to see how you think, not just what you concluded.

What the Interviewer Is Probing

The interviewer is evaluating structured decision-making under time pressure and incomplete information. Can you build a framework, validate it empirically, and communicate your confidence levels honestly? Can you scope a recommendation appropriately — knowing when the question you've been asked is narrower than the decision you're being asked to make?

SOAR Structure

**Situation:** KMP vs. React Native for shared business logic. One week to recommend. Team divided. **Obstacle:** No KMM team experience; iOS contractor advocating RN; multi-year platform implications. **Action:** 2-day PoC for each approach; 5-dimension trade-off matrix; explicit assumption documentation; scoped recommendation (logic layer only). **Result:** KMM adopted for business logic; contractor built iOS wrapper; team shipped sync engine on time; no JS bridge performance issues.

The Learning Arc

"This taught me that the value of a technical recommendation isn't the conclusion — it's making the decision-making process transparent enough that anyone can disagree productively. When I documented my 5 dimensions and stated my assumptions explicitly, the iOS contractor could engage with the framework rather than argue about the conclusion. That changed the entire dynamic of the conversation."

IC Level Calibration

senior · Primary Target

Build PoCs for both approaches against the specific requirements, document trade-offs across key dimensions, make an explicit recommendation with stated assumptions, and flag where your analysis has gaps.

staff

Same as senior, plus: scope the recommendation clearly (this feature vs. full platform migration are different decisions). Identify what would change your recommendation. Make the decision reversible where possible.

principal

Treat this as a foundational platform decision. Engage the iOS contractor directly to understand their concerns. Build a lightweight ADR (Architecture Decision Record) that future teams can reference. Ensure the decision includes a clear criteria for revisiting it (e.g., 'if React Native adoption exceeds X% at the company, we revisit').

Company Calibration

Nvidia

Intellectual honesty + bias for evidence over opinion

Google

Googleyness: Logical thinking + ambiguity comfort

Amazon

LP: Are Right, A Lot — seek diverse perspectives, use data

BlackRock

Risk assessment + decision quality under uncertainty

Want to pick your response and see the full analysis?

Practice This Scenario Interactively