A Feature-Flag Interview Exercise With a Stuck Rollout
Resolve a stuck feature-flag rollout through ownership, evidence, data compatibility, safe fallback and deliberate flag removal.
TL;DR
- In this fictional exercise, a reporting feature has remained enabled for a small group without a clear rollout decision.
- Reconstruct the flag's state and distinguish release control, experiments, and operational safeguards.
- Choose a safe next step, sequence flag removal, and rehearse failures across the interface, jobs, and stored configuration.
Diagnose the stuck rollout
Use this fictional interview prompt: a new reporting interface has been enabled for a small group of accounts for six weeks. Two code paths remain active, support cannot tell which interface a customer sees, and the original owner has moved teams. The interviewer asks what you would do with the feature flag.
Do not immediately choose between deleting the flag and expanding to everyone. First establish why the rollout stopped, what the enabled users experience and whether either path has changed underlying data. A flag is a routing mechanism; it is not a complete release decision or a guarantee that reverting the interface is safe.
The exercise tests operational ownership and lifecycle reasoning. It does not require a particular flag vendor or imply that every temporary flag has the same acceptable lifetime.
Reconstruct the current state
Create a small rollout record containing the flag's purpose, current targeting rule, evaluation locations, owner and decision history. Check actual evaluations rather than relying only on a control-panel setting. Clients, services and background workers may evaluate the same flag at different times.
| Question | Why it matters |
|---|---|
| Who is currently enabled? | Defines the affected population |
| What stopped expansion? | Separates missing evidence from a known defect |
| Which path writes data? | Reveals compatibility and rollback risk |
| Who can change targeting? | Establishes operational authority |
| What happens if evaluation fails? | Makes fallback behaviour explicit |
Use the fictional account groups to explain stable assignment. A user who moves between paths unpredictably can experience inconsistent workflows and produce confusing evidence. State the intended evaluation identity and how it is shared across the relevant components.
Separate release, experiment and operational control
The original feature-toggle discussion distinguishes different categories of toggles and their management needs. Use that distinction to ask whether this flag is a temporary release mechanism, an experiment or a deliberate long-lived operational control.
If it began as a release flag, do not preserve it forever merely because removing it requires work. If the team now wants an operational switch, define that new purpose, owner and tested fallback explicitly. Renaming the flag without changing its responsibilities does not resolve the ambiguity.
An experiment also needs a decision rule. A stalled comparison with no agreed outcome is not made rigorous by leaving users split indefinitely. Identify the evidence still needed and who will decide what it means.
Work through a safe decision
Suppose the fictional investigation finds that the new interface writes a richer report format, while the old interface can read only the previous format. Switching everyone back could make recently created reports unusable. This is a compatibility problem, not merely a targeting problem.
Explain the available options: add compatible reading, restrict the affected operation, repair a specific defect or maintain a bounded cohort while the compatibility work is completed. Choose based on the supplied constraints and name the remaining risk. Do not promise instant rollback simply because a boolean can change instantly.
If the new path is ready, define an expansion plan with observable checks and a stop condition. If it is not viable, define how enabled users and their data return to a supported state. Either choice needs communication to support and the people responsible for incidents.
Make removal a sequence
Once the release decision is complete, flag removal still requires care. Stop creating new dependencies on the old path, confirm which versions remain in service and remove obsolete code and tests deliberately. A mobile or desktop client that updates slowly can extend the compatibility period.
Check background jobs and stored configuration as well as the main interface. Removing the targeting rule while a worker still asks for it can invoke an unexpected default. Document the intended permanent behaviour before deleting the control.
Our system design frameworks guide can help you diagram the distinction between routing, data compatibility and operational ownership. Keep those concerns visible rather than burying them in a cleanup ticket.
Record who accepts the final release decision and who owns the cleanup work; those responsibilities may belong to different people.
Add a failure rehearsal
Ask a partner to make the flag service unavailable during rollout. Explain the cached or default behaviour for each component and whether it is safe for the operation. Then have the partner reveal that a support agent changed the targeting rule without a recorded reason.
Your answer should include an audit trail appropriate to configuration changes, a responsible owner and a way to identify the experience an affected account actually received. Avoid logging unnecessary private user data merely to track a flag evaluation.
Finish with a decision deadline, evidence checklist and removal or long-term ownership plan. Use the mock interview strategy to explain the sequence concisely. A strong response ends the uncertainty around the rollout while respecting the state already created by both paths.