The "It Works on My Machine" Killer
The primary goal of a hermetic build is determinism: given the exact same set of declared inputs, the build always produces the exact same bit-for-bit output, regardless of the machine, the time of day, or the user running it.
This property has profound practical consequences:
- Reproducible failures: If a build fails in CI, you can reproduce it locally with certainty. You are not chasing phantom environment differences.
- Trusted artifacts: You know for a fact that the binary running in production is exactly the binary that passed your test suite. There is no "well, the CI build was slightly different" ambiguity.
- Safe caching: Because the same inputs always produce the same outputs, you can safely cache build outputs and reuse them. This is the foundation of remote caching, covered in a later section.
What Breaks Determinism
Common sources of non-determinism that hermetic build systems guard against include: reading the system clock (date, time.Now()), embedding the build machine's hostname, iterating over hash maps in languages where map ordering is randomized, and downloading dependencies from the internet at build time (where the remote package might have changed). A well-configured hermetic build system either forbids these actions outright or requires them to be explicitly declared and pinned.
Interviewers at companies with large monorepos (Google, Meta, Stripe, Uber) frequently ask: "What does it mean for a build to be hermetic, and why does it matter?" A strong answer connects hermeticity to three outcomes: reproducibility (same inputs → same outputs), safe caching (outputs can be reused without fear of staleness), and debuggability (CI failures are locally reproducible). Avoid defining it purely as "isolated" — explain what it is isolated from and why that isolation is valuable.