Hard to test means the design is wrong

Ask a candidate how they approach testing a feature and most of them describe tools. Which framework, what the coverage number is, how they mock.

The answer that scores starts somewhere else: testing is an architecture question, and hard-to-test code is a design problem rather than a testing problem.

Say that early and it sets the level for the whole round.

Here is what it means concretely.

If a view model cannot be tested without a running server, it does not have a testing problem. It has the wrong dependencies, and the fix is to inject the boundary as a protocol rather than to write a more elaborate mock.

If logic can only be tested through the UI, the logic is in the wrong layer. Pull the decision into a pure function and the test becomes trivial.

If a test is flaky, something in the system is non-deterministic and you have not found it yet. The flakiness is information, not noise.

The follow-up that comes next, almost always. They will show you something hard to test and ask how you would fix it. The weak answer is add more mocks. The strong answer is that hard to test means the design is off, name the boundary, and the test writes itself.

Two more opinions worth having ready , because a testing round will look for them.

Roughly seventy, twenty, ten across unit, integration and UI. The failure mode has a name: the inverted pyramid, where slow brittle UI tests compensate for architecture nobody wanted to fix.

And coverage measures lines executed, not risk retired. A suite people disable is worse than a smaller suite people trust. If someone asks what your coverage is, the strong answer names what you deliberately do not test and why.

None of that is about knowing a framework. All of it is about having thought about the question before someone asked it in a room.