DevOps engineers are judged on the days things go wrong: the pipeline that fails twenty minutes before a release, the node that runs out of disk, the 2 a.m. page that turns out to be noise. Interviews reflect that, leaning on troubleshooting and judgement more than tool trivia. Learn what the work involves and which of four overlapping titles a posting really means, and your preparation can match the panel in front of you.

What DevOps engineers do between deploys

Picture a week on a product company's DevOps team:

  • reviewing a new service's Helm chart and sending it back because it has no resource limits or readiness probe;
  • moving a team's pipeline from long-lived cloud access keys to short-lived credentials through OIDC federation;
  • finding out why builds got twice as slow: a changed cache key means every job downloads its dependencies from scratch;
  • applying a Terraform change for a database read replica after reading the plan line by line;
  • a primary on-call shift: one real incident (an expired certificate on an internal endpoint) and three alerts that should never have paged anyone.

The common thread: you own the path from a developer's commit to a running, observable service, and you make that path safer and faster for everyone else. A backend developer writes the service; you make it build, deploy, scale and recover, which means reading application code well enough to tell an app bug from an infrastructure one.

Indian postings spread this work across four overlapping titles:

TitleWhat the work usually centres onSignals in the posting
DevOps engineerPipelines, infrastructure as code, containers, the release process, often cloud operationsJenkins or GitHub Actions, Terraform, Docker, Kubernetes, "build and release"
Site reliability engineerProduction reliability: SLOs, error budgets, incidents, capacity, automation in codeSLOs, on-call, Go or Python, Linux internals, "toil"
Platform engineerAn internal platform other teams self-serve from: templates, golden paths, developer portalsInternal developer platform, Backstage, Kubernetes operators, developer experience
Cloud engineerCloud architecture and operations: networks, IAM, landing zones, migrations, costAWS, Azure or GCP certifications, VPCs, IAM, FinOps

Judge a posting by its responsibilities rather than its title: a services firm's "DevOps engineer" may spend most days on cloud operations, while a startup's "SRE" may mostly maintain CI.

Skills panels test, from the shell upwards

AreaWhat good looks likeWhy panels care
LinuxRead processes, memory, disk and logs (top, free, df, journalctl); manage systemd services and permissionsContainers and cloud VMs still fail like Linux machines
ScriptingBash for glue, Python once logic outgrows a screen; parse logs, call APIsMany panels ask for a script written live
NetworkingDNS, TCP, HTTP, TLS, load balancers, subnets, routes, security groups"It's the network" is the hardest claim to prove or rule out quickly
CI/CDPipelines in Jenkins, GitHub Actions, GitLab CI or Azure DevOps, with caching, secrets and promotion between environmentsIt is usually the first thing you will own
Infrastructure as codeReusable modules, remote state with locking and careful plan reading in Terraform or OpenTofu; Ansible for configurationEvery change becomes reviewable and repeatable
Containers and KubernetesSmall, non-root images; Deployments, Services, Ingress, probes, requests and limits; HelmProbes, limits and image tags are where many failed deployments start
Observability and incidentsPrometheus and Grafana metrics, central logs, OpenTelemetry traces, symptom-based alerts; triage, rollback, blameless reviewsGood alerts make on-call bearable; senior candidates are judged on incidents more than tools

Differentiators: Go for internal tooling and Kubernetes operators; GitOps with Argo CD or Flux; policy as code with OPA Gatekeeper or Kyverno; pipeline security (image scanning with Trivy, secrets in Vault or a cloud secret manager); and cost awareness. When you check which tools current postings name (the snapshot near the top of this guide tallies them), look hardest at the cloud provider: a new CI tool takes days to learn, a new cloud much longer.

Experience levels, titles, and employer types in India

  • 0–2 years: some employers hire freshers straight into DevOps, though many people move in from adjacent roles (routes below). Expect Linux, Git, Bash or Python, one CI tool, Docker and one cloud's core services. The work is pipeline fixes, monitors, patching and access requests, often from a runbook.
  • 3–5 years: you own pipelines and infrastructure code for a group of services, run Kubernetes day to day (upgrades, autoscaling, node pools), take primary on-call and choose deployment strategies such as rolling, blue-green or canary.
  • 6+ years: you design the platform and its guardrails for many teams, lead major incidents, and set standards for security, cost and reliability.

Ladders vary: DevOps Engineer, Senior, Lead and Principal at many companies; SRE I, II and III at some product companies; Associate, Senior Associate, Consultant and Architect at services firms. The employer type changes the job more than the title does:

  • Services firms: client environments, often across several clouds, changes raised through ITSM tools within approved windows, and rotational shifts in managed-services teams.
  • Product companies: you run the platform for your own engineers and are on call for incidents customers notice. Expect more coding.
  • Startups: one or two people own the cloud account, CI, costs and security basics; a managed container service or a few VMs is often wiser than Kubernetes at that stage.
  • GCCs: part of a global team, often with follow-the-sun on-call, strict change approval and audit trails.

