Hiring Engineers is hard. Here’s how we made it easier.
I’ve thought a lot about my experiences hiring and getting hired as an engineer, and have come to the conclusion: It’s really hard. The candidate has little idea what to expect, ranging from a coffee—or beer—to a 6-hour-long-write-code-on-a-white-board marathon to prove they listened in school. Meanwhile, the interviewer doesn’t know how to find the traits they care about—which is often not pure Computer Science knowledge. The role requires someone who can plan, execute, care deeply, and communicate effectively. How do you learn that from a 1- or 6-hour interview?
In the end, you’ll have to make a subjective decision based on a relatively small amount of time with the candidate. The good news is that the right process can make things MUCH easier and more consistent. You’ll have to find a process that works for your team and answers as many relevant questions about a candidate as possible. Through a lot of research and “trial and error,” we found a system that has significantly improved our hiring process. This system provides both relevant answers about candidates and ensures the team is all 👍 with confidence.
Step 1: What do you want?
Even before publishing your job post, you need to determine what attributes are required for the role. This isn’t as simple as “Knows Scala”, “Expert iOS Engineer”, or “Is Smart”. It should be more focused on the expectations you have for anyone in that role. Think more along the lines of “High attention to detail”, “Curious about understanding new technology”, “Has an iterative process”, or “Has experience with building teams”. Write these attributes down in a shared document for the specific role—the role document. Your team will be using this doc as the guide for what questions need to be answered about a potential candidate. Even the job posting should be a well-written extrapolation of this document and the technologies your team uses day to day.
Step 2: Phone Screen
Great! You’ve found a candidate that seems to fit the role requirements. Review your role document before your call. You wouldn’t ask these questions directly of course, but your goal is to ask questions that give you a rough idea where they stand in reference to the role document and technologies required. This is a good time to review their resume and talk about their experiences, hear stories, and listen to how they talk about their work and career. Remember, the candidate needs to interview you as well, so make sure you leave time to answer their questions. The call should last about 30–60 minutes. Aim to discover that the candidate’s values line up with your team, they have the relevant technical skills, and look for attributes that line up with the role document.
Step 3: Code Sample
Next, you send a coding project to the candidate. You should maintain an arsenal of several different coding challenges that are small-scale samples of real problems that your team tackles. The project you send should take no more than 1–2 hours for the candidate to complete and should highlight a cross-section of the skills required for the role. The candidate should submit the project via a Github or Bitbucket repository, which is a skill in itself.
This can be hard because you are asking someone to work on personal time, especially before a full technical interview. But when alternatives are like the aforementioned white board quiz, a take-home project is typically more representative of how an engineer will perform on the job when there’s no interviewer staring them down, they have the freedom to research, and they can use their own tools.
Your goal here is to answer lightweight programming questions like, “can they code in a way that’s clear?”, “does it look like they copy-pasted from samples?”,and “did they really understand the problem?”. Finally, you need to review the role document—again—to make sure the candidate is still on target with what your team needs.
Step 4: In-Person Interview Prep
Before you begin interviewing the candidate, sit down with everyone involved in this interview process. This is your interview team. This team will help decide whether you should hire the candidate. They all need to have access to the role document, any notes about the candidate, and—if they are on the engineering side of the team—the code sample.
At this point, you have a pretty good impression of the candidate but probably have a lot of questions remaining. The interview team should take about 30 minutes and review what questions about the candidate are unanswered or require clarity. Each member should have a specific role (technical, fit, etc) in the interview such that they help answer these remaining questions. For example, if our concern was that a candidate doesn’t have attention to detail, we’d allocate time to working through a problem with them specifically to see how they break it down. At the end of this 30 min meeting, the entire interview team should be aware of everyone’s concerns and their role in the process.
The secret sauce here is: This will look different for each candidate. You are effectively making a custom interview for each candidate.
Step 5: In-Person Interview
The day of the interview! One team member, probably the hiring manager, should act as M.C. to make sure the candidate is comfortable. That person should also give the candidate a brief overview of the agenda so they know what to expect. Each interview should last about 30–60 minutes, so ask the candidate to prepare for a 2–3 hour time slot.
Interview 1, Technical Interviews: review the candidate’s understanding of your company’s technical challenges and verify their ability to solve and think about problems. There should be 2–3 technical interviews that focus on different areas relevant to your engineering team. One might be a deep dive into technology to verify the candidate’s understanding of the subject, while another could be solving a specific problem, etc.
Interview 2, Fit Interviews: How do they think about teams, process, getting things done. Would they fit on our team? Would you grab a beer or coffee with them on a random Thursday? Don’t ignore this step. You are going to be spending most of your waking hours with this person — do yourself a favor and make sure you can have a good time together.
By the end of these interviews, your team should be able to answer questions like “Does the candidate fit on our team?”, “Are they technically ready to get started?”,“Do their skills match the role document?” and “Would I grab a beer or coffee with this person for fun?”
Step 6: In-Person Interview Debrief
The team sits down again, for about 30 minutes or less, and reviews the interviews together. Someone, likely the hiring manager again, should guide a conversation about the candidate and determine if all the questions have been answered.
At the end of this debrief, everyone should be able to give their opinion on hiring the individual. Usually this is a 👍, 👎, or a 👍 with unanswered questions. That last option is rare, but if necessary go back to step 4 and repeat. If anyone on the team is 👎 and remains unconvinced by the debrief’s guided conversation, you should probably turn the candidate down.
Step 7: Reference Checks
These are an art in themselves as most people only give references they know will be positive. Prioritize stories about the candidate with questions like “Tell me about a time when you worked on a specific project together? What was your role? What was the candidate’s role? What was the biggest challenge you faced on this project and how did candidate work through it?”. The goal is to verify what you learned about them. Especially try to corroborate any of the flaws or idiosyncrasies that came up during the interviews to validate the reference’s candidness.
Finally, if the candidate fits the role document and passes your fit interview test, you make an offer!
I’ve done several different processes and this has been the best cross-section of finding information about the candidate while not putting them through an uninformative and painful process. You are being interviewed, too — so ensure that the candidate has a fun, pleasant, and challenging experience interviewing with your team.
Interviewing is hard and relies on a lot of subjective opinions. The best way to get through it is to have clear goals, clear communication, and a plan for answering the right questions about the candidate.