Q070: Feature Flags, Experiments and Progressive Delivery

What Interviewers Want To Evaluate

This question tests whether you can release product changes safely. Interviewers want feature flags, kill switches, targeting, experiments, rollout percentage, client versus server evaluation, flag cleanup, analytics, and operational discipline.

For senior roles, the strongest answer explains that flags are a release tool, a product experimentation tool, and a source of complexity that must be managed.

Short Interview Answer

Feature flags decouple deploy from release. They let teams ship code dark, enable features for selected users, run experiments, progressively roll out changes, and disable risky behavior quickly. Flags need ownership, targeting rules, analytics, server or client evaluation decisions, fallback behavior, and cleanup. Stale flags create complexity and should be removed after rollout.

Detailed Interview Answer

A deploy moves code to production. A release exposes behavior to users. Feature flags separate those events. This makes rollouts safer because teams can limit exposure and respond quickly when metrics degrade.

Flags can also power experiments, but experiment flags need careful assignment, metric design, and analysis. A kill switch is different: it should be simple, reliable, and available when a feature misbehaves.

Deep Technical Explanation

The lifecycle is:

create flag
ship guarded code
enable for internal users
progressively roll out
monitor metrics
complete rollout
remove flag and old path

Client vs Server Evaluation

Client-side flags are useful for UI behavior, but users can inspect browser code and sometimes flag payloads. Sensitive entitlement or permission checks should be enforced server-side.

Server-side evaluation can protect sensitive rules and reduce client payload, but may require passing evaluated decisions to the frontend.

Experiments

Experiments need stable bucketing, clear success metrics, guardrail metrics, and analytics instrumentation. A/B tests are not just random UI changes; they are measurement systems.

Common Mistakes

A common mistake is leaving flags in the codebase forever. Stale flags multiply paths and make testing harder.

Another mistake is using client-side flags as security controls. They are not authorization.

Architecture Discussion

Flag systems should define naming, ownership, default values, fallback behavior, analytics, cleanup date, and rollout playbook. Critical flags should have dashboards and alerts.

Trade-Offs

Flags improve release safety but increase code complexity. Every active flag can double behavior paths. The team needs discipline to remove them.

Real Production Story

A new checkout UI can be deployed behind a flag, enabled for employees, then 5 percent of traffic, then expanded if conversion and error metrics are healthy. If payment errors rise, the flag can be disabled without redeploy.

Enterprise Example

In enterprise SaaS, flags may target tenant, plan, region, role, or contract entitlement. The UI should reflect enabled capabilities, but billing and permission enforcement must remain server-side.

Performance Discussion

Flag payloads should be small and available early enough to avoid flicker. Delayed client flag loading can cause UI jumps or hydration mismatches.

Security and Reliability Considerations

Do not expose sensitive rollout logic unnecessarily. Define safe defaults for flag service failure. For kill switches, failure mode should usually disable risky behavior.

Senior Engineer Perspective

A senior engineer should discuss rollout strategy, observability, cleanup, and the difference between release flags, experiment flags, and permission checks.

Lead Engineer Perspective

A lead should own flag hygiene: stale flag reports, cleanup tickets, naming conventions, experiment review, and production rollback drills.

Debugging Workflow

When a flagged feature misbehaves, check exposure rules, user assignment, flag payload, release version, analytics events, and whether the issue disappears when the flag is disabled.

Revision Notes

Feature flags decouple deploy from release. They are powerful only when paired with monitoring, safe defaults, and cleanup.

Key Takeaways

Flags are not free. They buy rollout safety at the cost of behavior complexity.

Follow-Up Questions

1. What problem do feature flags solve?
2. How is deploy different from release?
3. What is a kill switch?
4. How do experiments differ from release flags?
5. When should flags be evaluated server-side?
6. Why are stale flags risky?
7. What metrics should a rollout watch?
8. What is percentage rollout?
9. Why are client flags not authorization?
10. How do you clean up flags?

How I Would Answer This In A Real Interview

I would say flags let teams ship code separately from exposing behavior. Then I would cover targeting, progressive rollout, experiments, kill switches, monitoring, server/client evaluation, and cleanup discipline.