How do feature flags enable unfinished work in Trunk-Based Development?

WHAT THIS TESTS: This question probes whether you understand the core tension in Trunk-Based Development: integrating code frequently without releasing unfinished work. The interviewer wants to see that you can separate deployment mechanics from user-facing release decisions, and that you know how feature flags fit into a continuous CI/CD pipeline rather than acting as a band-aid for poor branching strategy.

A GOOD ANSWER COVERS: Four specific things in order. First, the developer workflow: engineers working on multi-week features still merge to main daily or multiple times per day, but wrap new code paths in feature flags that default to off in production. Second, the CI/CD interaction: the pipeline builds and deploys main continuously, treating every commit as production-ready because the dormant flag hides incomplete behavior; automated tests run against both flag states where needed. Third, runtime behavior: the application evaluates flags at request time using a flag service or config, so the same binary serves both old and new code paths without separate artifacts. Fourth, release progression: when the feature is complete, the team enables it for internal users, then a small percentage of traffic, then full rollout, with the ability to instantly disable via a kill switch if errors spike.

COMMON WRONG ANSWERS: Three red flags stand out. One, suggesting long-lived feature branches as the primary mechanism; this contradicts TBD and reintroduces merge conflict pain. Two, claiming feature flags let you skip tests or merge broken code; the trunk must always be green, and flags require testing both on and off states. Three, confusing flags with separate deployment environments; staging is not a substitute for integrating to main, and flags live in production code, not in branch isolation.

LIKELY FOLLOW-UPS: The interviewer may ask how you handle flag cleanup and technical debt, since stale flags clutter the codebase; expect to discuss time-bombing flags or mandatory removal tickets. They might also ask about testing strategy, specifically how to test flag combinations without exponential blowup, or how to manage flag consistency across microservices. Another angle is operational risk: what happens if the flag evaluation service fails, and how do you default safely.

ONE CONCRETE EXAMPLE: Imagine a team adding a new recommendation engine that takes six weeks. Instead of a branch, they merge the data model in week one behind flag RECOMMENDATIONS_V2 set to false. The CI/CD pipeline deploys this to production ten times per day with no user impact. In week three they add the API layer, still behind the flag. In week six they enable it for 5 percent of users, monitor latency and error rates, then ramp to 100 percent over two days. If latency jumps by more than 50 milliseconds, the flag reverts to false in seconds without a rollback deployment.

Source: Travis CI