Developer hiring. For both parties, it’s a stress-inducing and potentially life-changing decision. And yet, they each have around 4 hours to gather enough info to make that decision. How do you use that time? Are you asking questions that prove the competency you need? How do you compare candidates?
After a long stream of unsuccessful on-site interviews, we realized we needed to change how our hiring funnel worked. When I took over our hiring funnel, we were disorganized and wasting a lot of time. In the last few months, however, we’ve had a lot more success. Not in the actual quantity of candidates being hired, but in the quality of the interview experience for everyone involved. Less interviewing and more suitable candidates; how did we do it?
Asking the Right Questions
The most impactful improvement came from the questions themselves. At the time, some of our engineers had their favorite questions to ask, but most would just pick from a list of sample interview questions found online. Often, our questions weren’t relevant to the position or candidate. They told us nothing about how a candidate would react to building a microservice, or their ability to test or debug code.
So we gathered together and made a list of all of the skills we want each type of candidate to have. DevOps hires should have AWS experience, backend hires should know how to make a simple REST API, etc. Testing for skills like ability to work in a team and perseverance are less straightforward, but just as important as testing for domain experience in a language or stack. We judge their ability to work in a team by how well they communicate while solving the problems. Does the candidate involve us in their thought process, or do they keep everything internal? Do they give up at the first sign of issues, or do they persevere?
Standardizing Our Interview Steps
Once we had the right questions to ask, we needed a way to compare results. Best way to do that was to standardize the process. We have three steps to our interviews: a phone screen, a technical screen, and an on-site interview.
Phone screens are done with an engineer over the phone to get a feel for the candidate, ask questions about their history and experiences, and find out how interested they are in what we do. We listed out the questions we cared about, and created a Google Form that we fill out with the candidate’s answers. These are visible to anyone, and are kept for any of the future interviewers to go over. Creating this also gave us a script to reference while in the interview, so no matter who performed it, the same questions were always asked.
For tech screens, we only have an hour to check their understanding, so we have to spend that time understanding their competency. Depending on what they know, or say they know, we ask questions about simple JS (array functions), advanced JS (scope, closure), regular expressions, AngularJS, and some light algorithms. If the candidate doesn’t have JS experience, we give them all the info they would need to know, and see if they can figure it out. We use CodePen for these interviews, so all of the work the candidate does is saved for later analysis.
In-person technical interviews are where most of our engineers get to meet the candidate. Each interviewer asks a question based on a specific skill they specialize in. We go in pairs, spending 10 minutes or so getting to know each other and 10 minutes at the end for any follow-up questions. Most of the hour is spent observing (and working with) the candidate to see how they solve problems. Once all of the interviews are done, it’s time to make the decision.
Deciding Unanimously
When making the final decision, we give everyone an equal say, and everyone has to agree. When the interview is over, we all gather in a circle in a conference room. To help eliminate any external bias, we all close our eyes, count to three, and either give them a thumbs up, sideways, or down. If no one is thumbs up, then it means the candidate wasn’t a good fit. When this happens, it means we need to iterate on our process, just like we do with our software. If no one is thumbs down, and most are thumbs up, then it’s a pretty solid Yes. If there is a mix, then we have a discussion. When everyone has made their statements, we consider the new information and vote again. This is repeated until we have a unanimous decision. This leads to a lot of interesting conversations, but always leads to a clear answer.
Conclusion
If you’ve never had to hire anyone before, hiring engineering talent can seem like an impossible and time-consuming task. If you take the time to understand the problem, build up some tools, and flesh out the story, you’ll have success. When I took over, we didn’t really know what we were looking for in a candidate. Our process was disorganized and just wasted everyone’s time. Now we spend less time interviewing and more time with strong candidates. Maybe these tips can help do the same for you?