Resume deep dive: CI/CD pipelines, test automation and the practices behind them

One round began with a deep dive into your resume that focused on automation and CI/CD. The interviewer tested how well you understand CI/CD concepts and which engineering practices you follow when you build and run delivery pipelines. Use a service you have worked on, or a realistic backend service if you prefer, and answer both parts. ### Clarifying Questions - Does the interviewer want the pipeline you actually built, or general principles illustrated with it? - What kind of system is it: a single service, many services in one repository, or something with a slower release train such as a mobile app? - How often does the team deploy today, and are there compliance requirements such as mandatory approvals or audit trails? ### Part 1 — From commit to production Walk the interviewer through what happens to a change from the moment a developer pushes it until it is serving production traffic. Name each stage and what it checks or produces, say which failures block a merge and which block a deployment, and explain how the change is rolled out and, if needed, rolled back. ```hint Follow one artifact Track a single build output through every environment and ask whether anything gets rebuilt along the way. ``` #### What This Part Should Cover - Concrete stages from commit to production and the purpose of each - Which gates run before merge and which run before or during deployment - Building an artifact once and promoting that same artifact across environments - Progressive rollout with automated health signals and a fast rollback path ### Part 2 — The practices you follow and why Explain the practices you insist on when implementing and running pipelines, and defend each one. Be ready for the interviewer to press on the hard cases: unreliable tests, slow pipelines, database schema changes, and secrets and configuration. ```hint Every practice needs a failure it prevents For each habit you name, be ready to say what goes wrong without it, ideally with an example from your own work. ``` #### What This Part Should Cover - Specific practices, each tied to the problem it prevents - How you deal with flaky tests and with pipelines that are too slow - Safe handling of schema changes, secrets and environment configuration - The measures you use to judge whether delivery is healthy ### What a Strong Answer Covers - Correct, precise use of continuous integration, continuous delivery and continuous deployment - Clear ownership: what you personally built or changed, and the measurable result - Explicit trade-offs between delivery speed and safety - What happens when a bad change gets through anyway, and what the team learns from it ### Follow-up Questions - Your pipeline takes 45 minutes and developers have started batching changes to avoid it. What do you do? - A deployment passed every check but caused errors in production. Walk through what happens next and what you change afterwards. - How would you roll out a breaking database schema change with zero downtime? - How do you decide what belongs in unit, integration and end-to-end tests?