Lesson 18 · Senior testing practice

Senior testing interview questions

High-signal questions about test strategy, seams, flakiness, doubles, and review judgment — with answer shapes that sound like real engineering maturity.

Your win: answer senior testing questions with model + trade-off + repo-grounded consequence, not just generic TDD slogans.

In plain English Plain English: strong testing answers explain what a test is trying to prove, why that layer was chosen, and what kind of false confidence the design avoids.

Why these questions feel different

Junior questions often ask how to write tests. Senior questions often ask how to choose them, review them, and decide what they are really proving. That is why short slogan answers usually sound weak here.

The stronger answer shape is closer to the stronger lesson style in the rest of this course: start with the model, make the trade-off explicit, then connect it back to a concrete repo consequence. That rhythm makes the answer sound like judgment instead of memorization.

The answer recipe Start with the testing model, name the trade-off or risk, then finish with the repo-grounded consequence.

How to use this page well

Do not treat this table like a glossary. Use it like a speaking drill. Read a question, cover the right column, answer out loud, then compare your answer shape with the model.

The point is not to memorize exact wording. The point is to train your answers to sound structured, practical, and grounded in how this repo actually tests code.

Question bank

Question	Best answer shape
What makes a unit test valuable in this repo?	It isolates one unit, proves a real behavior, stays deterministic, and catches bugs at the cheapest reliable layer.
Why does the repo push `t.Parallel()` and fresh suites?	Because repeated runs and concurrency expose hidden shared state; the structure is an anti-flake design decision.
How do you choose between mocks and `testutil.MockDB`?	Use mocks for orchestration and behavior expectations; use `MockDB` when repository scan/query behavior needs stronger proof without a real database.
What does `-count=3` really protect against?	Tests that only pass once by accident because of ordering, timing, or shared mutable state.
How does testability relate to design quality?	Clear seams and narrow responsibilities make honest unit tests easier; painful tests often reveal broader design issues.
What makes a mock expectation brittle?	When it overfits incidental implementation detail instead of the behavior the test actually needs to prove.
What is the main blind spot of high coverage numbers?	They can look green while missing important error paths or weak assertions.
How do you review a test like a senior engineer?	Ask what behavior it proves, what it leaves unproven, and whether it could give false confidence through brittle or weak checks.
Why regenerate mocks after an interface change?	Because generated mocks are part of the compilation truth; stale mocks make tests and builds lie about the current seam.
What is the real value of the testing pyramid?	It helps choose the cheapest reliable layer for each bug class rather than defaulting to realism or habit.

Backend use case The strongest answers name concrete repo facts like newSuite, AssertExpectationsForObjects, the two generators, testutil.MockDB, and -count=3 instead of staying purely theoretical.

Use the playbook and repo map together

The playbook compresses the senior lessons; the repo map gives you the source anchors that make your answer sound grounded.

→ Senior backend playbook
→ Repo testing map

Check yourself (from memory)

Q1. A strong senior testing answer usually includes…

That structure makes the answer sound like engineering judgment rather than testing slogans.

What are the three ingredients of a strong senior testing answer?

recall, then click to reveal

A clear testing model, the important trade-off or risk, and a repo-grounded consequence or example.

When you’re ready, do not just reread this page — go run the mock pack out loud. Ask me if you want me to conduct it live.

Sources. Repo playbook and repo testing map.