How do you fix an inverted test pyramid?

What's really being asked

This question tests your pragmatism and leadership, not just theoretical knowledge. The interviewer wants to see if you can create a realistic, incremental plan to pay down technical debt while managing business constraints and team dynamics. It evaluates your ability to make strategic trade-offs and influence a team to adopt better practices without halting feature development.

The full answer

A phased, multi-sprint strategy. First, in an 'Analysis & Alignment' phase, you quantify the problem. Use CI analytics to identify the top 5-10 slowest and flakiest end-to-end (E2E) tests. Present this data (e.g., 'These 10 tests account for 60% of our CI bill and 80% of flaky failures') to the team and product manager to secure buy-in for dedicating capacity, like 20% per sprint. Second, you begin 'Incremental Refactoring'. Enforce a strict rule for all new work: features must be covered primarily by unit and integration tests. Apply the 'boy scout rule' where any code being modified must also have its test coverage improved. Third, you practice 'Strategic Deletion'. As you build up lower-level test coverage for a feature, you deliberately delete the slow, brittle E2E test that it replaces. The goal is to change the ratio of tests. Finally, you improve 'Tooling & Guardrails'. Make it trivial to run fast tests locally and configure CI to provide rapid feedback on them, gating pull requests. Slower E2E tests can be moved to a separate, less frequent pipeline (e.g., nightly builds).

The mistakes people make

Proposing a 'big bang' rewrite or a dedicated 'testing sprint'. This is a huge red flag as it's impractical in almost any business. It shows a lack of experience balancing technical needs with product delivery. Another common mistake is being too vague, saying 'we should write more unit tests' without a concrete plan for implementation, capacity allocation, and team alignment. A senior answer must include a strategy for removing the bad tests, not just adding good ones; otherwise, the problem is just compounded. Finally, avoid blaming past decisions or teams; focus on a constructive path forward.

What usually comes next

'How do you convince a product manager to dedicate 20% capacity to this?' (Frame it in terms of business value: faster CI means higher developer productivity, fewer bugs in production means less time on hotfixes, and a healthier suite accelerates future feature delivery). 'What if the team resists?' (Start small, lead by example, and demonstrate quick wins. Convert one painful E2E test into fast integration tests and show the team the dramatic improvement in speed and reliability).

A concrete example

Consider a 3-minute E2E test that validates the entire user checkout flow. It's brittle and fails if any UI element changes. You would replace it with several targeted tests: a few unit tests for the cart's price calculation logic, an integration test for the OrderService that hits a test database to confirm order creation, and a consumer-driven contract test to ensure the frontend sends the correct payload to the Payments API. The only E2E test that might remain is a single, simple smoke test. This replaces one 3-minute test with a suite of tests that runs in under 3 seconds.