Backend coding interview
Feature Flag System Coding Interview Problem
Written and reviewed by Sahil Srivastav
What this interview round tests
Feature flags are the control plane of modern backend deployment — every gradual rollout, A/B test, and 2 a.m. emergency shutoff runs through one — and they have quietly become a favourite interview problem at platform and infrastructure teams. The question sounds administrative: given a user and a flag, is the feature on?
The grading lives in three properties that sound obvious and break constantly. Determinism: a user at 30% rollout must get the same answer on every request, and stay enrolled when the rollout grows to 50% — anything else flickers the UI and corrupts experiments. Precedence: targeting rules evaluate in priority order, and the kill switch beats everything, because the whole value of a kill switch is that nothing overrides it. Isolation: a flag enabled in staging must mean nothing in production. Each is a one-line spec and a subtle implementation.
The scenario
You are handed a feature-flag service: flags carry targeting rules (user lists, attributes, percentage rollouts) per environment, evaluation answers on/off per user, and a kill switch exists for emergencies. It returns plausible answers — and the test suite shows they are wrong in every dimension that matters.
The same user flips between on and off across requests at a fixed percentage, growing a rollout un-enrolls users it already admitted, rules fire out of priority order, staging configuration leaks into production evaluations, and the kill switch loses to a specific-targeting rule. Your job is to make evaluation deterministic, ordered, isolated, and killable.
What you’ll practice
- Deterministic bucketing: hashing user + flag into a stable rollout bucket
- Monotonic rollouts: 30% → 50% keeps every previously enrolled user
- Priority-ordered rule evaluation with first-match semantics
- Kill-switch precedence: one check that beats every rule, always
- Environment isolation: per-env config with no cross-contamination
- Default behaviour: what evaluation returns when no rule matches
How to approach it
Derive the rollout decision from a pure function, not a random draw: hash a stable key (user id + flag key) into a bucket in [0, 100) and compare against the percentage. The same input then yields the same bucket forever, and raising the threshold only admits new buckets — determinism and monotonicity fall out of one design choice. Seed the hash per flag, or every flag at 30% enrolls the same third of your users.
Then shape evaluation as a strict pipeline: kill switch first, unconditionally; then rules in priority order with first match winning; then the percentage gate; then the default. Most bugs in this problem are ordering bugs — a check that happens late, a rule loop that keeps evaluating after a match — so the fix is making the pipeline order explicit and untouchable.
The starter repository ships with a failing test suite and a bundled verify.sh. Reviewed reference solutions are part of Gronex Pro — this page stays spoiler-free on purpose.
Try it in a real repository
LeetCode teaches algorithms. Gronex teaches backend coding rounds with real repositories, failing tests, service logic, and production-style constraints. Read the diagnostic brief on this page, then open the challenge workspace when you are ready to investigate the repository.
FAQ
Why can’t percentage rollout just use a random number?
Because the decision must be repeatable: a user who saw the feature on this request must see it on the next, and must still see it when the rollout widens. Randomness re-rolls the dice per request; a stable hash of user and flag makes enrollment a property of the user, which is what experiments and gradual rollouts assume.
What makes kill-switch precedence an interview topic?
Because it is an ordering guarantee, not a feature. A kill switch that can lose to any other rule — a whitelist, an override, a cached decision — is not a kill switch. Interviewers probe whether your evaluation order makes the guarantee structural rather than accidental.
Do I need to build a UI or SDK for this?
No. The problem is the evaluation engine itself: configuration in, decisions out. The bundled test suite feeds it users, rules, environments, and rollout changes, and audits the answers for determinism, ordering, and isolation in Java, Python, or C++.
Related
Explore more interview problems
- Airflow DAG Dependency & Idempotent Load Coding Problem
- Pandas Join Fan-out & Deduplication Coding Problem
- SQL Window Function Partitioning Coding Problem
- Incremental CDC Merge & Late-arriving Data Coding Problem
- Data Leakage in a Feature Pipeline Coding Problem
- Model Serving Prediction API Contract Coding Problem