Lesson 15 of 30

Feature Flags

Q: How would you safely roll out a risky new feature to production?

A strong answer covers: Feature flags decouple deploy (code shipped) from release (feature active), enabling gradual rollout by percentage/user segment; Instant, code-free rollback by flipping the flag off — much faster than a revert-and-redeploy; Awareness of flag debt — stale flags left after full rollout are dead code that should be cleaned up.

A runtime switch that decides whether a piece of code path is active — separating 'is this code deployed' from 'is this feature turned on,' which is the whole trick behind shipping safely and often.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 2

A newly-released feature is causing errors in production. With a feature flag in place, what's the fastest way to stop the bleeding?

Feature flags don't help with already-deployed problems, only with rolloutsFlip the flag off — no revert, rebuild, or redeploy neededRevert the commit and redeploy immediately

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Feature Flags

What interviewers actually ask about this, and what a strong answer has to cover.

How would you safely roll out a risky new feature to production?

A strong answer covers

Feature flags decouple deploy (code shipped) from release (feature active), enabling gradual rollout by percentage/user segment
Instant, code-free rollback by flipping the flag off — much faster than a revert-and-redeploy
Awareness of flag debt — stale flags left after full rollout are dead code that should be cleaned up

Likely follow-ups

How do feature flags relate to A/B testing?
How do flags make trunk-based development practical for large, multi-week features?
What's the maintenance cost of feature flags, and how would you manage it?

Practice these with the AI interviewer →

The plain-language idea

Without feature flags, "deploy" and "release" are the same moment — the instant your code ships, every user sees it. A feature flag decouples them: the code can be deployed, dormant, behind a check, and turned on later — for everyone at once, for a percentage of users, or for specific accounts — with no new deploy required to flip it.

function Dashboard() {
  const showNewLayout = useFeatureFlag("new-dashboard-layout");
  return showNewLayout ? <NewDashboardLayout /> : <LegacyDashboardLayout />;
}

Feature flags: shipping code and enabling it are two separate stepsStep 1 of 3

if (flags.newCheckout) { <NewCheckout /> } else { <OldCheckout /> } — both code paths ship in the same deploy.

What people usually miss

Watch out

A flag is also a fast, code-free rollback mechanism. If a newly-released feature causes problems, flipping the flag off is immediate — no revert, no rebuild, no redeploy — much faster than the alternative of shipping a hotfix.
Flags enable real experimentation (A/B testing), not just binary on/off — showing variant A to 50% of users and variant B to the other 50%, then measuring which performs better, is the same underlying mechanism as a simple release flag.
Flag debt is a real, ongoing cost. Every flag left in the codebase after a feature has fully shipped (and the old path is never used again) is dead code and an extra branch to reason about — removing stale flags is a genuine maintenance responsibility, not optional cleanup.

Why this matters in interviews

"How would you safely roll out a risky change to production?" is a real operational question, and feature flags (gradual rollout, instant rollback, decoupling deploy from release) is the concrete, industry-standard answer — far stronger than "test it really well before shipping."