TL;DR: Measure commit-to-feedback time, including queueing and retries, then shorten the critical path. Investigate distrust separately: intermittent failures, misleading green runs and unreadable diagnostics need different fixes. Preserve required coverage while changing how work is scheduled.
How to approach it
Ask what the 45 minutes includes. A developer may count the wait for a runner, two failed attempts and a successful rerun, while the CI dashboard reports only the final execution. Compare individual runs with the job dependency graph before deciding which optimisation to try.
A strong answer
Collect timestamps for queue entry, runner assignment, setup, each job and final feedback. Segment runs by change type and cold versus warm cache. Track median and tail latency, but inspect complete traces: adding the p95 durations of different stages does not produce a valid p95 for the whole pipeline.
Worked example: where the 45 minutes go
Assume a fictional run has this measured sequence:
| Work | Duration | Dependency |
|---|---|---|
| Runner queue | 8 minutes | Before execution |
| Checkout and dependency setup | 5 minutes | Before checks |
| Lint | 2 minutes | Needs setup |
| Unit tests | 10 minutes | Needs setup |
| Integration tests | 16 minutes | Needs setup and isolated test environment |
| Package artifact | 4 minutes | Waits for all required checks |
These jobs currently run serially: 8 + 5 + 2 + 10 + 16 + 4 = 45 minutes. If lint, unit and integration checks can safely run concurrently with no extra setup or queue delay, the estimate becomes 8 + 5 + max(2, 10, 16) + 4 = 33 minutes. That assumption needs a trial: separate jobs may each provision a runner and repeat setup.
Reducing queue time from eight to one minute would bring this example to 26 minutes. Splitting the integration suite into two balanced, isolated eight-minute shards would make unit tests the longest check, producing 1 + 5 + max(2, 10, 8) + 4 = 20 minutes before sharding overhead. More integration shards would give little benefit until the next bottleneck changes. This is the critical path: the longest chain of dependent work that determines completion.
I would first test the least invasive change supported by those observations. Runner queueing needs a capacity or scheduling investigation; adding CPU to an already-running job does not shorten its wait. Record the runner-minute cost as well as elapsed time, because parallel jobs may finish sooner while consuming more compute.
Caching can reduce repeated work. Include the relevant toolchain, operating system, architecture and dependency inputs in cache identity. A cache hit must still yield a valid build. Separate untrusted pull-request cache writes from trusted release inputs, and retain a cold-build check so a warm cache does not conceal missing dependencies. Promote the tested artifact rather than rebuilding it after checks.
Affected-target selection can avoid unrelated tests, but it needs a dependency graph that includes shared configuration and generated inputs. Compare selected checks against broader runs and investigate missed dependencies. Keep a conservative fallback when the graph is uncertain.
Restore confidence in the result
Read recent failures with the developers. Did a test pass on rerun because of a timing race, an unavailable test service, or a real failure that only occurs with certain data? A rerun alone cannot distinguish these. Retain the first failure and classify it instead of allowing the final green run to erase the evidence.
Quarantine a flaky test only with an owner, a repair date and visible reporting. If it protects a high-risk path, provide a reliable replacement check or document an explicit temporary risk decision. Also inspect successful runs: skipped checks, stale artifacts and branch filters can make a green result misleading.
What interviewers probe next
"What should run first?" Cheap checks with useful failure messages can provide early feedback while slower independent work runs. If they frequently reject changes, waiting for them before starting expensive jobs may reduce wasted compute. Measure the feedback and cost tradeoff instead of enforcing one ordering everywhere.
"What about tests sharing a database?" Isolate schemas, databases or test accounts if the system supports that reliably. Include unique identifiers for external resources. If isolation is impractical, retain the necessary serial section and optimise elsewhere; parallel interference would damage both speed and confidence.
"How do you prove the improvement lasts?" Compare commit-to-first-useful-failure and commit-to-accepted-artifact latency over comparable changes, plus queue time, rerun rate and cost. Track missing checks and escaped defects as well. Choose a feedback budget with the team and investigate regressions against it.
Common mistakes
Summing every job duration after parallelisation. Elapsed time follows dependencies; billed compute can still accumulate across all runners.
Removing slow checks without identifying the risk they cover. Move a check only when another stage provides the required assurance before the relevant release boundary.
Treating cache availability as build correctness. A cold runner should be able to produce the required output from declared inputs.