The Feature Flag Graveyard

“Your codebase has 240 feature flags. 180 are dead. Removing them touches 700+ call sites. Q3 adds 20 more. What's your move?”

The Situation

You're a Staff Android engineer who just joined a team that's been shipping A/B experiments at high velocity for 3 years. Your codebase has 240 hardcoded feature flag constants, plus another 80 flags in Firebase Remote Config. Static analysis shows 180 of the hardcoded constants are dead — but some are overridden by Remote Config in production, making automated cleanup risky without cross-system coordination. Removing them safely requires touching over 700 call sites across 12 modules. Meanwhile, your Q3 roadmap includes 20 new experiments.

Context

Removing flags manually would require 3+ weeks of developer time with high regression risk
The CI pipeline is slow — each change requires a full build and test run of 35 minutes
Product managers use a mix of Firebase Remote Config and hardcoded constants — no single source of truth
Two engineers own the experiment infrastructure but are fully allocated to Q3 features
The flags are already causing conditional complexity that slows new feature development

The Question

“Tell me about a time you identified a systemic technical debt problem and drove a solution that was bigger than a cleanup sprint.”

Response Options

One of these is the strongest response. The others reflect common approaches with real trade-offs.

I scheduled a 'flag cleanup sprint' for two engineers to manually audit and remove dead flags over a two-week period.

I built an AST-based code analysis tool to automatically detect and PR-generate removals for always-on and always-off flags, and proposed a flag TTL policy requiring every flag to have a removal date set at creation — enforced in CI.

I escalated to engineering leadership to get dedicated headcount for a flag infrastructure quarter focused on cleanup and tooling.

I added a linting rule that prevents new flags from being merged without a linked JIRA ticket for removal, and trusted the team to clean up old flags organically.

The Debrief

Why the Best Response Works

Answer B works because it addresses both dimensions of the problem: the existing backlog (automated removal) and the future accumulation (TTL policy + CI enforcement). The AST tool is the multiplier — instead of 3 weeks of manual effort, you generate PRs that engineers can review, not write. The policy change is the lasting fix because it makes the default behavior the right behavior.

What to Avoid

The cleanup sprint is the most tempting response — it's visible, bounded, and feels like ownership. But it solves a state problem, not a flow problem. Two weeks after the sprint, flags accumulate again at the same rate. Staff engineers recognize when the problem is the process, not the backlog.

What the Interviewer Is Probing

The interviewer is testing whether you think at the system level or the task level. The right Staff answer eliminates the category of problem, not just the current instances. Automation + policy + enforcement is the pattern: make the right thing easy, the wrong thing impossible, and compliance verifiable.

SOAR Structure

**Situation:** 240 flags, 180 dead, 700+ call sites affected, Q3 adds 20 more. **Obstacle:** No existing tooling; CI cost; flag ownership distributed across 12 modules. **Action:** Built AST-based flag scanner; generated batch removal PRs; proposed TTL policy with CI enforcement gate; shipped dashboard showing flag health. **Result:** 160 dead flags removed in 6 weeks; new flag creation now requires TTL; flag count in CI-enforced compliance.

The Learning Arc

"This taught me that debt problems with no owner accumulate because the system makes them easy to create and hard to remove. Once I made removal easy (automated PRs) and creation governed (TTL policy), the team's behavior changed without requiring discipline. I now ask 'how does this grow?' before adding any new abstraction — because growth without cleanup is debt by default."

IC Level Calibration

senior

Build the AST tooling and run it yourself to generate a batch of PRs. Document what you found and propose the TTL policy. Get 50% of dead flags removed this quarter.

staff · Primary Target

Build the tooling, propose and get the TTL policy adopted in CI, present the flag health dashboard to the team, and define the SLO for flag lifecycle. Turn the cleanup into a repeatable process, not a one-time event.

principal

Drive the flag lifecycle policy as an org-wide standard. Work with the experiment platform team to make expiry a first-class feature of the flag infrastructure. Publish the approach as an internal engineering standard. Ensure other teams don't rediscover this problem.

Company Calibration

Google

Technical leadership: scalable solutions over point fixes