Developers cannot run the system locally — one service needs twelve dependencies. The inner loop is now "push and wait eight minutes". How do you fix it?

What the interviewer is testing

Whether you recognise the compounding cost of a broken inner loop, and whether your fixes are architectural rather than tooling.

Why this matters more than it appears

The inner loop runs dozens of times per hour per engineer. An eight-minute cycle does not cost eight minutes; it costs a context switch, and the developer starts doing something else, which is where the real productivity loss lives.

It also degrades quality: when verification is expensive, people verify less and batch more.

The fixes, in order of leverage

Run one service against contract-based stubs. The service under change runs locally; its dependencies are replaced by stubs generated from verified contracts rather than hand-written mocks. Because the stubs derive from contracts the providers verify in their own pipelines, the isolation stays trustworthy — which is the property that hand-written mocks lack.

Containerised real dependencies for the ones that matter. A real database and message broker started locally is cheap now and catches the large class of defects living in queries, migrations, transactions and serialisation. Using an in-memory substitute for the database is hard to justify today.

A shared remote dependency tier for services genuinely too heavy to run locally, with the local service pointed at it.

Faster feedback within the loop: hot reload, incremental compilation, and running only the tests affected by the change.

The architectural read

Needing twelve dependencies to do anything is usually a boundary problem. If most changes require coordinating across services, the boundaries are in the wrong place, and the local development pain is a symptom of coupling that also shows up as release coordination and cross-team dependencies.

What a strong answer adds

Measuring the inner loop explicitly — time from code change to observing the effect — and treating a target of under 30 seconds for the common case as a platform objective.

Common weak answers

Faster CI, which optimises the outer loop and leaves the inner loop broken. Docker Compose with every service, which is slow, fragile and drifts from production.