How would you set a WIP limit for code review?

WHAT THIS TESTS: 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.

A GOOD ANSWER COVERS: 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."

COMMON WRONG ANSWERS: 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.

LIKELY FOLLOW-UPS: 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).

ONE 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."