How do you design a CI/CD pipeline from scratch for a new project?

I start by understanding what the team needs to ship safely and quickly, not by picking tools first. I map out the stages the code needs to pass through: build, test, security scan, package, deploy to staging, and promote to production. I automate each stage and define clear promotion criteria so nothing moves forward without meeting quality gates. For a typical project I would use something like GitHub Actions or GitLab CI for the pipeline itself, with containerised builds to keep environments consistent. I include automated unit and integration tests early in the pipeline so failures surface fast and cheaply. I also build in security scanning at the image and dependency level rather than treating it as a post-deployment concern. The goal is to make every commit to the main branch deployable. I treat the pipeline as code and version it alongside the application.

How do you approach infrastructure as code and what tools do you prefer?

I treat infrastructure as code as a first principle, not an optimisation. If infrastructure is not in version control, it cannot be reviewed, tested, or reliably reproduced. My preferred tool for cloud-agnostic infrastructure is Terraform because of its declarative syntax, provider ecosystem, and strong community. For configuration management I use Ansible when I need to manage state on existing machines, and for Kubernetes I use Helm for packaging and ArgoCD for GitOps-style delivery. I organise Terraform into modules by domain, which keeps things composable and reusable across environments. I also enforce a plan before apply workflow in CI so infrastructure changes get reviewed like code changes.

How do you think about monitoring and observability for a production system?

I think about observability in terms of the three pillars: metrics, logs, and traces. Metrics tell you something is wrong, logs tell you what happened, and traces tell you where in a distributed system the problem originated. My standard approach is to instrument applications with structured logging from the start, export metrics to a time-series database like Prometheus, and use distributed tracing with something like OpenTelemetry to understand request flows. I build dashboards that reflect the four golden signals: latency, traffic, errors, and saturation. I also configure alerts on symptoms that matter to users rather than on low-level resource thresholds. The test I use for any alert is: if this fires at 3am, is it worth waking someone up? If not, it should be a warning, not a page.

Tell me about a significant production incident you handled. What was your role and what did you learn?

We had a database connection pool exhaustion that took down our primary service for 35 minutes on a weekday afternoon. I was on call and took incident command. My first step was to declare the incident formally, open a dedicated communication channel, and page the relevant engineers without flooding the channel with noise. I kept the internal and external communications separate and gave our head of engineering a short factual update every 10 minutes. The immediate mitigation was a restart and a connection pool limit increase, which restored service in 12 minutes. The root cause was a recent background job with a missing connection release under an error condition. The process change was adding a connection pool metric to our core dashboard and a circuit breaker test to our pre-production load tests.

Describe a time you improved deployment frequency or reduced deployment risk.

When I joined my previous team, production deployments happened once a week on Friday afternoons and required a 30-minute manual runbook. I built a fully automated pipeline with automated smoke tests, blue-green deployment on our Kubernetes cluster, and automatic rollback if smoke tests failed. Within two months we were deploying multiple times a day with no manual steps and a mean time to recover from a bad deploy of under four minutes. Deployment frequency is one of the DORA metrics, and improving it directly correlated with a reduction in change failure rate because smaller, more frequent changes are easier to diagnose and roll back.

Give me an example of how you have influenced engineering culture around operational practices.

When I joined a start-up with no on-call process, I introduced a lightweight on-call rotation and a simple incident response template. I ran a blameless post-mortem after the first significant incident and explicitly recognised the engineer who had surfaced a design flaw honestly. Over the following quarter I ran three internal learning sessions on SRE principles, each under 30 minutes, and published an operational readiness checklist for new services. By the end of the year every team had an on-call rotation, incident response times had improved, and engineers were voluntarily running post-mortems on near-misses. The change was gradual and practical.

How do you manage secrets and sensitive configuration in a cloud-native environment?

I never store secrets in environment variables hardcoded into deployment manifests or source code, and I never commit them to version control. My preferred approach in a Kubernetes environment is to use a secrets management tool like HashiCorp Vault or AWS Secrets Manager, with the application retrieving secrets at runtime via a sidecar or init container. I rotate secrets regularly and automate rotation where the provider supports it. For CI/CD pipelines I use the secrets management built into the platform. I also follow the principle of least privilege for all service accounts: each service should only be able to read the specific secrets it needs.

How do you approach container and Kubernetes security?

Container security starts at the image level. I use minimal base images, scan images in CI for known vulnerabilities using a tool like Trivy or Snyk, and enforce a policy that blocks deployment of images above a severity threshold. In Kubernetes I apply network policies to restrict traffic between pods, use RBAC to limit what service accounts can do, and run pods as non-root users with read-only root filesystems where possible. I use admission controllers to enforce policies at the cluster level. For secrets I use a dedicated secrets store rather than Kubernetes Secrets, which are only base64-encoded unless you configure encryption at rest.

How do you approach capacity planning and cost optimisation in a cloud environment?

I start with visibility: you cannot optimise what you cannot see. I set up cost dashboards that break down spend by team, service, and environment. For right-sizing, I look at actual resource utilisation over a 30-day window before making changes. I use horizontal autoscaling for stateless workloads and reserved or committed use discounts for predictable baseline load. I also schedule non-production environments to shut down outside working hours. For storage I enforce lifecycle policies to move infrequently accessed data to cheaper tiers automatically. Engineers who understand that cloud costs are real make better architectural decisions.

DevOps Engineer

DevOps Engineer interviews test your ability to bridge development and operations, automate infrastructure, and build reliable systems at scale. Interviewers want to see hands-on experience with CI/CD pipelines, cloud platforms, and incident management, alongside a culture-first mindset that enables fast, safe delivery. This guide covers the questions asked most often and the answers that land offers.

For general interview preparation tips, read our guide to common interview questions.

Common DevOps Engineer Interview Questions

Behavioural Interview Questions for DevOps Engineer Roles

Technical Questions for DevOps Engineer Candidates

What Hiring Managers Look for in DevOps Engineer Interviews

What hiring managers really look for in DevOps Engineer candidates:

Real production experience. War stories about incidents, outages, and migrations are more valuable than any certification.
Systems thinking. The best DevOps engineers understand how everything connects: code, infrastructure, monitoring, security, and cost all interact.
Communication skills. DevOps engineers sit at the intersection of development and operations. The ability to translate between the two is as important as technical depth.
Security-first instincts. Candidates who treat security as an add-on rather than a foundation raise red flags at most mature organisations.
Culture contribution. Ask yourself whether this person will help the team deploy more safely and learn from failures, not just whether they know Terraform.

Questions to Ask Your Interviewer

→What does the current CI/CD setup look like and what are the biggest friction points in the deployment process?
→How is on-call structured and how many incidents has the team dealt with in the last three months?
→What is the balance between building new tooling and maintaining existing infrastructure?
→How does the team approach post-mortems and learning from incidents?
→What cloud platforms and major infrastructure components will I be working with?

Practise These Questions Before Your Interview

The mock interview tool builds a practice session around a specific job posting and your background, so you rehearse the questions most likely to come up.

Start Practising

Free during beta. No commitment.

Related Roles

Software Engineer

Tech9 questions

Cybersecurity Specialist

Tech9 questions

Data Scientist

Tech9 questions