Hiring cloud and DevOps engineers: separating real hands-on skill from tool lists

A candidate arrives for a DevOps interview with a CV that names eight tools and three cloud platforms. The engineering head asks how she would deploy a small service with no downtime. She names the tools again, in a different order. Nobody in the room is sure whether she has done it.

This happens often in cloud services firms because the market rewards keywords. Your job in the interview is to move the conversation from names to events. This post sets out a way to do that without turning the process into a three-week exam.

Before you open the job, write down the three or four pieces of work the new person will own in the first six months. It might be moving a client's workloads to a new account structure, building release pipelines for a product team, or watching cost and capacity for a managed client. Each of these needs a different mix of skills.

Then separate must-have from can-learn. An engineer who has run containers in production can usually pick up a second orchestration tool. An engineer who has only followed tutorials may not. The role design and job description work GullyHR does is built around this split, so the advert attracts the right people and screens out the wrong ones.

• Look for verbs and outcomes: migrated, rebuilt, reduced, on-called, wrote the runbook. Be wary of lines that only list tools.
• Look for scale in plain terms, such as number of environments, services or clients the person supported. Ask what that meant day to day.
• Check how long they stayed on each project. Short stints are not a fault, but ask what they saw through to the end.
• Note whether they describe a team or only themselves. Production work is almost always shared, and the story should show that.

1. 1

   Short screening call

   Ten to fifteen minutes. Ask them to describe the last production incident they worked on, step by step, including what they did first.

2. 2

   Walk through one past project

   Ask them to draw it. Who used it, where it ran, how it was deployed, how it failed, who was called. Interrupt with why questions.

3. 3

   Hands-on exercise

   A small problem in a sandbox they can use with their own tools, such as a failing pipeline or a misconfigured network rule. Agree the time limit in advance and allow them to search the web as they would at work.

4. 4

   Review session

   Ask them to explain what they did and what they would do with more time. Candidates who can only repeat commands will struggle here.

5. 5

   Scenario and judgement round

   Offer a client situation with trade-offs, such as a rushed change before a festival sale. Listen for caution, communication and willingness to say no.

6. 6

   Reference and offer

   Check the same facts the candidate gave you with someone who worked alongside them. Use the scorecard to agree the offer level.

Ask about the worst change they ever pushed. Ask what they would never run in production again. Ask how they decided to roll back and who they told. People with real hours on live systems answer with specifics, such as a certificate that expired on a Sunday or a pipeline that deployed to the wrong account. People without them tend to give principles.

Ask also how they hand work to the next person. In a services firm, an engineer who documents and hands over cleanly is worth more than a brilliant one who keeps everything in their head. This ties directly to how your night and weekend cover works, as covered in the post on shift rosters for security and network operations centres.

Role and level being hired, with the three main pieces of work for the first six months.
Evidence of running live systems: example given, detail level, ownership (score 1 to 4).
Hands-on exercise: approach, correctness, clarity of explanation (score 1 to 4).
Handling of failure: honest account, what changed afterwards (score 1 to 4).
Communication with clients or non-technical colleagues (score 1 to 4).
Learning ability: how they picked up their last new tool (score 1 to 4).
Concerns, follow-up questions and the interviewer's name.
Recommendation: hire, hold, or decline, with one line of reasoning.

A certificate shows that someone studied a platform and passed an exam. That is useful, especially for a junior profile or when a client contract asks for certified staff. It does not show judgement under pressure. Treat it as one input on the scorecard and verify the live skill with the exercise.

Good cloud engineers are rarely on the market for long. If your process takes five weeks and three reschedules, the best candidate will have signed elsewhere. Keep the stages to the six above, name a single owner, and set a rule for how quickly feedback goes out after each step. Offer levels should come from your pay structure, as explained in the post on pay and grading for infrastructure and security engineers.

If you hire often, a standing process helps. GullyHR supports firms with this through IT specialised recruitment, and the cloud computing companies hub collects related guides for this sector.

• Confirm in writing the scope of the role, including on-call expectations and any client-site or night duty.
• Confirm the notice period and joining plan with the candidate, and agree what happens if they are asked to leave the current employer early.
• Explain access rules for client systems, so the candidate knows from day one what they will and will not be given.
• Have your own qualified adviser review the offer letter and any restrictive terms before use.