DevOps has achieved buzz word status. Job descriptions and resumes are chock full of DevOps descriptors, tools and processes. Job descriptions are being built around DevOps and applicants are building their resumes around DevOps. Resume searches with DevOps keywords return thousands of hits. This is a sure sign of the impact DevOps is having. And yet, this shift towards DevOps has flooded the job market with "DevOps compliant" resumes. This adds a challenge when you're trying to find the right people to join your DevOps team.
And let's not forget, PEOPLE are the most important aspect to successfully implementing DevOps. Getting the right people on-board is a must.
So, here's what I've been doing--I break up the interview process into two or three stages:
- Stage 1: Initial phone screen
- 45 minutes
- An initial phone screen is an undemanding way in time and effort to determine whether or not a candidate with a resume of interest, is really that person on their resume!
- Stage 2: In-person tech and team review
- 3-4 hours
- The meat of an interview is a face-to-face (zoom calls included) review by the team to drill down on their technical capabilities, and more importantly, what and how they do things. Matching a candidates temperament with the company's culture is vital for success. A cowboy that jumps in and makes changes, may not be the right person in a strictly managed, process oriented environment. But, they might make an ideal candidate for many start-ups.
- Stage 3: Final interview (optional) and negotiation
- Another round of interviews may be appropriate depending on the size of the organization, and who has an interest. Often senior managers will want to meet all new hires.
Then, there are four broad categories that I try to assess when interviewing. But, first, I always ask these two questions no matter who I am interviewing:
- What do you know about the company? (have you looked at our website? )
- In your own words, how would you describe the position? (did you read the job description)?
This is in part housekeeping. Recruiters and schedulers make mistakes. Or the job description may have changed since the applicant was engaged. But these questions can also reveal an applicants interest in the job. That's important, because I want to work with with people that take the initiative to learn about the company offering the job.
Okay, so back to the four broad categories I use to assess candidates. They are:
- Ownership
- Responsibility
- Technology
- Process
But, before I explain those categories, I have a few "go to" questions I ask every candidate looking for a technical position. These questions are meant to take a quick and deep dive into basic skills required by successful Ops people. If a candidate has done the work, these are simple questions. But if a candidate struggles with these questions, they likely won't recover during the remainder of the interview.
Linux: What is load average?
Networking: What is a subnet mask?
Python (scripting): What's the difference between a "list" and a "tuple?"
Security: What is risk?
Ok, back to those four categories, and specific questions I use to get at these categories:
- Ownership -- Or "work ethic and philosophy." That's somewhat officious, but what I'm trying to get at is, what excites the candidate? And what do they think of the work? Or how do they go about getting the work done? Some questions:
- What do you consider success?
- How do you know when you've succeeded?
- What is DevOps?
- Talk about your interests? Do you have tech interests outside of work? Associations, projects?
- Responsibility -- Or role. What have you done? How much of it? And who did you do it with?
- What size teams have you worked with or managed?
Talk about the environments you worked in: - How large have they been?
- How many environments?
- What networking is involved?
- How many systems?
- How much application data are you storing?
- What role did you play in setting up the environment? And its upkeep?
- What's your hand's-on comfort?
- Are you on the on-call rotation?
- Technology -- Or skills: depth and breadth. These questions are meant to get a detailed picture of the candidates skills and the skills required for the job:
- Server Configuration Management
- What experience do you have with Server Configuration Management? Docker, Check, Puppet, etc?
- Describe systems you worked with and your involvement in the design, setup, and their maintenance
- Containerization:
- Are you familiar with Docker or other container technologies?
- If so, describe the setups you have worked with and your involvement in the design, setup, and maintenance of those systems. Did your involvement include re-architecting existing VM based deployments? If so, describe.
- Cloud:
- What cloud companies have you used? AWS, Google, Azure?
- Describe the cloud services you've used? For example, in AWS: EC2, S3, EKS, ECR, etc
- Process -- How do you do the work?
- Collaboration? Ticket management? Agile, kanban?
- Build and deployment:
- Describe build and deployment systems you've worked with
- Release process and cadence
- Monitoring:
- What is your current monitoring setup (Nagios/Sensu, commercial)?
- How is it configured?
- A specific question like, "how do you determine the threshold for load alerts?" can lead to open ended responses
- Backups
- What is your backup plan?
- Do you have a committed RTO and RPO?
- Have you tested your backup plan?
- Log aggregation?
Another approach you can weave into the questions above, is asking about real world examples. Real world examples are problems you have encountered. Setup the candidate with what you saw initially, and see where the candidate goes with that. This will give you insight into their experience and problem solving capabilities.
These categories of interest and questions have served me well. But, one warning: if you are playing "gotcha" with questions and candidates, you've lost your way. Interviews are a dialog. The dialog--the engagement--you have with a candidate is so much more important than the questions. Interviewing is meant to find people you want to work with and that want to work with you. Be considerate. Be prepared to answer your own questions, and help a candidate that's stuck. Interviews are stressful. Sometimes, people need another beat, and then they're great. Remember: you are representing your company.
Always, always, always treat candidates with respect.
