Continuous Integration and Build Automation
What to know
Continuous integration means every change integrates to trunk frequently and triggers an automated build and test pipeline. Candidates must understand pipeline stages (checkout, dependency resolution, compile, unit test, static analysis, package, publish artifact), build reproducibility (pinned dependencies, lockfiles, deterministic toolchains), and artifact immutability-build once, promote the same artifact through environments. Know caching strategies (dependency caches, layer caches), parallelism and test sharding, and flaky test management (quarantine, retry with reporting, root-cause fixes). Understand build agents/runners, ephemeral vs. persistent executors, and secrets injection at runtime rather than baking them into images.
Traps
A frequent distractor is rebuilding the artifact per environment-this breaks provenance and is wrong for CD. Another is using latest tags or unpinned base images, which destroys reproducibility. Questions may confuse continuous integration with continuous delivery: CI is the practice of integrating and verifying; CD extends to releasable/deployed states. Also watch for retry-everything answers: blind retries mask flaky tests and hide real failures.
Rule of thumb
A pipeline should fail fast and fail loudly. Order stages cheapest-first (lint, unit tests) before expensive integration and end-to-end suites. Keep pipelines under roughly ten minutes to the first meaningful signal; beyond that, developers context-switch and bypass checks.
Worked example
A build takes 40 minutes, mostly reinstalling dependencies. Fixes: cache the dependency directory keyed by lockfile hash, shard the test suite across parallel runners, and run static analysis concurrently with unit tests. Rebuilding from scratch on every run is not a fix-it is the problem.