Describe how you'd lead the incident response for a critical crash affecting a large percentage of users in production

#What separates an IC from an incident commander here

This question is designed to see whether you can lead under pressure without becoming either paralyzed by wanting full root cause before acting, or reckless enough to ship a blind fix to millions of devices. The senior signal is a calm, structured response: someone declares the incident and takes command explicitly — even if that's you, saying it out loud — because ambiguous ownership is how the first twenty minutes get wasted on three engineers independently investigating the same stack trace instead of one person directing parallel work.

#The first ten minutes: declare, don't investigate yet

The moment a crash spike crosses a real severity threshold — a defined percentage of sessions or DAU, not a gut feeling — I declare an incident, assign an incident commander, and open a single channel that becomes the one source of truth, specifically to stop the Slack-thread sprawl where three people are debugging in three different DMs with three different half-pictures. In that first window I'm resisting the urge to start reading stack traces myself; my first job is command structure and stopping the bleeding, not being the smartest debugger in the room.

#Stop the bleeding before you understand it

The single biggest lever in mobile incident response is that Android and iOS give you very different speeds of mitigation, and a senior engineer needs to know both cold. On Android, if the crash correlates with a recent staged rollout, halting that rollout in the Play Console is close to instantaneous and buys real time. On iOS, you cannot pull an already-installed binary off anyone's phone — your options are removing the app from sale to stop new installs, and requesting an expedited review for a fixed build, which Apple typically turns around in a day or two but is never instant. This is exactly why I push, outside of incident time, for every meaningfully risky feature to sit behind server-side remote config or a kill switch — because a config flip is the only mitigation that's equally fast on both platforms and doesn't depend on either store's review clock.

#Diagnose without stopping the mitigation

While one track is mitigating, a second track — a different person, ideally — is finding root cause, so the two don't bottleneck each other. That means symbolicating the crash immediately (dSYMs for iOS, the R8/ProGuard mapping file for Android) so the stack trace is readable instead of a wall of hex offsets, and correlating the spike's start time against everything that changed recently: the last release, a remote-config change, a backend deploy, an A/B test ramp. In my experience the crash is caused by the backend more often than people expect — an API starts returning a null or a new field shape, and an older app version that never guarded against it crashes on the parse, which is why "what changed on the server in the last few hours" belongs on the checklist as early as "what did we ship."

#Communication is part of the job, not an afterthought

A crash affecting a large slice of users is a trust event as much as an engineering one, and a senior engineer manages the narrative alongside the fix: a factual, non-speculative update to internal stakeholders and support on a fixed cadence — even "no new information, still investigating, next update in twenty minutes" — so nobody is guessing, plus a clear plan for what support tells affected users. Going quiet during an incident is what turns a bad hour into a bad week, because leadership and support start filling the silence with their own guesses.

#Deciding rollback vs. hotfix vs. ride-it-out

Once mitigated, the decision of what happens next is a real tradeoff, not automatic: a full rollback is safest but throws away every other change in that release; a targeted hotfix is faster to write than to safely test and ship through both stores; and if the kill switch already stopped the bleeding, sometimes the right call is to ship the real fix on the normal next release rather than rushing a second emergency change into an already-tense system. I make this call explicitly, out loud, with the reasoning stated, rather than defaulting to whichever option feels most active.

#The postmortem is where the real leadership shows

Once the fire is out, I run a blameless postmortem focused on the system, not the person who wrote the line that crashed — because that same mistake was reviewable, testable, and shippable by the whole process, not just one engineer. The output I actually care about is concrete guardrails: a lower default staged-rollout percentage, an alert that fires on crash-rate slope instead of only absolute thresholds, a canary gate a release can't skip, and, if the diagnosis showed we were slow to detect, an honest look at why our own alerting lagged behind user reports on social media or the app store reviews.