Hiring Challenges

We’re always hiring at Puppet Labs. We’ve gone from 10 staff to 75 odd staff in two years. And it just doesn’t stop. And hiring is hard work. It’s time-consuming to find the candidates and then time-consuming to sift through the hundreds of candidates to find the gems in the rough. I don’t credit myself with overly awesome skills in many areas (y’all have seen my code…) but I think I do have a pretty good eye for talent. Part of it is experience and part of it is just gut feel. I know a couple of minutes into most phone screens or interviews whether someone will be a good hire or not. I sometimes can’t work out exactly what I am hiring them for but I know they will be an asset.

But getting to that phone screen or in person interview is hard. We get a lot of candidates for some roles.¹ This results in two problems:

• Finding the time to screen, and
• Selecting the good candidates to move forward.

At Puppet Labs we try to solve both issues with one technique: challenging the candidates. We ask candidates to demonstrate a variety of their skills to us before we progress them to interview. This isn’t a new technique but it has very quickly proved to be a powerful differentiator for us in recruiting.

So how does it help us take care of these issues? Firstly, it cuts down the number of people who are just fishing. Sending in your resume to a company and even mocking up a decent cover letter that is generic enough for most Ops/SysAdmin positions is pretty easy. Ask these candidates to actually do something to prove themselves and they tend to drop out (or wheedle to avoid the task which is instant fail).

Secondly, resumes suck. They pretty much all fall into two broad categories:

• The candidate is lying, or
• The candidate has a crap resume.

It amazes me how little justice people do themselves with their resumes and I am equally amazed how people put stupid and easily tested falsehoods on their resumes too. So instead by asking the candidate to actually do a set of tasks that might take some brain power reveals both people who have undersold themselves and those who have lied about their experiences.

So what do the challenges look like? We do two types of challenges:

• Written exercises, and
• Technical problem solving.

Our written exercises tend to be activities like:

“Install Puppet Enterprise and tell us how the experience went. Also what are three things you’d improve about the installation user experience."

Not only is this a good indicator of basic technical skills it demonstrates that the candidate can string a sentence together.² The only limit we place is on the length of the response - no more than a page. Otherwise you’re back in the morass of hours of screening.

Our technical challenges tend be coding-based with a focus on Operations and SysAdmin tools and skills. They include a mix of tasks like:

• Develop a Nagios plugin
• Develop a Munin plugins
• Write scripts to manipulate data

We let the candidate choose the language they want to use to respond and then evaluate their responses as a group.³ We look for some key characteristics in how they solve the technical problems:

• Functionality
• Elegance
• Re-usability
• Documentation and code comments

Unlike many Engineering coding challenges these are all short, simple challenges.⁴ Usually 50-100 lines of code maximum including help and comments. Easy to complete and easy to review. It’s also proven to be remarkable what a handful of lines of code can tell you about the candidate.

If the candidate does well in both challenges we’ve got a pretty good that they have skills that we need. We can then advance them to a phone interview and start working out whether they are a cultural and professional fit with the company.

Overall, this process has saved us considerable pain and I’d strongly recommend looking at doing something similar for your own hiring.