Describe staged rollout on Google Play Console, benefits, and metrics to monitor

WHAT THIS TESTS: Whether you understand production release hygiene on a platform with billions of devices. Interviewers want to see that you treat deployment as a risk-management exercise rather than a binary publish event, and that you know the specific mechanics of Google Play staged rollouts.

A GOOD ANSWER COVERS: Four things in order. First, setup mechanics: you choose a percentage of users and optionally restrict countries, then start the rollout; Play randomly selects that cohort for the new APK or App Bundle. Second, progression: you manually increase the percentage over time through the Play Console; it does not auto-ramp. Third, halting: if crash rates, ANR rates, or user feedback degrade, you halt the rollout immediately, which stops new users from receiving the build but leaves already-upgraded users on that version. Fourth, metrics: monitor crash-free session rate, ANR rate, native crash volume, app-not-responding clusters by Android version and device model, user rating trends, and business telemetry like login success or purchase conversion. Benefits to highlight are blast-radius containment, real-world validation across diverse hardware and networks, and the ability to catch issues that internal testing missed.

COMMON WRONG ANSWERS: Claiming that staged rollouts work for first-time app launches when they only apply to updates. Asserting that the percentage increases automatically. Believing that halting a rollout reverts users to the previous version; in reality, halted users stay on the broken build and you must ship a new release to fix them. Monitoring only vanity metrics like daily active users instead of stability signals. Ignoring country-specific targeting as a way to control exposure by timezone or market risk.

LIKELY FOLLOW-UPS: How would you handle a bad rollout where users cannot upgrade because the app crashes on launch? Would you use country targeting to stage by timezone, and what are the tradeoffs? How do staged rollouts interact with emergency releases and track promotions? What is your rollback strategy if the new version uses a new database schema or server API?

ONE CONCRETE EXAMPLE: Say you are releasing a video playback rewrite. You begin at 5 percent in production, targeting countries where your support team is awake. After two hours you check Firebase Crashlytics and see a 3x spike in native crashes on Mali GPUs. You halt the rollout at 5 percent, preventing 95 percent of your user base from receiving the bad build. The 5 percent already updated remain affected, so you immediately prepare a hotfix release and start a new staged rollout for that fix rather than attempting a rollback through the Console.