How do you balance test coverage against speed of delivery?

The framing that coverage and speed trade off is misleading because the lever isn't "more tests = slower." It's "the wrong tests = slower without proportional coverage gain."

Strategies that buy both:

1. Test-pyramid discipline. Unit tests are 100x faster than E2E. Pushing test logic down the pyramid — same coverage at lower cost — is the single biggest lever.
2. Parallel execution. Sharding tests across runners turns a 60-minute serial suite into a 10-minute parallel one. Adds CI cost, not developer wait time.
3. Smart selection. Run only impacted tests on PR, full suite nightly. Branch CI is fast; main is thorough.
4. Pruning. A 5,000-test suite half full of dead and flaky tests is slower and weaker than a 2,000-test maintained suite.
5. Tag-based runs. Smoke on every PR, regression on PR-to-main, full suite + perf nightly. Match scope to risk.

Where the trade-off is real: new niche features where the cost of test infra exceeds the value (skip until it stabilises); edge cases with low business impact (defer until needed); slow E2E tests of a flow already covered at unit + contract level (don't add).

A worked answer: "On my last team, our PR pipeline ran 90 minutes — engineers context-switched. We dropped it to 18 minutes by sharding 4×, removing 200 dead tests, moving 60 E2E to contract-level tests, and gating long performance tests behind a label. Coverage went up — the contract tests caught more API drift than the E2E ever did."

The senior signal: framing the choice as "what specific tests, at what cost, for what risk reduction" rather than as "coverage vs speed" generally.