A monorepo's pipeline takes 55 minutes because every commit builds and tests everything. Developers batch changes to avoid it. How do you fix it?

What the interviewer is testing

Whether you recognise the second-order damage — batching — and whether you know the specific techniques rather than proposing more machines.

Why this matters more than the 55 minutes

Developers batching changes to avoid the pipeline is the real cost. Larger batches mean harder reviews, harder diagnosis when something breaks, and higher change failure rate. The slow pipeline has quietly reversed the practice it was meant to support.

The techniques, in order of leverage

Affected-target detection. Build and test only what the change can affect, derived from the dependency graph. A change to one library runs its tests and its dependents' tests, not the estate's. This is the single largest win and is what monorepo build tools exist to provide.

Remote caching. If a target's inputs are unchanged, reuse the previous result rather than recomputing. Shared across the team and CI, so a target built by anyone is not rebuilt by everyone. Requires hermetic, deterministic builds — which is the prerequisite people underestimate.

Test tiering. Fast unit tests on every commit as a blocking gate; slower integration and end-to-end suites on merge to trunk or on a schedule, with a clear policy for what happens when a post-merge suite fails.

Parallelism and sharding for what remains, which is the least interesting lever and the one teams reach for first.

Merge queues so trunk is verified without every author waiting for a full serial run.

The target to state

Under 10 minutes for the blocking feedback loop. That is roughly the boundary at which developers wait for the result instead of switching context, and it is worth optimising towards explicitly rather than aiming vaguely at "faster".

What a strong answer adds

Instrumenting the pipeline to find where the time actually goes before optimising — it is frequently dominated by dependency installation, container image pulls or environment setup rather than by the tests themselves, and those have different fixes.

And noting the flakiness interaction: a 55-minute pipeline with a flaky test is far worse than the runtime suggests, because each re-run costs another 55 minutes and the team's willingness to trust red collapses.

Common weak answers

Adding build agents, which buys a linear improvement against a structural problem. Splitting the monorepo, which is a large change that addresses the symptom.