What they're testing
Whether you think about the maintenance cost of tests, or only about writing them.
The short answer~30 seconds
The higher you go, the slower, flakier and more expensive to fix tests get — hence many unit tests at the base, fewer integration tests in the middle, very few end-to-end ones on top. I agree on cost and disagree with applying it mechanically: a test's value lies in catching real bugs, and in some systems nearly every real bug lives where components MEET — in which case the integration tier deserves most of the effort.
The long answer
The trap in following the pyramid too strictly is that you can reach high unit coverage and still break in production, because everything is mocked. Testing a service against a mocked repository proves the service calls the right method, not that the SQL underneath works. Which is why integration tests against a real database (Testcontainers or similar) often deliver more confidence per hour than more unit tests.
An alternative shape worth knowing is the "testing trophy": fewer unit tests, more integration tests, with static typing as the base. The argument is that TypeScript and a linter already catch the class of mistakes many trivial unit tests catch — wrong argument types, missing fields — so re-encoding them as tests pays twice.
What they'll ask next
?What should end-to-end tests cover?
The few most business-critical journeys — signup, checkout — not every screen. The goal is detecting "the whole assembly still works", and three to five tests achieve that; thirty and you spend your time fixing flakes instead of building features.
These lose points
- Mandating 100% coverage. It rewards testing getters and skipping the hard branches — precisely where bugs live.