How Do Feature Flags Work in Frontend Development?
Learn how feature flags decouple deployment from release, enable gradual rollout, and require disciplined cleanup.
Expected Interview Answer
Feature flags are runtime configuration switches that let a frontend team ship code to production behind a conditional check, so a feature can be turned on or off — or targeted to specific users — without deploying new code, decoupling deployment from release.
Instead of holding a feature back on a long-lived branch until it’s fully ready, teams merge the code continuously behind a flag check like if (flags.newCheckout) that defaults to off in production. A flag service (LaunchDarkly, a custom backend endpoint, or even a config JSON) evaluates rules — percentage rollout, user segment, environment — and returns which flags are enabled for the current user, letting teams do gradual rollouts, A/B tests, or instant kill-switches if a feature misbehaves, all without a redeploy. This requires disciplined flag hygiene: flags left in the codebase after a feature is fully rolled out accumulate as dead conditional branches that make code harder to reason about and test, so removing stale flags is as much a part of the workflow as adding them. On the frontend specifically, flags also need care around initial render — evaluating a flag asynchronously after the first paint can cause layout shift or a flash of the wrong variant, so critical flags are often resolved server-side or from a fast local cache before the first render.
- Decouples deployment from release — merge continuously, release when ready
- Enables gradual percentage rollouts and instant kill-switches without redeploying
- Supports A/B testing and user-segment targeting from the same mechanism
- Reduces risk of big-bang releases by letting teams test in production safely
AI Mentor Explanation
Feature flags are like a stadium having a new floodlight system wired in and ready weeks before it’s switched on for an actual match, controlled by a single switch in the control room. Groundstaff can flip that switch on for a practice session to test it, then flip it off instantly if something looks wrong, without rewiring anything. Only when confidence is high do they leave it on for every match night. That wired-in-but-switch-controlled rollout is exactly how feature flags let code ship without immediately being visible to every user.
Step-by-Step Explanation
Step 1
Merge code behind a flag check
New functionality ships to production continuously, gated by a conditional that defaults to off.
Step 2
Flag service evaluates targeting rules
A remote config service resolves whether the flag is on for the current user based on segment, percentage, or environment rules.
Step 3
Gradual rollout and monitoring
The team widens the rollout percentage while watching error rates and metrics, ready to roll back instantly.
Step 4
Flag cleanup
Once the feature is fully rolled out and stable, the flag check and old code path are removed from the codebase.
What Interviewer Expects
- Clear articulation of decoupling deployment from release
- Awareness of gradual rollout, kill-switch, and A/B testing use cases
- Mention of flag hygiene — removing stale flags to avoid dead conditional branches
- Understanding of frontend-specific risks like flash of wrong variant on first render
Common Mistakes
- Never removing stale flags, leading to an unmaintainable tangle of dead conditionals
- Evaluating flags only client-side after first paint, causing visible layout shift/flicker
- Treating flags purely as booleans and ignoring percentage rollout/targeting capabilities
- Not testing both flag states (on and off) before merging
Best Answer (HR Friendly)
“Feature flags let us merge and deploy code to production without immediately showing it to every user — we wrap the new feature in a toggle we control remotely, so we can turn it on for a small group first, watch how it performs, and instantly turn it off if something goes wrong, all without a new release. It lets us ship safely and gradually instead of doing risky all-or-nothing launches.”
Code Example
function useFeatureFlag(key, defaultValue = false) {
const [enabled, setEnabled] = useState(defaultValue)
useEffect(() => {
fetchFlags(currentUser.id).then((flags) => {
setEnabled(Boolean(flags[key]))
})
}, [key])
return enabled
}
function CheckoutPage() {
const newCheckoutEnabled = useFeatureFlag('new-checkout-flow')
return newCheckoutEnabled ? <NewCheckoutFlow /> : <LegacyCheckoutFlow />
}Follow-up Questions
- How would you avoid a flash of the wrong variant on first render for a critical flag?
- How do you decide when it is safe to remove a stale feature flag from the codebase?
- How would you test both the on and off states of a flag in CI?
- How does a percentage rollout differ from a user-segment targeting rule?
MCQ Practice
1. What is the primary benefit of feature flags in frontend delivery?
Flags let code ship to production while controlling visibility separately, without a new deploy to change state.
2. What is a common frontend-specific risk when using feature flags?
If a flag resolves after initial render, users can briefly see the default variant before the correct one appears.
3. Why is removing stale feature flags considered important?
Flags left in the code after full rollout become permanent dead branches that clutter the codebase.
Flash Cards
What do feature flags decouple? — Deployment (shipping code) from release (making it visible to users).
What is a kill-switch use case? — Instantly disabling a misbehaving feature without a new deploy.
Frontend-specific flag risk? — Flash of the wrong variant if the flag resolves after first paint.
Why remove stale flags? — To avoid dead conditional branches that make code harder to maintain and test.