Section 1: A Deploy You Never Ship - Problem Understanding & Clarifications

Executive Summary: This section covers the first ten minutes of a Staff/Principal interview on a feature flag and progressive delivery platform. We break the prompt into what, who, why and how, then work through the clarifying questions whose answers change the design: what a flag is, who flips it, where it is evaluated, which audiences it targets, and how instant "instantly kill" has to be. The answers become written assumptions, and the running example arrives: Fabrikam Mail rolling out smart-reply-v2 to a user named Dana.

The interviewer reads you one sentence:

"Design a system that lets product teams gradually roll out features to a percentage of users, target specific audiences — by region, tenant or user ring — and instantly kill a feature if it causes problems, all without deploying new code."

The phrase that matters most is the last: without deploying new code. A feature flag is a deploy you never ship. The new code is already running on every server, sitting behind an if. The platform decides who reaches the inside of that if, and changes that answer in seconds. Percentages, audiences and the kill are all ways of saying who gets in.

Many candidates picture a table of booleans with a toggle page and start drawing. That works for one service and falls over at a few thousand. The admin page is the easy part. The hard part is evaluating flags on every request, everywhere, and pushing one change to a whole fleet.

Key Insight: A flag platform has two halves. The control plane, where humans edit rules, is small and slow. The data plane, where every request asks "is this on for this user?", is huge and fast. Most of the interview is about keeping the second from ever depending on the first.

Decomposing the Prompt

Before asking anything, map the problem in four parts:

• What it does: Store flag definitions with rules, evaluate them against a request's context, roll changes out step by step, and stop a feature on demand. In verbs: define, evaluate, roll out, kill.
• Who uses it: Product teams create flags and run rollouts on their own. SREs and on-call engineers press the kill switch. The heaviest user is the code itself, in services, browsers and phones, asking millions of times a second.
• Why it exists: To separate deploy (shipping code) from release (turning it on for people). That buys safety (small blast radius, instant rollback) and speed (ship dark, turn on later).
• How it's used: A UI or API for changes that happen a few times a minute, and an SDK call in the hot path that happens on almost every request.

Quick check before moving on: