How do you systematically manage and pay down experiment debt?
Tests sustainable velocity through experiment lifecycle hygiene. Strong answers cover isolated experiment directories, TTLs on feature flags, and recurring cleanup sprints. Red flag: banning experiments or treating all experiment code as permanent.
What's really being asked
This question tests whether you understand that growth engineering velocity is a function of sustainable systems, not just shipping speed. Interviewers want to see if you can design processes that keep experiment code from permanently polluting the production codebase while still preserving the fast iteration cycles that growth teams require. The core tension is between allowing engineers to move quickly and preventing abandoned branches, stale feature flags, and untested paths from calcifying into technical debt.
The full answer
First, structural separation in the codebase. Mention isolating experiment code into dedicated directories or using component wrappers so that throwaway logic is visually distinct from production code. This makes cleanup obvious and allows you to enforce different code coverage or style standards for experiments. Second, enforce time-to-live policies on feature flags and experiments, paired with automated stale-experiment detection and a recurring cleanup ritual such as a quarterly debt sprint. Third, require a productionization gate: before experiment code graduates, it must meet standard testing and observability bars. Fourth, safety tooling like error boundaries to prevent a crashing experiment from taking down an entire page, plus automated test suites that verify key tests still pass under specific experiment subsets. Fifth, shared accountability: the PM or growth team owns experiment hygiene, not just engineering, and the experiment results dashboard must be thorough enough to kill losing tests quickly.
The mistakes people make
A major red flag is proposing a blanket ban on experiments or adding heavyweight code review that destroys iteration speed. Another is treating experiment debt as purely an engineering problem without involving PMs in cleanup prioritization. Suggesting manual tracking spreadsheets instead of automated flag TTLs shows a lack of tooling imagination. Finally, ignoring safety mechanisms like error boundaries implies you have not operated in a high-velocity environment where broken experiments directly impact revenue.
What usually comes next
The interviewer may ask how you would handle native mobile experiment debt where app store releases slow down cleanup, pushing you toward solutions like React Native Code Push, Flutter, server-driven UI, or webviews. They might also probe how you balance different test coverage standards for throwaway code versus productionized code, or how you prevent an experiment from negatively impacting core metrics through automated alerts and on-call rotations.
A concrete example
At a previous company, we created an experiments directory adjacent to production features and required every experiment flag to have an expiration date in our configuration. If a flag exceeded its TTL without a decision, it auto-alerted the owning PM and engineer. Winning variants were promoted out of the experiments directory into the main codebase with full test coverage, while losing variants were deleted in a weekly cleanup job. We also wrapped all experiment components in error boundaries, ensuring a broken A/B test never 500-ed the entire landing page. This kept our deploy velocity at multiple times per day while keeping the main codebase clean.
Interview question
A growth team’s codebase is filling with stale flags and abandoned branches. Which approach best sustains iteration speed while systematically managing experiment debt?
- a.Ban short-lived experiments and require full production code review for every variant to prevent debt accumulation.
- b.Track experiments in a shared spreadsheet, require manual PM approval for flag removal, and apply production test standards to all throwaway variants.
- c.Isolate experiment code in dedicated directories and run quarterly engineering cleanup sprints while letting feature flags persist without automatic expiration.
- d.Isolate experiment code in dedicated directories, enforce automatic TTLs on flags with stale alerts, require a productionization gate for graduating winners, and make PMs co-own hygiene.Correct
Why? this is the answer
The correct answer combines structural isolation, automated TTLs with alerts, a productionization gate, and shared PM/engineering accountability—the exact balance the card describes for sustainable velocity. Option C is tempting because it includes isolation and cleanup sprints, but without automatic TTLs and PM co-ownership, flags persist indefinitely and hygiene remains purely an engineering burden.
Just read this? Test yourself on what you have been reading.
Read the original → alexeymk.com
- #growth engineering
- #experimentation
- #technical debt
- #feature flags
- #engineering process
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Every open role lists the topics its interview covers, so you can prepare for the real thing rather than guessing.
See open roles