Diagnosing a Widening CFD 'Testing' Band
Tests your ability to interpret a CFD and propose data-driven experiments. A widening 'Testing' band means work enters faster than it leaves. Diagnose with experiments (e.g., tracking test failures, environment downtime) before proposing solutions.
What's really being asked
This question assesses your ability to translate a visual process metric into a concrete diagnosis and then apply a scientific method to problem-solving. It's not about knowing what a CFD is, but about using it as a starting point for data-driven, iterative improvement. The interviewer is looking for a structured, hypothesis-driven approach, not a single "correct" answer. They want to see if you diagnose before you prescribe a solution.
The full answer
A strong answer has three parts. First, a clear diagnosis: a widening 'Testing' band means the arrival rate of work into the 'Testing' stage is greater than the departure rate, indicating a bottleneck. Work is piling up. Second, a list of specific, data-driven diagnostic experiments. You would propose to gather new data to isolate the cause, such as tracking test environment uptime, measuring the flaky test rate (e.g., tests that fail then pass with no code change), timing the duration of manual vs. automated test suites, or categorizing bug types found in QA. Third, you'd explain how the results of these experiments would lead to different solutions. For example, high environment downtime points to an infrastructure fix, while a high number of regressions points to a need for better unit test coverage upstream.
The mistakes people make
The biggest red flag is jumping to a solution without a diagnostic phase. A candidate might immediately say "We need to hire more QAs" or "We should automate everything." This shows a lack of analytical rigor. Another weak answer is being too vague, suggesting "We should look into it" without proposing specific metrics to collect or experiments to run. A senior candidate must be able to articulate how they would investigate, not just that they would. Blaming the QA team is also a major red flag; the CFD shows a system problem, not necessarily a people problem.
What usually comes next
Expect questions like: "Let's say you discover 30% of test runs fail due to a flaky test environment. What's your next step?" or "How would you justify the engineering cost of fixing the test environment to a product manager who wants to ship features?" or "What if your experiments are inconclusive? What's your plan B?" These follow-ups test your ability to act on the data you've gathered and navigate organizational trade-offs.
A concrete example
"I'd start by instrumenting our CI/CD pipeline. My hypothesis is that our end-to-end test suite is the problem. I'd add logging to measure two things over the next 5 sprints: 1) The P95 duration of the full test suite run. 2) The percentage of runs that fail for non-product reasons, like a timeout fetching a dependency or a staging DB reset. If the duration is consistently over our 45-minute target, we'll focus on parallelizing tests. If the flaky failure rate is over 10%, we'll dedicate engineering time to stabilizing the test infrastructure itself."
Interview question
A team's Cumulative Flow Diagram shows the 'Testing' band widening over several sprints. What is the most effective initial action to take?
- a.Limit the amount of new work entering the 'Testing' stage until the QA team can clear the existing backlog.
- b.Advocate for hiring more QA engineers to increase testing capacity and handle the growing backlog.
- c.Initiate a project to automate more tests, as the slow departure rate indicates inefficient manual processes.
- d.Propose specific data collection experiments, like measuring test environment stability or categorizing failures, to diagnose the bottleneck.Correct
Why? this is the answer
The correct first step is to diagnose the problem with data before prescribing a solution. A widening band indicates a bottleneck, but the cause is unknown. Jumping to solutions like hiring, limiting work, or automating is premature and may not address the actual root cause.
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