what deserves a test, what does not, and how you know the suite is telling you the truth. Coverage percentages answer none of that.
Written after an answer that was a number and nothing else. Updated October 2026. 7 min read
Where the tests should live
end to end, few
integration
unit, many and fast
WHAT THEY ASK
what would you test here?
what would you not test?
how do you test the failure?
what makes a test flaky?
The short version: say what you would test and what you deliberately would not, put most tests at the fast end, test the failure paths rather than only the happy one, and have an opinion about flaky tests. A candidate who can say what is not worth testing sounds far more experienced than one quoting coverage.
Team practices vary widely. Defend your own with reasons rather than rules.
The number that answered nothing
"Our coverage was around eighty percent."
It was true and it told the interviewer nothing. Coverage measures which lines ran, not whether anything was checked. The follow up, which I had no answer for, was simple: which part of that system were you most afraid of, and what did you do about it.
Coverage says what was executed. The interview is about what was verified.
What to say instead
Risk first, shape second.
1
Name the risk
Which part would
hurt most if it
broke quietly?
2
Pick the level
Unit for logic,
integration for
wiring, end to end
sparingly.
3
Test the failure
Timeouts, bad input,
partial writes.
4
Keep it honest
Delete tests that
never fail and fix
ones that fail
randomly.
Four moves that turn a coverage answer into a judgement answer.
What not to test
The part that signals experience.
Usually worth testing
Business rules and edge cases
Data transformations
Error and retry paths
Anything that has broken before
Usually not worth it
Framework behaviour
Simple getters and setters
Exact log strings
Private methods through reflection
Flaky tests are a trust problem
Say that out loud.
One test that fails randomly teaches an entire team to rerun the pipeline without reading it. That habit then hides a real failure. Quarantine first so trust survives, then fix the cause, which is nearly always time, test ordering or shared state between tests.
Testing the failure path
The question candidates skip.
Timeouts
What does your code do when the dependency never answers?
Partial writes
Half the batch succeeded. Is that state recoverable?
Bad input
Not just invalid, but plausible and wrong.
Retries
Does retrying twice produce two of something?
If your current team has no tests
Answer honestly and move to the plan.
Saying that your team ships without tests, followed by which single path you would cover first and why, reads far better than inventing a culture you did not have. Interviewers are mostly checking whether you have an opinion and whether you would improve things without demanding a rewrite.
How I practised the discussion
Out loud, on real code.
I took functions from my own projects and talked through what I would test and skip, with a timer. For the rest of the loop, the algorithm round and the behavioral round, I used Phantom Code AI[https://www.phantomcodeai.com/] nightly, attempting first and comparing second. Having coding, system design, SQL and behavioral practice in one place meant the craft discussions above were the only thing I had to rehearse separately.
Common questions
Short answers.
Unit versus integration?
Is high coverage a good goal?
How do you handle flaky tests?
What if your job has no tests?
Have an opinion, not a percentage
The strongest testing answers I have heard were specific about what the person chose not to test. That is the sentence that separates judgement from compliance.
Take one function you wrote this week and say out loud what deserves a test and what does not.
Written after learning that eighty percent is not an answer
What is the most useful test you ever wrote?
Mine caught a timezone bug that would have been invisible.
Top comments (1)
I'd be careful with "delete tests that never fail." A stable test guarding a critical invariant can stay green for years and still earn its place. I'd first deliberately break the behavior it protects and check that the test catches it. That separates a healthy regression test from one whose assertions don't matter.