How DevOps interviews are put together

  1. Recruiter screen: notice period, your cloud, and whether you have done on-call. An AWS-versus-Azure mismatch can end things here.
  2. Fundamentals: Linux, networking and a short live script, such as counting 5xx responses per minute in an Nginx access log.
  3. Scenarios: the interviewer plays the broken system and answers each command you say you would run, so narrate what you check and why.
  4. Design: a pipeline or the infrastructure for a service, covering environments, promotion, secrets, rollback and monitoring; senior candidates get multi-zone or disaster recovery questions.
  5. Managerial: incidents you led, a change of yours that caused an outage, and how you handle being paged.

Some companies send a take-home instead: containerise an app, then write its pipeline and a Helm chart or Terraform module.

Scenario questions to rehearse aloud

The classic opener is "a deployment is failing; walk me through it." A strong answer has a shape:

  1. Ask which stage fails and what changed since the last green run: the code, a base image, a dependency, a rotated secret.
  2. In the pipeline, read the first error rather than the last, re-run once at most to rule out flakiness, and check runner disk space and credentials.
  3. In the cluster, run kubectl rollout status, then kubectl describe pod for events. ImagePullBackOff points at the tag or registry credentials; CrashLoopBackOff at the app or its config (kubectl logs --previous); Pending at resources, node selectors or taints; OOMKilled at memory limits.
  4. If production is affected, roll back first and investigate afterwards.

Then practise these:

  • What happens between a user typing your app's URL and a pod receiving the request? Cover DNS, the load balancer, the ingress controller, the Service and its endpoints.
  • A pod cannot reach a managed database in another subnet. How do you narrow it down? (DNS, security groups, route tables, network policies, then nc or curl from a debug pod.)
  • What is the difference between liveness and readiness probes, and what goes wrong if the liveness probe checks the database? (A slow database restarts every pod at once.)
  • Design a pipeline for a monorepo with six services: what runs on a pull request, what runs on merge, how the same image digest moves from staging to production, and where secrets live.
  • terraform plan wants to destroy and recreate the production database. What now? (Stop, find the attribute forcing replacement, consider prevent_destroy, and use moved blocks or state commands if it is a refactor.)
  • The disk is full but du cannot account for it. Why? (Deleted files held open by a running process, visible with lsof +L1; also check inodes with df -i.)

A resume that shows what you changed

The weakest DevOps resumes list tools without consequences. Give the scale in safe terms (services, clusters, environments, teams supported), what you changed, and the before and after. These bullets use illustrative numbers:

  • Example: Moved 18 services from manually triggered Jenkins jobs to reusable GitHub Actions workflows with dependency caching; median pipeline time fell from 24 to 9 minutes.
  • Example: Wrote Terraform modules for VPC, EKS and RDS adopted by four product teams; a new environment went from a two-week ticket to a reviewed pull request applied the same day.
  • Example: Led the response when the primary payments database failed, promoting the standby in 25 minutes; then scripted the failover and ran quarterly drills, and the next drill took under five minutes.

Common mistakes and their fixes:

  • A skills block spanning three clouds and every tool you have read about. Panels often pick the least familiar one and ask about it, so list what you have run in production.
  • Certifications above experience. They can help you through screening, especially at services firms, but panels hire on what you have operated.
  • Leaving out on-call and incidents, which are the evidence of judgement senior panels want.

Ways in, projects that prove it, and where it leads

  • From support or system administration: you already know Linux and production. Add Git, Python, one CI tool, Terraform and containers, then automate a manual task you do today and write it up.
  • From development: learn Linux and networking properly, then volunteer to own your team's pipeline and deployments.
  • From QA automation: you already run tests in pipelines; extend that to building and deploying what you test.
  • As a fresher: do not start with Kubernetes. Linux, networking and one programming language come first, then Docker, a cloud's basics and CI.

Projects a panel can dig into:

  1. Take a small app with an API, a worker and a database, and build everything around it: Dockerfiles, a pipeline that tests, scans and pushes images, Terraform for the cloud resources, Helm charts, and Argo CD deploying from Git. Document how to roll back.
  2. Add observability to it: Prometheus, Grafana dashboards, OpenTelemetry traces and three alerts with runbooks. Then break it on purpose (kill pods, fill a disk, add latency) and write a short post-incident review.
  3. Automate a real chore, such as finding untagged or idle cloud resources, with tests and a dry-run mode.

Watch the bill. Keep cloud projects within free-tier limits or credits, set a billing alert, and tear environments down when you finish.

From DevOps, common next steps are SRE, platform engineering, cloud engineering, and security through DevSecOps (see the cybersecurity guide).

Next steps and where to look