How would you refactor an inverted test pyramid?
This tests your ability to create a pragmatic, multi-sprint strategy for tech debt. A good answer includes analyzing the suite, quarantining flaky tests, enforcing new coverage standards, and incrementally refactoring. A red flag is proposing a total rewrite.
What's really being asked
This question tests your ability to move from theory (knowing the test pyramid is good) to practice (creating a concrete, multi-quarter plan to fix a bad situation). It evaluates your strategic thinking, pragmatism, and leadership. Can you balance improving engineering effectiveness with ongoing feature delivery? Can you influence a team to adopt new habits? It's not about the definition of the pyramid, but the execution of the refactor.
The full answer
A strong answer presents a phased, data-driven approach. First, analysis: quantify the problem. Instrument the test suite to track execution time, failure rate, and code coverage by test type. For example, "Our P95 build time is 45 minutes, with 80% spent on E2E tests that cover only 15% of the code." Second, containment: immediately stop the bleeding. Quarantine the top 10% flakiest tests to run separately, and establish a team policy like "no new E2E tests without an architecture review." Third, incremental refactoring: for all new features, require proper unit and integration test coverage. Dedicate a small percentage of capacity each sprint (e.g., 15-20%) to a "test refactoring" epic. The goal is to take one critical E2E test, write the equivalent unit/integration tests that cover the same logic faster and more reliably, and then delete the E2E test.
The mistakes people make
The most common red flag is proposing an unrealistic "big bang" solution. This includes suggesting a "testing sprint" or "rewrite sprint" where the team stops all feature work. This shows a lack of business awareness. Another red flag is a purely technical answer that ignores the human element. A good strategy requires getting team buy-in, changing coding habits, and adjusting CI/CD workflows, not just writing different code. Finally, weak answers stay too high-level, saying "we should write more unit tests" without providing a concrete plan for how to get there.
What usually comes next
"How would you get buy-in from your product manager for this work?" (Answer: Frame it in business terms—faster delivery, fewer hotfixes, higher developer velocity). "What if a senior engineer on your team pushes back, saying the E2E tests provide the most value?" (Answer: Use data. Show the high cost, flakiness, and low value of specific tests, and demonstrate how faster, more targeted tests can provide better confidence). "What specific tools would you use to measure coverage and flakiness?"
A concrete example
"In Sprint 1, we'd focus on analysis. I'd set up tooling to measure test suite performance and identify our 5 flakiest and 5 slowest E2E tests. In Sprint 2, we'd quarantine those tests and create a team agreement for new code. We'd also allocate one story point to refactoring: pick the simplest, highest-value E2E test (e.g., 'user login'), write corresponding integration/unit tests, and then delete the original Selenium test. This might save 90 seconds on every CI run. We'd repeat this process, chipping away at the E2E suite sprint by sprint."
Interview question
When refactoring an inverted test pyramid in a mature product, which strategy is most aligned with a pragmatic, multi-sprint approach?
- a.Implement a phased strategy: first analyze test suite performance, then quarantine flaky E2E tests, and incrementally replace high-value E2E tests with faster unit/integration tests using dedicated sprint capacity.Correct
- b.Focus solely on new development by enforcing strict unit test coverage for all new features and gradually deprecating old E2E tests as they become irrelevant.
- c.Optimize the existing E2E test suite by investing in better infrastructure, parallel execution, and flakiness reduction tools to speed up build times.
- d.Schedule a dedicated 'testing sprint' where the team pauses feature development to rewrite all existing E2E tests as unit and integration tests.
Why? this is the answer
A pragmatic, multi-sprint strategy involves a phased, data-driven approach, starting with analysis and containment, followed by incremental refactoring with dedicated capacity. A 'big bang' rewrite (option D) is a common red flag, and merely optimizing E2E tests (option C) or passively waiting for deprecation (option B) does not address the core structural issue of an inverted pyramid.
Just read this? Test yourself on what you have been reading.
Read the original → martinfowler.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 testing — each one lists the topics its interview covers.
See open roles