What they ask in a DevOps interview, how to answer about CI/CD, Kubernetes and incidents, and how to rehearse the conversation.
A DevOps interview is least of all like an exam on tools. Anyone who has read job postings knows the list of technologies. What is tested is different: how you build the process, what you do when everything breaks, and whether you can choose a tool for the task rather than by how trendy it is.
| Stage | What is assessed |
|---|---|
| Screening | experience, stack, salary expectations |
| Infrastructure | Linux, networking, containers, orchestration |
| Practice | incident analysis, log-based diagnostics |
| Processes | CI/CD, releases, security, teamwork |
The answer “GitLab CI” is not an answer. They expect the path: commit → build → tests → artifact → deploy to environment, with rollback and with what happens when any step fails. A good answer includes build time and prior experience improving it.
Image layers and their caching, multi-stage builds, why a 1 GB image is a problem, how to pass secrets, the difference between CMD and ENTRYPOINT. They often ask you to explain why an application container crashes on startup.
Pod vs Deployment, readiness and liveness probes, restarts and their causes, resource limits and OOMKill, ConfigMap and Secret, Ingress. Practical question: “the pod won’t come up — where will you start?”
Terraform vs Ansible, state and locking, plan before apply, idempotency. They check whether you understand what `apply` will do before running it.
What happens from browser to application: DNS, load balancer, TLS, proxy. LAN layers, MTU issues, the difference between L4 and L7. This is where they weed out those who 'did everything through ready-made pipelines'.
Metrics vs logs vs tracing, what SLO and budget are, why 'monitoring exists but incidents are not visible'. Practical case: users complain but metrics are normal — what do you check?
Steps when production goes down, who makes decisions, how to communicate, how to write a postmortem without assigning blame. This is interviewers' favorite question: it shows real experience.
The structure works: symptom → hypotheses → what I check → solution → prevention.
«Users report a 502. First I look at the load balancer: whether the upstreams are alive. If they are alive — I check application logs and latency metrics. On a previous project, the cause was database connection pool exhaustion: increasing the pool and adding a timeout helped. Prevention — an alert on pool utilization, not on 5xx».
— sample answer from interview debriefing practice
A week of 30–40 minutes per day: cover seven topics, recall two or three real incidents with numbers, and go through one full dialogue. The incident case is more important than theory — that's where candidates are most often screened out.
If it is listed in the job posting — yes, at least at the level of probes, limits, and troubleshooting a crashing pod. If the infrastructure is on virtual machines, they ask about systemd, load balancing, and deployment without an orchestrator.
Yes — Python, Go, or Bash at the level of automation scripts. Full live coding is less common, but they may ask you to review someone else's script and find an error in it.
Say it directly and explain the principle: “I have not worked with this, but the task is solved the same way as X — through declarative description and idempotent execution.” The interviewer is checking transferable thinking, not API knowledge.
With a range, not a single number, based on the market. A detailed breakdown is in the article salary negotiations.
Describe the situation in one phrase — “DevOps engineer interview, Kubernetes and CI/CD, four years of experience” — and go through the dialogue in simulator. The coach will ask questions about your role and review the answers after the conversation.
Recall two of your own incidents and write them out using the scheme: symptom — hypotheses — what you checked — solution — prevention. Then walk through the case aloud: open HintMeTalk AI, «Trainer» mode, describe the vacancy in one phrase. After the breakdown, it is clear where you start fixing without checking the hypothesis.
Breakdowns for other roles: Java, Python, frontend, systems analyst.
Practise this skill in HintMeTalk AI
Open the app
HintMeTalk