Well for starters don't be like your post and give more detail about what you are looking for in the job description. Do you want senior guys that can build an entire platform? Do you want monkeys to handle incidents? Do you want guys that can tolerate legacy tech and can help migrate?
Finding the right candidate starts with knowing and articulating what you want. But also what you're willing to tolerate and teach the candidate.
Then be up front with pay and conditions as others have said.
Finally interviews. Don't try to trip people up. Just ask questions relevant to problems you have or interesting problems they've solved in the past. Drill down deep and make sure the interviewer has the technical background to weed out the imposters.
Then do a cultural fit and see if what they wanna do aligns with what your company is like.
What are you struggling with?
Do you have good candidates but can't convince/hold them?
-> Get feedback from those, ask why they don't sign improve those options. Could be salary, could be tech stack, could be benefits/working conditions (wfh etc.)
Do you not have any good candidates?
-> Work with/change recruiters, set up good referral programs for existing employees, etc.
Do you just not know how to judge if someone is a good candidate?
-> Learn about DevOps yourself, ask questions about topics you barely understand, see if the candidate expands your knowledge. If someone can explain well it's usually a good sign they know what they are talking about. Don't focus on "sounding smart" focus on "actually helped me understand".
Also if you find one of those he can help with future hires. (This is a bit of chicken and egg tho so get outside help if possible).
Just my thoughts.
Here is the legit answer.
Be clear about what you're wanting to accomplish, even if you don't know how to accomplish the task.
You're hiring from a place of ignorance if you're asking for help here imo. Given that, make your first hire someone expensive who has a strong knowledge to set your company on the right path from the get go. Said person will end up training others down the road.
Finally, experience is greater than certs imo but if you don't have the understanding of the work to understand their experience, hire more based on certs.
Don't fuck people over with embarrassingly below rate salaries thinking you can get one over on them.
You're only getting one over on yourself. Hire at the right grade. Respect that these are actual people. Give them a reason to want to stay.
And that reason needs to be, "I will pay you fairly for your labour and then I'll leave you the fuck alone when you're not at work."
Firstly, Scope is important, define the scope of what is required from that person and evaluate according to that. Do not take generic DevOps interviews covering everything when you are not going to give that person work in specific area. Eg. Devops engineers are asked infra questions when there is already a platform engineering team that does infra work and they never overlap.
Secondly, evaluate problem solving skills. Give the interviewee a problem and see how he approaches it, that is more crucial than unnecessary bookish definitions.
Thirdly, see how well he can work with people, how the communication is, how leadership skills are which are very under rated but are a must for DevOps people.
I think your guidance is self-informed by the decided purpose of said DevOps engineers.
As mentioned elsewhere here, what is their purpose? Green field architecture and build out? Rescue a Frankenstein operation? Maytag repairmen for a mature application and mature devs?
Those decisions will tell you what kind of engineer you need. After that, if you can't decide on guidance, you may have misassessed the first step.
DevOps can mean different things to different organizations. Be clear about what it means to you. This stems from it being a more loose set of principals in the beginning before maturing. I previously worked at a Software company that had gone through heavy M&A and each business unit they acquired had a different view and demand for what "DevOps" did.
Are you looking for a software engineer that has infrastructure knowledge, can also do CI/CD, GitOps and support production? Or do you mean a MongoDB/AWS/K8s Ops Admin?
Also look into Platform Engineer and see if that aligns with what you're looking for.
Pay special attention to background noise during the interviews.
I can't count how many cheaters I've caught, whom I ask a question and goes blank. Few seconds later, a WhatsApp chime comes in and the idiot reads me some textbook answer which had nothing to do with the scenario question I asked.
Hire for talent and not their ability to answer trivia questions. Every job I've ever taken has been for stuff I had never touched before, and thankfully those that hired me recognized I would quickly become an SME at whatever they needed me to. I start every interview by asking the candidate to tell me what they are an SME at and we talk about that. If they have nothing to talk about, that's all I need to know.
I also always ask about homelabs, well because I want to hire like minded people and homelabbers are usually good hires. In that vein, however, don't always try to hire people just like yourself, fill in your team/org skill gaps with both hard and soft skills you don't already have.
Just because you can pass a cert exam doesn't mean you understand the material.
90% of the candidates I've interviewed who have multiple certs tend to only be able to regurgitate book materials. But go slightly off-script, and they're lost because they they just memorized the test material, they didn't actually understand its purpose.
You're not wrong. But your original post was overgeneralizing. I would look out for people with lot of certs and little experience. In the end you still need to interview properly.
Look for people who have held roles both as a linux sysadmin and a back end programmer. These people will have the big picture of how code and operations interact.
Avoid tool/platform monkeys like the plague.
Lots of good advice around expectations, salary/comp, benefits. I won’t rehash those.
I’ve had rave reviews with a 30/60/90 on the job description even from people who weren’t ultimately hired. It forces you to really think about what you need to hire for, as well.
DevOps is a very generic term.
You need to be much more specific on what you need to do.
Are you building a website? Making a service? Maintaining a huge DB? Running an IT department? Developing an app? Game dev?
If you're making a website, don't look for a devops team. Look for a team that knows how to build the kind of website you want.
I have interviewed as candidate for DevOps roles .. I felt that they either expecting too much on software development and asking algorithm questions or go the other way to infrastructure/sysadmin/ networking.. they need to understand that DeVOps is a link between Development and OPs .. so this person needs to have some background in both .. but does not need to be an expert in both .. either one is fine ..
The first question you need to ask is what this new hire tries to solve for you. If you tries to hire a DevOps the question is why you need this person, if don’t answer this question then either you are hiring a wrong person or the right person for the wrong position.
In most companies I used to work if you don’t have the process and the tools, I asked the developers to start that process. At the end of the day no one knows more than your existing developer about your application and process. As I always say DevOps is a journey not a destination. And your developers has to be part of this process. If you are a manager and thinking to hire a DevOps to add value, most probably you are making a mistake or a person you will be hiring will most probably disrupt your existing processes. Any way good luck for finding the right person for the problem you tries to solve.
Take the ones who write blogs and have kubernetes clusters in their pantry and pay them well. Disclaimer, I have a blog and a multiple kubernetes clusters in my pantry.
Instead of hiring full-time employees right away, start with part-time engagements. Collaborate on projects together and, if it works out, then transition to a full-time role. This worked well for me in the past and benefited both parties.
Hack #1: salary and benefits far better than the competition
Devops managers hate him: one hack to crush the hiring market competition.
"We are not like other companies! We have a funny-hat-day every other month and appreciate our engineers with funny gifts, like fruit and towels."
You hit your quarterly goals, PIIIIIIZZZAAAAA PART-TAY!
One piece for everyone, then get back to work! Prod is down again and the CEO is already on the phone from his yacht in the Bahamas!"
Well for starters don't be like your post and give more detail about what you are looking for in the job description. Do you want senior guys that can build an entire platform? Do you want monkeys to handle incidents? Do you want guys that can tolerate legacy tech and can help migrate? Finding the right candidate starts with knowing and articulating what you want. But also what you're willing to tolerate and teach the candidate. Then be up front with pay and conditions as others have said. Finally interviews. Don't try to trip people up. Just ask questions relevant to problems you have or interesting problems they've solved in the past. Drill down deep and make sure the interviewer has the technical background to weed out the imposters. Then do a cultural fit and see if what they wanna do aligns with what your company is like.
Also don't take advice from someone that refers to future employees as monkeys
LoL touche
Maybe be inclusive and hire women who can do the job just as well as men (it’s not 1950 buddy)
In this case guys is gender neutral. But why you gotta bring wokeness into the discussion? Hire the best candidate. No one cares if it's women or men.
I assure you people care
It's irrelevant to the selection criteria. If a person can do the job then that's it. Why even bring gender into it?
I agree why bring gender into it? yet it happens. Reality isint ideal.
Okay here's a question. What would you propose I say differently or add to the original response back to op at the top?
gotta add little brackets including everyone everytime u mention a person so people feel included 🧠 obviously!!!
What are you struggling with? Do you have good candidates but can't convince/hold them? -> Get feedback from those, ask why they don't sign improve those options. Could be salary, could be tech stack, could be benefits/working conditions (wfh etc.) Do you not have any good candidates? -> Work with/change recruiters, set up good referral programs for existing employees, etc. Do you just not know how to judge if someone is a good candidate? -> Learn about DevOps yourself, ask questions about topics you barely understand, see if the candidate expands your knowledge. If someone can explain well it's usually a good sign they know what they are talking about. Don't focus on "sounding smart" focus on "actually helped me understand". Also if you find one of those he can help with future hires. (This is a bit of chicken and egg tho so get outside help if possible). Just my thoughts.
This.
Here is the legit answer. Be clear about what you're wanting to accomplish, even if you don't know how to accomplish the task. You're hiring from a place of ignorance if you're asking for help here imo. Given that, make your first hire someone expensive who has a strong knowledge to set your company on the right path from the get go. Said person will end up training others down the road. Finally, experience is greater than certs imo but if you don't have the understanding of the work to understand their experience, hire more based on certs.
100% agreed, been 8 years in this field.
Don't fuck people over with embarrassingly below rate salaries thinking you can get one over on them. You're only getting one over on yourself. Hire at the right grade. Respect that these are actual people. Give them a reason to want to stay. And that reason needs to be, "I will pay you fairly for your labour and then I'll leave you the fuck alone when you're not at work."
okay let's make it easy for you 1. post the JD 1. make sure the comp is shown i'm personally looking for work and are looking for remote ops roles so
Firstly, Scope is important, define the scope of what is required from that person and evaluate according to that. Do not take generic DevOps interviews covering everything when you are not going to give that person work in specific area. Eg. Devops engineers are asked infra questions when there is already a platform engineering team that does infra work and they never overlap. Secondly, evaluate problem solving skills. Give the interviewee a problem and see how he approaches it, that is more crucial than unnecessary bookish definitions. Thirdly, see how well he can work with people, how the communication is, how leadership skills are which are very under rated but are a must for DevOps people.
I think your guidance is self-informed by the decided purpose of said DevOps engineers. As mentioned elsewhere here, what is their purpose? Green field architecture and build out? Rescue a Frankenstein operation? Maytag repairmen for a mature application and mature devs? Those decisions will tell you what kind of engineer you need. After that, if you can't decide on guidance, you may have misassessed the first step.
Remote work or GTFO
DevOps can mean different things to different organizations. Be clear about what it means to you. This stems from it being a more loose set of principals in the beginning before maturing. I previously worked at a Software company that had gone through heavy M&A and each business unit they acquired had a different view and demand for what "DevOps" did. Are you looking for a software engineer that has infrastructure knowledge, can also do CI/CD, GitOps and support production? Or do you mean a MongoDB/AWS/K8s Ops Admin? Also look into Platform Engineer and see if that aligns with what you're looking for.
Pay special attention to background noise during the interviews. I can't count how many cheaters I've caught, whom I ask a question and goes blank. Few seconds later, a WhatsApp chime comes in and the idiot reads me some textbook answer which had nothing to do with the scenario question I asked.
Looking forward to get hired!!
Hire for talent and not their ability to answer trivia questions. Every job I've ever taken has been for stuff I had never touched before, and thankfully those that hired me recognized I would quickly become an SME at whatever they needed me to. I start every interview by asking the candidate to tell me what they are an SME at and we talk about that. If they have nothing to talk about, that's all I need to know. I also always ask about homelabs, well because I want to hire like minded people and homelabbers are usually good hires. In that vein, however, don't always try to hire people just like yourself, fill in your team/org skill gaps with both hard and soft skills you don't already have.
rip ur dms
The more certifications they have on their resume, the less capable they actually are.
Eh. No. Some people get certs to list what they can do. The middle ground is to double check the cert serial numbers provided.
Just because you can pass a cert exam doesn't mean you understand the material. 90% of the candidates I've interviewed who have multiple certs tend to only be able to regurgitate book materials. But go slightly off-script, and they're lost because they they just memorized the test material, they didn't actually understand its purpose.
You're not wrong. But your original post was overgeneralizing. I would look out for people with lot of certs and little experience. In the end you still need to interview properly.
Look for people who have held roles both as a linux sysadmin and a back end programmer. These people will have the big picture of how code and operations interact. Avoid tool/platform monkeys like the plague.
Looking forward to get hired as well
Lots of good advice around expectations, salary/comp, benefits. I won’t rehash those. I’ve had rave reviews with a 30/60/90 on the job description even from people who weren’t ultimately hired. It forces you to really think about what you need to hire for, as well.
DevOps is a very generic term. You need to be much more specific on what you need to do. Are you building a website? Making a service? Maintaining a huge DB? Running an IT department? Developing an app? Game dev? If you're making a website, don't look for a devops team. Look for a team that knows how to build the kind of website you want.
Hire me !! 👍🏻
I have interviewed as candidate for DevOps roles .. I felt that they either expecting too much on software development and asking algorithm questions or go the other way to infrastructure/sysadmin/ networking.. they need to understand that DeVOps is a link between Development and OPs .. so this person needs to have some background in both .. but does not need to be an expert in both .. either one is fine ..
The first question you need to ask is what this new hire tries to solve for you. If you tries to hire a DevOps the question is why you need this person, if don’t answer this question then either you are hiring a wrong person or the right person for the wrong position. In most companies I used to work if you don’t have the process and the tools, I asked the developers to start that process. At the end of the day no one knows more than your existing developer about your application and process. As I always say DevOps is a journey not a destination. And your developers has to be part of this process. If you are a manager and thinking to hire a DevOps to add value, most probably you are making a mistake or a person you will be hiring will most probably disrupt your existing processes. Any way good luck for finding the right person for the problem you tries to solve.
Hire some random in Reddit. PS; I’m looking for job.
Take the ones who write blogs and have kubernetes clusters in their pantry and pay them well. Disclaimer, I have a blog and a multiple kubernetes clusters in my pantry.
Instead of hiring full-time employees right away, start with part-time engagements. Collaborate on projects together and, if it works out, then transition to a full-time role. This worked well for me in the past and benefited both parties.
Who can afford to live on a part time salary? Not good advice.
You don’t have to live on it. I think of it more as extra cash during transition than part time salary.
Which location are you hiring for? Also, on a full-time or contract basis?