DevOps Engineers are in high demand. It’s easy to judge a book by it’s cover but are you missing out on untapped talent? Here are the secrets we’ve unearthed from the organisations hiring successfully.

Look under the hood of a job title 🔎

When reviewing CVs, don’t be guided by job titles – there are companies in which Platform Engineers write code and develop features and I’m sure most of us have encountered ‘DevOps Engineers’ who work in a siloed ops or infra team and haven’t touched any modern tooling!

Focus on what you need your new hires to do from day one, and work with your talent function or recruitment partners to hone in on those skills and experiences. 

To give a recent example, the team at Burns Sheehan have filled several DevOps & Platform engineering vacancies with software engineers. The words DevOps and Platform were nowhere to be found in their CVs, but if someone has experience of managing services in public cloud, has created infrastructure with Terraform and managed deployments with Jenkins, does it matter what their job title is?

Have they gained the skills and experience in a non-commercial setting? 📚

There are obviously situations where a particular level of skill & experience is largely non-negotiable. For example, you have created a budget for a tech lead to provide mentorship and guidance on a large-scale Kubernetes migration. You probably need an individual with strong Kubernetes experience who can evidence that they have delivered something similar in the past. 

But at the mid-level, it's worth considering if the candidate may not have had the opportunity to develop the skill commercially due to limitations in the role. Therefore, have they taken the responsibility onto themselves to develop the necessary skills outside of work? E.g. has the candidate done any non-commercial work and if the candidate has worked on personal projects driven by the technologies you are looking for. 

If you have a mature team who has the capacity to develop this sort of profile in terms of training and support, then it is something to consider. But if the team is fairly immature in terms of experience then the patience and support required to upskill a mid-level might be too much added pressure. 

Wrong toolkit. What’s the next best alternative? 🛠

Has the candidate used different tools to do a similar job? Most experienced cloud practitioners will say that the transition between AWS, GCP & Azure takes a couple of weeks for someone who is already relatively competent in using a variety of services on one platform. It’s not immediate, but it’s also not a vacancy that has sat empty for six months. Consider what a candidate has experience of doing, not just the tool kit they’ve been provided with. Similar parallels could be drawn between different infrastructure as code solutions, CI/CD tooling, observability stacks. If the candidate understands the underlying concepts, it is likely they could transition to a new tool relatively quickly.

They’ve just fallen short in the technical assessment! 📝

If you have a candidate you’re on the fence about technically, why not encourage them to upskill in the missing tech during their notice period? You don’t want to ask someone to “work for free” but keeping in touch with pending starters and providing them with learning & training materials is a win-win. Building rapport and engagement during notice periods is never a bad thing! There is also an opportunity to tie this in with measurable objectives and milestones once you have your new engineer in post.


Burns Sheehan have worked with many clients, helping them unearth “hidden talent” in the market. Our team have advised hiring managers to re-think how they identify and assess applicants during the interview process. Screened and qualified candidates go through a rigorous vetting process by Burns Sheehan which enables us to share comprehensive notes that accompanies a candidates CV. If you are building teams in cloud & platform and are looking for tailored hiring advice, get in touch with me here.