Trunk-Based Development vs. GitFlow for High-Frequency Releases
This tests your grasp of modern release strategy. Explain how TBD enables frequent merges to main, while feature toggles decouple deployment from release for safety. Contrast this with GitFlow's versioned release model.
What's really being asked
This tests your strategic understanding of the link between development workflow, risk management, and release cadence. The interviewer wants to see if you can articulate why Trunk-Based Development (TBD), combined with feature toggles, is the standard for high-velocity teams, and if you have a senior-level appreciation for the cultural and process challenges of adopting it.
The full answer
First, explain the mechanism: TBD involves all developers committing small changes directly to a single main branch, often multiple times a day. This keeps the codebase continuously integrated and avoids large, risky merge conflicts.
Second, describe the safety net: Feature toggles are the key enabler for low-risk releases. They allow incomplete or un-validated code to be merged and deployed but kept disabled for users. This decouples code deployment from feature release, which is the core principle.
Third, provide the contrast: Briefly compare this to GitFlow, which uses long-lived branches (develop, release) designed for scheduled, versioned releases. This older model often leads to slower feedback loops and painful 'merge hell' scenarios that delay releases.
Fourth, detail the transition challenges: The primary hurdles are not technical but cultural and process-oriented. A good answer mentions the mindset shift from feature isolation to collective code ownership, the absolute requirement for robust automated testing and CI pipelines to keep the trunk stable, and the new discipline required for managing the feature flag lifecycle (e.g., cleanup).
The mistakes people make
Simply defining the two models without explaining how TBD plus toggles enables the desired outcome of high-frequency, low-risk releases. A candidate who just gives definitions is missing the point.
Forgetting to mention feature toggles. TBD without toggles is a high-risk strategy, as every commit to main could potentially break production. The toggles are what make it safe.
Describing transition challenges as purely technical (e.g., "learning new git commands"). The real challenges are about team discipline, testing culture, and process change.
Presenting GitFlow as "bad" and TBD as "good" universally. GitFlow is a valid choice for projects with scheduled, versioned releases (like mobile apps or installed software), whereas TBD excels for web services with CI/CD.
What usually comes next
"How would you manage the 'feature flag debt' that can accumulate over time?" "What specific types of automated tests are non-negotiable for a team moving to TBD?" "Describe a situation where you would still recommend GitFlow over TBD."
A concrete example
A team moving from GitFlow to TBD is shifting from a model where a feature might live on a branch for 2 weeks to one where it must be merged within 1-2 days. At Google's scale, over 25,000 engineers commit to a single trunk. This is only possible because new code is merged behind feature flags. A new, half-built API endpoint can be deployed to production but toggled 'off' so it receives no traffic, while the team continues to iterate on it directly in main.
Interview question
A team wants to adopt Trunk-Based Development to increase release frequency. What is the most critical practice that allows them to safely merge and deploy incomplete features?
- a.Requiring comprehensive peer review on all pull requests before merging.
- b.Enforcing small, atomic commits that pass all automated tests.
- c.Using feature toggles to decouple code deployment from feature release.Correct
- d.Maintaining a separate, long-lived 'develop' branch for integration.
Why? this is the answer
Feature toggles are the key safety net in Trunk-Based Development, allowing incomplete code to be merged and deployed but kept disabled for users. While small commits and testing (B) are essential, they don't solve the problem of an unfinished feature being live.
Just read this? Test yourself on what you have been reading.
Read the original → flagsmith.com
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. Open roles that interview on ci/cd — each one lists the topics its interview covers.
See open roles