What are build artefacts and why version them?
Assesses fundamental understanding of CI/CD conventions, runtime behavior, and memory/performance considerations.
Hiring managers look for precision, avoidance of ambiguous jargon, and ability to explain trade-offs under real production conditions.
A build artefact is the immutable output of a build: a container image, JAR, binary, or package. Versioning means each artefact has a unique, traceable identifier.
Why:
- Reproducibility: you can redeploy exactly the bits that were tested instead of rebuilding and hoping.
- Traceability: a tag tied to a commit and pipeline run lets you find what changed and who made it.
- Rollback: redeploying a previous artefact is fast and reliable.
- Promotion: build once, then move the same artefact through staging and production. Rebuilding per environment risks differences.
Practices:
- Tag with the commit SHA plus a semantic version.
- Store in a registry or artefact repository with retention policies.
- Sign and scan artefacts for supply-chain security.
- Never overwrite a released tag; immutability is the point.
docker build -t registry.example.com/api:$(git rev-parse --short HEAD) .
docker push registry.example.com/api:$(git rev-parse --short HEAD)
Avoid building on production hosts.
Candidate Response Strategy & Interview Tips
- Start with a concise one-sentence summary: Deliver a direct, confident answer first before expanding into nuances.
- Demonstrate real-world trade-offs: Discuss where this approach excels and when you would avoid it in production systems.
- Discuss complexity & edge cases: Proactively explain time/space complexity or boundary conditions (null values, scale limits).
- Prepare for interviewer follow-ups: Technical hiring panels frequently probe deeper into concurrency, backward compatibility, or alternative libraries.