Hiring DevOps Engineers: What You Need To Know
It’s Not Easy Doing Everything
There’s an oft-circulated image in the technology sector – a company looking for a Swift programmer with 8 years of experience, while the language had only been out for 3. It’s a sad, sad testament to the corporate spectrum of talent: insane requirements that simply, and legitimately, cannot be met. DevOps isn’t magically excluded from that.
In Defense of Recruiters
My day job involves a technology staffing agency, so I unfortunately have a vast amount of experience with unreasonable requirements and uninformed talent acquisition specialists. And I’m not talking about the people I work with: I’m talking about the corporate side. Some companies have HR working on tech roles – writing job descriptions and required technologies they know absolutely nothing about. There’s really no sense in it, but those are the cards HR is dealt, and I truly feel for them; technology is probably the hardest industry to recruit for. It’s ever-changing and ever-evolving – and with everything else HR has to recruit for, they simply don’t have the time to learn technical terms, what frameworks are, what queries and libraries are, etc. So they go off a piece of paper and hope they said “Vue” right (psst – it’s pronounced ‘view,’ not ‘voo.’).
So, What Should You Look For When Hiring For DevOps?
Technology is hard to hire for, and DevOps is even harder.
In a tech slack community, someone once asked, “How would you describe DevOps?”
He was met with about 10 different definitions, each more complex than the last. This led me to believe that there’s not one real all-powerful definition of DevOps, other than the overly-simplistic “it’s dev and ops together.” That would never cut it. DevOps is infrastructure, systems administration, scripting, cloud computing, automation, development, deployment, it’s oh-god-there’s-a-fire-call-devops. DevOps engineers are amazing individuals with a breadth of knowledge attainable only through years of hard work and constant education.
I’ve looked at countless amounts of DevOps job openings over the past year (a product of both working at a tech staffing agency and my partner being a DevOps engineer) and what baffles me is the fact that these job descriptions keep getting longer and longer. I’ve seen technical requirement sections with at least 20 technologies. No one, in their right mind, should expect that.
People are looking for unicorns, and those are incredibly rare. I get the feeling (let’s call it more than a feeling – it’s what I’ve unfortunately seen with my own eyes) that most job descriptions are basically a short email written to HR from the tech lead with a stream of technologies DevOps currently uses, and HR takes those 20-30 technologies and plugs them into the technical requirements section.
Let’s take a moment to realize how unfair that is for everyone involved – but especially your DevOps team.
What You Can Realistically Expect Your DevOps Candidates To Know
It’s unrealistic to expect a DevOps engineer to know every single piece of tech your company uses. What should be listed in your technical requirements are your core techs – period. You can have a “nice to have” section below that, but please keep requirements to what is truly required – not tech that your company uses maybe once or twice per year. That can be taught. Most things can. Core tech, to put it bluntly, would be the stuff they use every single day. Everything else can go into the “nice to have” category. Companies need to stop expecting their DevOps candidates to know everything right off the bat, and instead allow for training on the small stuff.
Speaking of, it’s important to look at the education your DevOps candidate has gathered over the years. I’m not talking about degrees here – I’m looking at how bare their résumé was, tech-wise, at the beginning of their career versus now. Look at their prior jobs: what technologies did they use? What did they learn during their tenure at each job? Did they keep learning and advancing, or did they stay in jobs that utilized their current skillset only? If you’re looking at a cloud engineer that uses AWS, did they get certified? Let me make this clear, certifications shouldn’t be everything. While they show an understanding of the product and passion, they don’t show actual hands-on experience, which can be crucial. But to go back to my main point on education, this stuff matters more than you could ever imagine. Teachability, curiosity, and initiative are paramount to making a good DevOps engineer, and are all things I would look for in a new hire.
And on the topic of initiative, let’s talk about talented, “lazy” engineers. Lazy engineers are, for the most part, very good. They tend to find ways to automate redundant, menial tasks. That’s good. You want that. You want DevOps people that are able to create scripts and automate a good chunk of their jobs. That’s how you know you got a good one. Look for people who have scripting and automation on their résumés, and for people with object-oriented programming since many scripting languages require an understanding of them to fully unlock their potential.
Lastly, look for engineers with good soft skills. Sometimes, soft skills can be just as important as technical knowledge. Knowing how to communicate effectively is imperative for DevOps engineers. Let’s face it: some developers are very protective of their code, and having someone come in and tell them “hey, I found a bug” can put them on the defensive. You want DevOps folks that are able to diplomatically bring up issues, suggest better ways of doing things, and foster a positive – collaborative – work environment between both teams.
DevOps requirements have been a huge problem for years. However, as more and more people point this out to corporate recruiters, third-party recruiters, and HR staff, we can help them differentiate what’s actually a requirement, and what’s nice to have – and maybe, just maybe, we can reach a compromise.
DevOps folks are amazing workers with vast amounts of knowledge and technical ability – so let’s keep them motivated, give them a chance to learn the smaller stuff, and stop trying to catch unicorns – because, let’s face it, all DevOps engineers are unicorns.
- Keep reqs to your core tech.
- Put a “nice to have” section for your lesser-used tech.
- Go for teachability, not just alrdeady-attained knowledge.
- Don’t pass on people because they ‘seem lazy’ – they might be your best automaters (did I just invent a word?).
- Go for soft skills, because your DevOps team will need those.
- Realize how awesome these guys are in their own right just by being in this field.
About the Author
Roxanne Williams is a tech/marketing professional in Florida. She has experience in Project Management in both IT and Marketing capacities.
She writes about hiring, marketing, and technology.
Find her LinkedIn here.
> Read more
> Read more
> Read more
> Read more