What the role means here
In this market DevOps rarely means a platform team. It usually means you are the person who makes deployment boring for four or five developers, and who gets called when production stops. Interviews reflect that: less theory, more "what did you do when it broke".
Cloud usage is mixed. Plenty of companies run on their own hardware or on regional providers, so answers that assume managed everything can land badly. Ask what they run on before you design against it.
Pipelines
You will be asked to describe a pipeline you built, then pushed on the parts people usually skip: what happens on failure, and who is allowed to deploy.
Your pipeline is green but the deploy broke production. Where do you look, and what do you change so it cannot happen the same way twice?
- Build once, promote the same artefact — not rebuild per environment
- Where secrets come from, and why they are not in the repository
- Rollback as a first-class step, not a manual scramble
- What the pipeline does NOT test, said out loud
Containers and what runs them
Docker is assumed. Kubernetes is common but far from universal here — plenty of solid teams run compose on a couple of machines and are right to. Do not over-claim Kubernetes depth; it is easy to check.
- Image size and why it matters for a slow connection
- The difference between a container that stops and one that is unhealthy
- Persistent state — the thing containers are worst at
- Resource limits, and what happens when you do not set them
The incident story
Have two ready. This is the highest-yield preparation on this page, and most candidates arrive without one.
Tell me about the worst outage you were part of. What did you do first?
Structure it: what broke, how you found out, what you did to stop the bleeding, what the root cause turned out to be, and what changed afterwards. The last part is the one interviewers are listening for. An outage with no change afterwards is a story about luck.
You do not need to have been the hero. Being the person who wrote the timeline honestly is a good answer.
What interviewers here are really assessing
- Can you make things repeatable, or do you fix them one at a time
- Do you leave the system understandable to whoever is on call next
- How do you behave under pressure — and can you say so without performing
- Do you know the cost of what you are proposing, in money and in attention
What to focus on at your level
Junior · 0–2 years
Linux you are comfortable in, one pipeline you built, and containers you can debug rather than only run.
Mid · 2–5 years
Infrastructure as code, monitoring you configured yourself, and at least one incident you can narrate end to end.
Senior · 5+ years
A position on how much platform a small team should have, cost awareness, and the judgement to argue against Kubernetes when it is not warranted.
Open DevOps roles right now
Read from the live roles on Nebryx when this page loaded — not a list written into the page. If it is empty, nothing matching is open today.
Frequently asked questions
Do I need Kubernetes to get hired here?
No. It helps for the larger employers and for outsourcing work aimed at European clients, but many strong teams in the region deliberately do not run it. Knowing why you would not use it is itself a good answer.
How much cloud experience is expected?
Varies more than any other role on this site. Ask early. Experience on one provider transfers well; pretending to know three does not survive the first follow-up.
Is scripting enough, or do I need a real language?
Bash and Python cover most of the work. Go is increasingly useful and is what a lot of the tooling you touch is written in.