Phased rollout with feature flags

WHAT THIS TESTS The interviewer wants to confirm you know the core value of flags, separating deploy from release, and can run a disciplined progressive rollout with safety gates and cleanup, not just toggle a boolean.

A GOOD ANSWER COVERS Deploy the code to production behind a flag that is off, so the binary is live but the feature is dark. Define targeting rules: enable for internal employees first to dogfood, then for an explicit beta cohort, then ramp by percentage of users toward general availability. Between each stage, watch error rates, latency, and product metrics, and only advance the gate when the signals are healthy. Keep an instant kill switch so you can disable the feature for everyone without a redeploy if something breaks. After general availability stabilizes, remove the flag and the dead branch so it does not become permanent configuration debt.

COMMON WRONG ANSWERS Using flags as long-lived branches or environment forks. Jumping straight to a large percentage without watching metrics between stages. Having no rollback path beyond a code revert and redeploy. Forgetting cleanup, leaving dozens of stale flags that tangle the codebase and confuse on-call.

LIKELY FOLLOW-UPS How do you ensure a user has a consistent experience across requests during a ramp? How do flags interact with database migrations? How do you avoid flag-combination explosion?

ONE CONCRETE EXAMPLE For a new dashboard, you deploy it dark, flip the flag on for the internal org, fix issues found in dogfooding, then enable a 200-account beta and gather feedback. You ramp to 1, 5, 25, then 100 percent of users, watching error and engagement dashboards at each step with a kill switch ready. Once it holds steady at full rollout for a week, you delete the flag and remove the old code path.