I don't often talk to recruiters. In fact, I don't typically work with third-party recruiters because all too often, they are interested only in filling a job req, collecting their commission, and moving on to the next one. Additionally, most recruiters don't really understand the needs of a DevOps-minded organization. But good recruiters are often the best source of knowledge when it comes to finding great talent.
When I sat down to write an article about DevOps hiring, I knew that candidates' and hiring managers' thoughts would be well covered by the Opensource.com DevOps community. But I thought it'd be great to get some tips from a recruiter on how to find, cultivate, and, well, recruit great talent for DevOps roles.
Enter Ken M. Middleton of Your DevOps Recruiter. Last year Ken reached out to me about potentially working together during my job search, and I quickly recognized his honesty and candor. Ken knew what I was looking for was outside of his wheelhouse and told me that. He earned my respect at that moment.
I sat down with Ken and peppered him with hiring questions. Here are some highlights from our discussion.
I started with a very direct question: How do you find great talent?
Ken offered two interesting answers. "The first one you can probably guess: LinkedIn. LinkedIn—to anyone recruiting a specialized skill set—is the bee's knees when it comes to really being able to tap into that passive talent. That's the thing that I think LinkedIn has created for themselves. You have people on LinkedIn who, they're not really looking for a job, but they're open to hearing about jobs. And I'm able to connect with them. I think people really have to understand that LinkedIn is a two-way street."
Ken added, "So this is something that I try to do a decent job of, and I'm consistently working on it. You are looking at the best talent out there, based on their LinkedIn profile and how strong it is and what that brand is that they've created. But you also have to have a pretty strong brand yourself. So my LinkedIn profile, to me, is part of my marketing platform, that when I reach out to somebody, I want them to understand that I'm in the DevOps community—I'm commenting on DevOps things; I'm looking at different DevOps articles."
Ken's second answer should not surprise anyone familiar with Opensource.com, but it might shock some folks in the DevOps world: "You've got to be active in your local area, whether it's with meetup groups, whether there are other, different DevOps or AWS groups, or any other contact or class forums. You've really got to see what's out there and get out and meet people."
Imagine that! Collaboration outside of silos works in hiring DevOps. This is such an overlooked method of hiring.
You don't need to have a position to fill to better yourself and meet like-minded people. I try to encourage introverted people I work with to go to more meetups and community events. You don't necessarily need to speak at these events. You don't even have to ask questions. But at least go and introduce yourself to someone. Eventually, you'll find somebody with a similar interest, and you can discuss things with them. Building relationships like this will net you benefits beyond hiring.
Filling the unfilled DevOps roles
One thing I learned while talking to Ken was that many DevOps roles go unfilled.
"I've been in the IT recruiting space for 11 years, but when I left my previous company and ventured out on my own in March of 2017, I started looking at all these DevOps roles, and what I recognized is that a lot of the roles weren't being filled. Some of these roles had been open for close to a year. And I didn't understand the problem."
Ken continued, "I started doing some research, and what I found out is that you have your general recruiters trying to recruit on these roles, and they didn't clearly understand the difference between Git and GitHub. They didn't know what continuous integration means versus continuous deployment. So, when they were speaking to these people, they were using all these general terms and slinging people at these jobs that were not qualified for. And it was just wasting everybody's time. You really need someone that knows the lingo if you're going to engage a recruiter to help you in your search."
Take the time to collaborate with recruiters, too. Spreading knowledge outside of the technical teams in an organization can take it even further.
When I asked Ken if he uses the Silicon Valley method of hiring—looking at a candidate's GitHub profile—he responded that he rarely does this. "I'll go and look at some people's profiles, but I don't look at their code because I don't know what the hell I'm looking at. But what I do is try to make sure I understand is all the different technologies and how they're using them."
Recruiting from GitHub is a bad idea, Ken says. "It's quite exclusionary. [GitHub] has helped me build my knowledge overall. But I don't look at GitHub. I do try to continuously figure out where I can find new people if it is different avenues like that. I'm always looking for different avenues to find people."
Learning new technologies
Continuous learning goes a long way even outside of highly technical fields, and Ken takes the continuous learning and feedback tenets of DevOps seriously.
I wanted to press Ken on a problem I routinely have when recruiting people: How do you know if a candidate can learn new technology? How do you assess if they have fully invested and walled themselves off from new things?
Ken replied, "What I have noticed a little bit with some of the managers I've worked with is that they're so focused on a specific technology that they're willing to pass up on good talent in regard to people who could pick up the technology."
It's nice to know that checking boxes on a list is not the best way to go about assessing whether or not to hire people.
Ken continued, "What I've found [is] if they're making their first DevOps hire, they're so focused on the technology—and as you know, there are so many different tools out there that when you look at the combination of what people can work with, it's almost endless. So when they're so focused on, hey, this person has to have experience with this configuration management tool, this monitoring tool, this container tool—and it's like—okay, they may need to have that. But let's talk about what you are trying to accomplish. What could they potentially learn? And what is that cultural aspect that you're looking for? I've found that when you get managers who are so specific on the technology that it's so hard to fill their roles, that it just makes it almost impossible."
Hiring for culture fit
A few times during our conversation, the topic of culture and finding a cultural fit came up. Ken's answer has forever changed how I will interview:
"I always like to ask people, 'Tell me, what is your ideal-type role? If you could have the druthers of what you'd be doing and what type of environment you're working in, talk to me about that.' And so, when I'm working with people, I try not to lead with a job. I might tell you, 'Hey, I have a job that you need this XYZ technology,' but I won't tell you what the culture is like. I won't tell you what the company is like. I won't tell you anything in regard to what the company is looking for, because I want to hear what you're looking for. And if you're saying something that's in line with what I'm looking for—I have some people who are like, 'I want to work for a startup company—I like a hectic environment; I like learning new things all the time, and I love it when they don't have processes in place.' Okay, that sounds like a company I'm working with. But if you tell me—and I get this too—'I want an established company; I don't want to have to worry about having a job in two years from now or 18 months when our crowdfund didn't come through'—I listen. I let them tell me what they want. That gives me a sense of what type of culture they're looking for."
Brilliant! The approach shouldn't be to sell a person on a job, but to find the best fit for your culture and needs. A hard sell will typically get a person to buy in. But if a candidate has to be sold into your company, do you think they'll be around after a year or two?
Make sure a role fits the candidate's needs and wants, then tell them more about it.
What secrets lie in reference checks
I asked Ken: How can you validate your assessment of a candidate's talent?
Ken had an interesting answer to that question: "You've got to check their references. You've got to call people that they've worked with and talk to them about what type of employee this person was. I love my consultants, and I think they're amazing, and I'll always advocate for them, but I never take someone's consultant's word. I just can't do it. I'm here to service two people: I'm here to serve the client and I'm here to serve you. And me putting you in a job that you're not really qualified for, or you're not a culture fit for, it's not helping you or me."
How do you gauge if someone's fit for a specific position based on their references?
"I check their references, and I know in my mind what the client's looking for, but I don't lead the reference in that capacity. I will ask a question like, 'Hey, tell me about John. Tell me about what type of worker he was. Walk me through what you can expect from him on a day-to-day basis. What would be the soft skills he had? What would be his weaknesses? How does he handle them?' I'm listening to all of those things, and then once I get a good sense of if they are a match, I'll even ask—and most of the time this works out: 'Here's the type of environment this person might be going into. They're looking for X, Y, and Z, this, that, and the other. What are your thoughts on that person's ability to do the job?'"
And I've had people—you can tell the ones that are like, absolutely, that person would be great for it—or when they start giving you qualifiers, like, 'He or she would be good if they do this,' or 'Here is what I think that you need to make sure the person understands.' That helps me kind of create a picture if this person is an overall good fit. But it is a long, thorough process because it does take time. And it's not a complete science; it's a little bit of an art."
How do you gauge the quality of a reference? How can you verify if a candidate sent a buddy as opposed to a manager?
"I use LinkedIn to verify references. I don't take friends, I don't take coworkers; I take managers. And when people give me people that they say are their managers and I can't verify that through LinkedIn, that's a little bit of a red flag, too. And I rarely even present those candidates, because they're giving me peers and saying they're managers. Luckily, with LinkedIn, you can kind of filter a lot of that stuff out these days."
Establishing rapport, finding red flags, and measuring talent
It's important when engaging a candidate to establish rapport. Find a similar interest to talk about. It's even better when that interest comes from the role itself. Ken elaborates on this idea:
"I'm trying to put something in your LinkedIn profile that kind of speaks to you and your background and would make you say, 'All right, let me connect with this person and talk more about them.' And one of the biggest things I always use with people is like, 'Hey, listen, even if you're not looking for a job right now, it always makes sense to connect with a recruiter to know what's going on in the market. I'm a DevOps recruiting expert; I would love to share with you what I'm seeing in the market, and you don't need to be looking for anything now, but a year or two from now, if you're looking for something, I want us to build a relationship that you feel comfortable with.' Because it takes time to build a relationship that you trust somebody, and that's the thing I really pitch to people: that I want to talk to you now when you're not looking so when you're ready you feel comfortable in knowing that I can advocate on your behalf."
Much to my chagrin, job hopping is seen as a very bad thing in hiring. Ken explained:
"People jumping around a lot is always a red flag. Unless you are an H-1B candidate—there are people who are just in situations where they need to take contract jobs—if you have a job, if you're switching jobs every 18 to 24 months, it's just a red flag, because there has to be something there that isn't helping you keep a long-term job. Now, I know people say millennials, millennials, millennials do it. That is true, but a lot of companies are looking for someone to put more than 18 to 24 months into a job. Some clients just won't look at candidates if they jump around that much. They just won't even look at them."
I asked Ken: How do you measure demand for a particular skill or talent? I wasn't surprised to hear that folks are looking for Kubernetes skills.
"Fortunately, I'm part of a company called TEEMA Group, so I can see what jobs are posted out there even with my partners. So when I start seeing a bunch of jobs that are asking for a certain skill set, then I can tell it's more in demand. Like right now, Kubernetes—almost everybody and their cousin is trying to get somebody with some Kubernetes experience. A lot of companies are thinking about containerization, microservices, with Kubernetes relating to the level, and they realize the gains they can make by having it in their environment, and that's a real hot one right now.
"Outside of Kubernetes—I mean, that's just been so consistent. Everything else is just kind of across the board. Everybody wants AWS—even though more companies are using Google Cloud, because I've heard it's really good, that a lot of people like it. But AWS is the one if you're in a DevOps world; if you don't have AWS experience, you really limit your chances. You almost have to try to get some AWS knowledge to be able to work in probably 80-85% of the DevOps environments out there right now, because it's been the go-to for so long that people just kind of use it without even thinking about it. I don't know how many people look at Azure, but AWS is—they dwarf a lot of the competition right now. You need to really get experience with those two if you don't have it."
I asked Ken to elaborate on how he assesses someone's skills for something as new as Kubernetes.
"That takes it back to what we talked about before. That's the position I'm in right now. I have a client who wants someone with Kubernetes experience and the position has been open for two months, and we can't find anyone with it. When we had one person that was really, really good, what he was looking for, the guy took a different job. What I try to do is help my client understand you need to acquiesce a little bit on some of these skills, and look at someone who has the ability to pick it up, someone that's really good with Docker, has worked with different clusters, has worked a little bit with Kubernetes, and can pick up what they don't know. I try to really focus on what previous situations they were in where they had to learn a technology that they didn't know going into it. Have they a proven aptitude to do what they need to do to get up to speed on a new technology?"
DevOps job titles
There is a significant amount of contention around DevOps job titles. Thankfully, Google's Liz Fong-Jones and Seth Vargo have put the SRE vs. DevOps debate to bed. But what about DevOps Engineer titles?
"You know, it's a two-edged sword. Because before, you would have people that called them software engineers, but they were using all the different tools. They were using Docker, they were using Jenkins, and they were using all these VM tools—Chef, Ansible, and Puppet—but they were considered software engineers. People were discounted then because their title didn't say 'DevOps engineers,' but they were, right? And you still see a little bit of that today. So, what's happened now is that everybody has 'DevOps engineer' on their resume. I mean, not that they don't have the experience—because a lot of them do have decent experience—but it's like if someone has touched any type of automated system or automation tool, or even just done shell scripting, they put DevOps on their resume, and they're a DevOps engineer."
Any prominent titles other than "DevOps Engineer?"
"'DevOps engineer' is a big one. 'Site reliability engineer' is always out there. 'Build and release.' Those are the three that you see all the time. And then some people just call themselves 'software engineers,' but if you look at their resume, they're doing a lot of DevOps stuff. But the DevOps title has definitely proliferated, and it's on everybody's resume; it's just a hot buzzword."
I hope you found our conversation as enlightening as I did. I'd love to hear your thoughts in the comments.
[See our related story, Who drives the culture of exceptional hiring?]
Comments are closed.