A guide to hiring a DevOps engineer
Every product team has the same two jobs: build the software and run it. DevOps is the practice of making those two jobs work together, and a DevOps engineer is the person who owns the path between them. Without that person, releases are slow, servers are set up by hand and a failure at night turns into a scramble. This guide explains the role, how it compares with related jobs and how to work with a remote engineer. It is written for founders, engineering managers and product leads who want calmer releases.
What a DevOps engineer is responsible for
The work falls into two halves. The first is build and release: how code moves from a developer’s branch through tests and into production. The second is run and watch: how the system stays up, how problems are seen and how the team recovers. A DevOps engineer builds the pipeline, sets up the cloud and the servers, writes the setup as code, packages the apps and adds the logs, metrics and alerts. They also write short guides, so the knowledge does not stay in one head.
How a DevOps engineer differs from other roles
A software engineer writes the product. A DevOps engineer builds the road the product travels on. An AWS developer builds applications on one provider’s services, while a DevOps engineer works across providers and tools. A security specialist, such as an ethical hacker, tests whether the system can be broken into. DevOps engineers keep security habits, but they do not replace a full test. If your need is narrow, a Docker developer or a Kubernetes developer goes deeper on containers and clusters.
When a DevOps engineer makes sense
- Releases are manual, slow or frightening, and developers avoid shipping on Fridays.
- Your servers were set up by hand and nobody can rebuild them from scratch.
- You find out about outages from customers and not from your own alerts.
- Your cloud bill keeps growing and nobody knows why.
- You are moving to containers or to a new cloud and want an experienced hand.
If you have a small app on a simple host, a good developer may be enough for now. If your system has many services and strict uptime needs, you may want a full team or a lead on site.
Reading a DevOps engineer’s background
Look for what the person changed, not only the tools they have touched. Ask which systems they ran, how many developers used their pipelines, what broke and what they did about it. Strong answers name the system, the choice that was made, why it was made and what happened next. Be careful with a background that is only a list of products. Knowing the name of a tool is different from having used it in production when things went wrong.
Interview questions to try
- Walk us through how a code change reaches production in a system you built.
- Tell us about the worst outage you handled. What was the cause and what changed afterward?
- How do you keep secrets out of code and logs?
- When would you not use Kubernetes?
- How do you decide which alerts should wake someone up?
Listen for plain steps and honest trade-offs. Doubt anyone who says a tool solves every problem. For more questions with scoring ideas, read our DevOps interview questions guide.
Set a short paid task
Pick a small job from your real stack for each finalist. Useful examples are a pipeline that tests and deploys a sample app, a short review of your current cloud setup with three suggestions, or a monitoring plan for one service. Pay for the hours. Check how clear the steps are, whether the work can be repeated and how the person answers when you ask why they chose a method.
Match the person to your stage
An early product needs someone who can set up a simple, safe pipeline and one hosting setup without building too much. A growing team with many services needs someone who can split work cleanly, add monitoring and cut release time. A team in a regulated field needs someone who can keep records of who changed what. Titles differ from firm to firm, so ask what each candidate personally owned.
Agree access and routines
Set up personal logins with just the permissions the job needs, and register every account to your company. Agree on working hours, a weekly call with the developers and a way to reach someone when a release fails. Decide who is on call and what happens outside working hours before the first incident, not during it. Remove access when the work ends.
Working with your developers
Present the DevOps engineer as a teammate who makes shipping easier, not as a gatekeeper. Ask for short written guides on how to deploy, how to roll back and where to look when something fails. Hold a brief review after every incident that focuses on fixing the process and not on blaming a person. Over time, developers should need less help to ship safely.
Mistakes to avoid
- Handing over the only admin login to one contractor.
- Building a large cluster before the product needs one.
- Skipping tests of backups, so the first restore happens during an emergency.
- Adding many alerts that nobody reads.
- Leaving the setup undocumented, so only one person understands it.
Want a specialist for one area? See our pages to hire Docker developers and Kubernetes developers.