Your production flag service holds around 300 flags and nobody can say which are still needed. As the engineer setting policy, how would you run flag hygiene as an ongoing operational review, and which flags would you deliberately never expire?

## Why 300 unknown flags is a reliability problem A stale flag is not merely clutter. It is a live conditional in production code whose disabled branch has had no traffic and no tests for an unknown length of time, and whose value can be changed by anyone with access to the flag console. Three concrete risks follow: - **Accidental exercise.** Somebody bulk-edits, restores a backup of flag state, or a default changes during a platform migration, and a branch nobody has run in two years is suddenly serving users. - **False confidence.** Responders see a flag whose name suggests it disables a risky path and reach for it during an incident. It does nothing, or something unexpected, and the outage lengthens. - **Change amplification.** Every flag multiplies the states the code can be in, so refactoring, reasoning and reproducing bugs all get harder, in proportion to a number nobody is managing. The practice question is how to keep that number honest without turning it into an annual cleanup crusade that never happens twice. ## Make it a number, then review the number The policy that works is the one that produces a metric a team already looks at. Concretely: **Metadata is mandatory at creation.** Refuse to create a flag without an owning team, a type, and an expiry date. Type is what decides everything downstream, so it has to be chosen deliberately rather than inferred later. **The tracked metric is flags past expiry.** Not total flags — total is a business fact, and a healthy team mid-rollout has plenty. Overdue flags is the number that means something has been forgotten, and it should be reviewed on a fixed cadence in a forum the team already attends, next to pager load and open action items. Reviewing it there rather than in a dedicated meeting is what makes it survive past the first quarter. **Automate the candidate list.** Two signals find most of the dead weight without human effort: flags pinned at 0 or 100 percent for a long window (90 days is a reasonable default) and flags whose evaluation count is zero. The second is the strongest evidence available — a flag nobody evaluates has outlived its call site, and its record is pure noise. **Removal means deleting the branch.** Deleting the flag record while leaving `if (true)` in the code, or leaving a hard-coded constant, converts one problem into a subtler one. The removal change deletes the conditional, the losing branch and its tests, and it is a normal reviewed code change that ships through the pipeline. ## What you never expire The policy has to have an explicit exempt class or people will quietly ignore it. Flags that legitimately live for the service's lifetime: - **Kill switches and circuit-style levers** for expensive or fragile dependencies. - **Degradation and load-shedding toggles** that turn off non-essential work under pressure. - **Permission, entitlement and licensing gates**, which are product logic expressed as configuration and are never going to be "finished". - **Regional or tenant-scoped operational controls** used during failover or maintenance. These are exempt from expiry, not from discipline. Being permanent, they attract the opposite obligation: both states stay covered by tests, and the switch is drilled on a cadence so its wiring and its fallback stay verified. That is a real recurring cost per lever, which is why the useful constraint is a **budget** rather than a blanket permission: keep the permanent set small enough that the team can genuinely keep every one of them tested and drilled. A team that can drill six levers a year should not be carrying forty and calling them controls. ## Making the default direction removal Several cheap mechanisms bias the system toward cleanup instead of accumulation: - **Ownership follows the on-call rotation**, so an unowned flag has a home rather than becoming everyone's problem. - **Expiry is visible where engineers already are** — a comment or annotation at the call site, or a build warning past the date — rather than only in a console nobody opens. - **Removal is somebody's named work item**, because unowned cleanup does not happen. This mirrors the postmortem lesson: an action item without a name is a wish. - **A cap on new flags per team**, if things are truly out of hand, forces a removal before a creation. Blunt, but it works when the number is 300 and rising. What does not work: a one-off cleanup with no ongoing metric, a bot that auto-deletes flags without a human deciding which branch wins, or a policy with no exempt class, which pushes teams to lie about flag types. ## The judgment an interviewer is testing This is a policy question with a real tradeoff, so a strong answer commits to positions and pays for them. It distinguishes temporary flags from permanent levers instead of treating all flags alike. It puts a number on the thing it wants managed, and puts that number where it will be seen. It accepts the recurring drill cost for the permanent set and bounds that set accordingly. And it is honest that removal is engineering work with a real price — you are spending time to reduce the number of states production can be in, which is a reliability investment, not tidiness.