Test against a real database in a container rather than mocking the data layer, because most bugs live in queries, migrations and transactions that a mock cannot express. For external APIs, mock at the transport boundary with recorded or stubbed HTTP responses so your own client code is exercised, and add a small set of contract tests against the real service to catch drift. Keep tests isolated with per test transactions or fresh schemas.
Why interviewers ask this
The interviewer wants to know whether your tests would actually catch a regression. Mocking the repository layer produces suites that pass while production breaks, so they are listening for real database testing, boundary level HTTP stubs and a plan for detecting when a third party changes. Speed and isolation matter too, since a slow or flaky suite gets skipped no matter how thorough it is.
How to structure your answer
- State the principle: mock at the process boundary, not inside your own code.
- Use a real database in a container and explain isolation between tests.
- Handle third party APIs with stubbed transport plus contract checks.
- Address speed and flakiness so people keep running the suite.
Example answer
My rule is to mock at the edge of my process and not inside it. So the database is real, running in a container with the same engine and version as production, and migrations are applied at the start of the run, which means the migration itself gets tested every time. Each test runs in a transaction that is rolled back, or gets its own schema when it needs to commit, so tests stay isolated and can run in parallel. Mocking the repository would give me green tests that prove nothing, since the bugs I actually ship are in queries, constraints and transaction boundaries. For an external API I stub at the HTTP layer with recorded responses, so my client, my retry logic and my parsing all run for real; I just do not hit the network. Since recordings drift, I also run a small contract suite against their sandbox on a schedule, not on every pull request, so I hear about a change from a failing job rather than from an alert at three in the morning.
Walking into this interview soon? GhostPilot listens to your live call, spots the question the moment it is asked, and puts a structured answer on your screen in real time. Try it on your next mock, or grab a $29 Session Pass, no subscription, for the real thing.
See how it worksFollow-up questions to expect
- How do you keep the suite fast once you have a real database?
- How do you test a failure mode like a timeout from that API?
- What do you do about tests that depend on time or ordering?
Related backend developer questions
Your interviewer will ask their own version of this. Paste your actual job description into the free Question Predictor and get the 20 questions that role is most likely to ask, with what each one is really probing.
Predict my questions