Explain the test pyramid and when you might deviate from it.

Mike Cohn's test pyramid argues for cost-and-speed-driven distribution: lots of unit tests at the base (fast, cheap, isolated), fewer integration tests in the middle (slower, broader), and a small E2E layer at the top (slowest, most brittle, but highest confidence). The intuition is sound — feedback latency and flake rate scale up the higher you go.

Real systems force compromises. A microservice with thin business logic and heavy I/O often has a "diamond" or "trophy" shape — most value comes from contract and integration tests because there's barely any pure logic to unit test. Conversely, a critical algorithmic core (pricing engine, fraud scoring) might justify a much wider unit base than the pyramid suggests. Front-end-heavy applications with rich client state often need more component-level integration tests than the original pyramid imagined.

The honest answer in an interview: the pyramid is a heuristic, not a rule. The right shape is the one that gives your team the fastest, most reliable signal at acceptable cost. Anti-patterns to call out are the inverted pyramid (mostly E2E — flaky and slow) and the ice cream cone (heavy E2E plus heavy manual — usually a sign of weak unit-level seams).