Summary
Feature flags decouple code deployment from feature release by allowing behavior to be enabled, disabled, or targeted at runtime.
Interview Points
- Flags support gradual rollout, experiments, kill switches, and tenant-specific behavior.
- Flags reduce release risk but add branching complexity.
- Clean up stale flags.
- Evaluate flags consistently and observably.
- Guard both frontend and backend behavior when needed.
2-3 Minute Interview Script
“Feature flags let teams deploy code separately from releasing a feature. That is powerful because we can merge and deploy safely, then enable the feature for internal users, a small cohort, or one tenant.
They are also useful as kill switches. If a dependency or feature misbehaves, we can turn it off without a rollback.
The tradeoff is complexity. Every flag creates another branch in the system. Stale flags make code harder to reason about and can hide bugs. So flags need ownership, naming, observability, and cleanup dates.
In an interview, I would say feature flags are a release safety tool, but they must be managed like production configuration.”
Follow-Ups
- Where should flags be evaluated?
- How do you test flag combinations?