Practice build system vocabulary: targets, dependency graphs, cache keys, incremental builds, hermetic builds, cache hit/miss, and deterministic build concepts from Bazel, Gradle, and Make.
0 / 5 completed
1 / 5
What is a 'hermetic build' in build system terminology?
A hermetic build is fully self-contained and isolated. It does not read from the host filesystem or environment beyond what is declared. This enables reproducibility: the same input always produces the same output, anywhere.
2 / 5
A team celebrates a 'cache hit' in their build pipeline. What happened?
A cache hit means the build system found a stored result for the current set of inputs (the cache key) and reused it. This avoids redundant recompilation, making incremental builds dramatically faster.
3 / 5
What is a 'cache key' in a build system?
A cache key is typically a hash of all inputs to a build target — source files, compiler version, flags, and dependencies. If any input changes, the hash changes, triggering a rebuild. Identical keys mean the cached output can be reused.
4 / 5
What is an 'incremental build'?
An incremental build leverages the dependency graph and cached results to skip targets whose inputs haven't changed. This is the primary mechanism for fast developer iteration — only changed code and its dependents are rebuilt.
5 / 5
A colleague says 'the build is deterministic.' What does this guarantee?
A deterministic build produces identical binary output for identical inputs — the same source code, same compiler, same flags always yield the same artifacts. This is essential for reproducibility, security auditing, and trusting remote cache results.