How would you set a WIP limit for code review?
This tests your ability to use data to diagnose a bottleneck and facilitate a solution. A great answer gathers flow metrics, proposes an initial limit based on team size (e.g., N/2), and frames it as an experiment.
What's really being asked
This question assesses your ability to move from vague feelings ("reviews feel slow") to a data-driven, experimental approach. It tests your understanding of flow metrics, your facilitation skills, and your grasp of systems thinking, specifically the Theory of Constraints. The interviewer wants to see if you can lead a team toward a solution by making the problem visible with data, rather than just imposing a rule.
The full answer
A good answer hits four points. First, the data gathering phase: collect quantitative metrics like cycle time for the 'Code Review' stage, the age of the oldest PRs, and the number of PRs currently in review per engineer. Second, gather qualitative data by talking to the team about why reviews might be stalling. Third, the facilitation phase: present the data in a retro or dedicated meeting, making the problem visible to everyone. Don't just show averages; show the distribution and outliers. Fourth, propose an initial limit as a starting point for an experiment, not a final rule. A common starting point is N/2 or N-1 where N is the number of engineers. Frame it as "Let's try a limit of 4 for two weeks and measure the impact on our overall lead time."
The mistakes people make
A major red flag is jumping straight to a solution without mentioning data ("We should set the limit to 3."). Another is focusing only on punishing people for not reviewing code, which creates a toxic culture. A junior answer might suggest a limit that is too high (e.g., equal to the number of engineers), which defeats the purpose of a limit, or too low, which could cause developer idle time if the upstream process is not smooth. Finally, treating the WIP limit as a rigid, permanent rule rather than a tool for learning and continuous improvement is a sign of inexperience.
What usually comes next
Expect questions like: "What if the team resists setting a limit?" (Answer: Focus on the pain the current situation is causing and frame the limit as an experiment to solve that pain). "What other columns might need a WIP limit?" (Answer: Any column that is a consistent bottleneck). "After setting the limit, what metric would you watch to see if it's working?" (Answer: Overall cycle time from 'In Progress' to 'Done'. The goal is to optimize the whole system, not just one column).
A concrete example
"Our team of 8 engineers had an average of 12 PRs in the review column. The cycle time for that column was 3.5 days. I pulled the data from our ticketing system and showed the team a histogram of PR age; several were over a week old. I proposed an experiment: a WIP limit of 4 (8 engineers / 2) for two sprints. We agreed to swarm on older reviews to get under the limit. After a month, our review cycle time dropped to 1.5 days and our overall feature lead time decreased by 20% because work flowed more smoothly."
Interview question
Which approach best reflects a data-driven and experimental method for setting a code review WIP limit?
- a.Immediately implement a limit of N/2 (where N is team size) and monitor its impact on overall lead time.
- b.Mandate a strict limit based on the number of active pull requests per engineer to ensure individual accountability.
- c.Research common industry best practices for review limits and apply the most frequent recommendation as a new team standard.
- d.Collect cycle time data for reviews, discuss findings with the team, and propose a temporary limit to test its effect.Correct
Why? this is the answer
The recommended approach involves gathering quantitative and qualitative data, presenting it to the team for discussion, and then proposing an initial limit as an experiment. This contrasts with immediately implementing a solution or imposing a rigid rule without data-driven team involvement.
Just read this? Test yourself on what you have been reading.
Put your scrolling time to good use
Learn one idea, try a quiz and save useful cards for revision. Tezvyn makes it easy to learn and stay current in your tech field, a few minutes at a time.
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 agile — each one lists the topics its interview covers.
See open roles