CFD shows a widening 'Testing' band. What does it mean?
This tests your ability to interpret process metrics and propose data-driven solutions. First, define the bottleneck: work enters testing faster than it leaves. Then, propose experiments to diagnose the cause before suggesting solutions.
What's really being asked
This question tests your ability to interpret process health metrics, specifically a Cumulative Flow Diagram. More importantly, it evaluates your problem-solving methodology. Are you data-driven? Do you diagnose before you prescribe a solution? The interviewer is looking for a structured, scientific approach to process improvement, not just a correct definition of a CFD bottleneck. They want to see you can move from observation to hypothesis to experiment.
The full answer
A good answer has three parts. First, clearly state what the widening band means: the rate of items entering the 'Testing' stage is greater than the rate of items leaving it. This is a classic bottleneck, and the work-in-progress (WIP) for that stage is increasing. Second, propose specific, data-driven diagnostic experiments. Avoid generic answers. Suggest measuring things like: 1) QA engineer active work time vs. idle/wait time, 2) the number and severity of bugs found per feature, 3) the cycle time for bug fixes from developers, and 4) uptime and performance of the testing environments. Third, based on the potential data from those experiments, suggest targeted solutions. For example, if data shows high idle time, it might be a developer hand-off issue. If test environments are slow, the solution is infrastructure, not hiring.
The mistakes people make
The biggest red flag is jumping to a solution without a diagnostic phase. Saying "We should hire more QA" or "Developers need to write better code" is a poor answer because it's a guess. Another weak answer is being too vague, like "We need to investigate the problem." A senior candidate must propose how they would investigate, using specific metrics and experiments. Blaming the QA team is also a major red flag, showing a lack of systems thinking.
What usually comes next
"Let's say your data shows that the test environment is stable and QA capacity is sufficient. What else could be causing the bottleneck?" (Probing for systemic issues like poor-quality handoffs, complex deployment processes, or unclear acceptance criteria). Another follow-up: "How would you convince your product manager to dedicate a sprint to fixing this, when they want to ship new features?" (Tests your influence and communication skills).
A concrete example
"I'd start by instrumenting our CI/CD and project management tools. Let's say over two weeks we find that for every 8-hour day, our 3 QA engineers are only able to actively test for 3 hours each. The other 5 hours are spent waiting for builds, waiting for a staging environment to be free, or trying to reproduce poorly documented bugs. This data (9 hours of active work vs. 15 hours of waste per day) makes it clear the problem isn't QA headcount. My first experiment would be to create a dedicated, stable staging environment for the next sprint and measure the change in active test time."
Interview question
Upon observing a widening 'Testing' band in a Cumulative Flow Diagram, what is the most effective initial action to take?
- a.Implement a strict code quality gate to prevent buggy features from reaching testing.
- b.Immediately increase the number of QA engineers to handle the growing workload.
- c.Pause new feature development to allow the testing team to clear the existing backlog.
- d.Initiate specific diagnostic experiments to understand the underlying causes of the bottleneck.Correct
Why? this is the answer
The card emphasizes that the most effective initial action is to diagnose the problem with data before prescribing solutions. Jumping to solutions like hiring more staff (Option B) or blaming developers (Option A) without understanding the root cause is explicitly identified as a common mistake.
Just read this? Test yourself on what you have been reading.
Read the original → monday.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 agile — each one lists the topics its interview covers.
See open roles