Diagnosing a Widening Code Review Band in a CFD

WHAT THIS TESTS: This question tests your ability to move from data to diagnosis to action. The interviewer is looking for more than just a definition. They want to see if you can apply systems thinking to identify a bottleneck, methodically investigate potential root causes without jumping to conclusions, and propose specific, practical solutions. It separates candidates who just report on metrics from senior engineers who use metrics to drive process improvement.

A GOOD ANSWER COVERS: An excellent answer has four parts. First, clearly define the problem: a widening band means the rate of work entering the 'Code Review' stage is consistently higher than the rate of work leaving it. This is a classic bottleneck. Second, list several plausible hypotheses for the root cause, such as insufficient reviewer capacity (e.g., only two seniors reviewing for a team of eight), pull requests being too large or complex, an inefficient review process (e.g., no SLAs), or low-quality code requiring multiple revision cycles. Third, explain how you would diagnose the true cause before acting, such as analyzing PR size data, measuring the cycle time for just the review stage, or simply talking to the team. Fourth, propose concrete, targeted solutions based on the likely cause, like implementing a WIP limit on the 'In Review' column, setting a soft guideline for PR size (<400 LoC), or encouraging pair reviewing.

COMMON WRONG ANSWERS: A major red flag is jumping to a single, expensive solution like "We need to hire more seniors." This shows a lack of diagnostic rigor. Another is blaming people instead of the process, with statements like "Our devs are writing sloppy code" or "The reviewers are too picky." Vague answers like "We should discuss this in retro" are also weak; a senior candidate should be able to lead that discussion with data and proposals. Finally, some candidates misinterpret the chart, confusing a wide-but-stable band (high WIP) with a widening band (a growing bottleneck).

LIKELY FOLLOW-UPS: Expect questions like: "How would you get buy-in from the team to try one of your proposed changes?" or "Let's say you implement a WIP limit on reviews. What negative side effect might you watch out for?" or "What other charts or metrics would you look at to confirm your diagnosis?"

ONE CONCRETE EXAMPLE: "A widening review band is a bottleneck. My first step would be to quantify the problem. I'd pull data from our git provider for the last three months to chart the average PR size and the average time-to-merge after a PR is opened. If I see that average PR size has grown from 200 to 500 lines of code over that period, that's a strong signal. I'd bring this data to the team and propose an experiment: for the next two sprints, we try to keep PRs under a 300-line soft limit by breaking up work differently. We would then monitor the CFD to see if the band's growth slows or reverses."