A product manager asks why the app feels slower on Android than on iOS when it is the same web application. Walk me through what you investigate and what you tell them.

What the interviewer is testing

Whether you reach for field data segmented by device class, or start guessing about browser engines. The question is almost always about the device population, not about the platform, and someone who knows that gets to a useful answer in one step.

The trap is answering "Safari and Chrome have different engines". Engine differences exist and are almost never the explanation for a complaint this large.

The clarifying questions that change the answer

• Which markets? The Android device distribution differs enormously by region, and an app that is fine in one market can be unusable in another on the same code.
• Slower at load, or slower during interaction? They have different causes and different fixes: load is transfer plus parse, interaction is main-thread work and memory pressure.
• Is it measured or reported? A perception from three colleagues with the same phone is not a population.

The arc of a strong answer

1. Segment the field data by device class, not by operating system. Group by main-thread benchmark or by a device model tier, and compare p75 within each. The iOS population is narrow and skews recent; the Android population spans seven years of hardware, so an OS-level comparison is comparing two different distributions rather than two platforms.
2. Expect the gap to mostly disappear within a class. A current flagship Android and a current iPhone are close, because the aggregate difference is composition: main-thread speed varies by roughly 5x to 10x across a realistic Android population and by far less across an iOS one.
3. Name the mechanisms that remain. Lower-end devices have slower single-core performance, so JavaScript parse and execute take longer - on the order of 1 MB per second of uncompressed script rather than several; less memory, so background tabs are evicted and returning to the app is a cold start that fails to restore state; and thermal throttling under sustained work, which makes the second minute slower than the first.
4. Give the product answer, not the engineering one. "The experience is fine on the devices we test on and poor on the devices a third of our users have" is a statement a product manager can act on. A budget derived from the slow tier, and a physical device of that tier on someone's desk, follow from it - and so does the trade-off to name explicitly: choose the slow tier as the reference and you will ship fewer client-side features, which is the cost being paid for the third of users who currently bounce.

Common weak answers

• "It is a browser engine difference." Rarely the cause at this magnitude, and it leads to unfixable conclusions.
• "We should build native apps." Does not follow from the evidence, and a native app on the same device is still on the same device.
• "Our Lighthouse score is 95." A lab number on one simulated device, which is precisely the measurement that hides a population effect.

What a strong answer adds

That the measurement itself may be understating the problem: if the monitoring beacon fires late, the slowest sessions are abandoned before they report, so the device tier with the worst experience is the one least represented in the data. Checking sample counts per tier, not just percentiles, is what makes the analysis trustworthy.