Senior · Modules and tooling
Build reproducibility and resource budgets
Why does go test ./... fail only under a small CI container?
Try explaining this aloud before opening the answer. State your assumptions and trace a boundary case.
Reveal a strong answer
Compilation and test execution both consume memory, processes and CPU. Package build parallelism, test parallelism and each test's own worker count are separate multipliers.
Inspect the actual failure: OOM kill, timeout, missing native library, unavailable network or flaky shared fixture need different fixes. Caches improve speed but should not be required for correctness.
Pin toolchain and dependencies, validate platform/build tags, bound concurrency and retain useful logs. Reproducible source inputs do not automatically guarantee bit-identical binaries unless paths, flags, generated artifacts and other inputs are controlled.
Common trap
Increasing the timeout cannot recover a process that the kernel killed for exceeding memory.
Try it
A test suite runs8 packages ×8 paralleltests ×16 workers. How should you approach its load?
Worked solution
Treat the combined concurrency as a budget, not three independent defaults. Measure peak memory and dependency demand, then cap the appropriate layers and isolate heavy integration tests. Do not suppress failing cases to make the build green.
Change the constraint
Which evidence would you retain to distinguish a compile OOM from a test-process OOM?
How did you do?
Self-assessment, not a compiler pass or interview score. Explain the reasoning unaided before marking understood.
Not marked. Progress stays on this browser, separate from course completion.
Primary references
Checked 2026-10-20. Use documentation for your pinned runtime, driver and tool version.