A Detailed Hiring Process
2 July, 2019
Engineering Director at Duo Security
I think hiring is one of the most important things we do as managers. When we are really hiring strongly I have told my managers that it's okay during those times to spend 25 or even 50% of their time on hiring. This includes recruiting, sourcing, and interviewing. In other words, the hiring process is a high level activity and I put a high value on it. Plus, we don't want to get it wrong. Hiring the wrong person can be very expensive for the organization. Thus, below I have outlined how I conduct my current hiring process and the reasons why I do it this way.
The Process: Behavioral screen After our recruiter has talked to someone, the first step in our process is for that candidate to have a one-hour conversation with a manager. This can be done either via phone or video call. The conversation is centered around how that individual person works. It is not so much a get-to-know-you conversation as it is about understanding their work behavior. For example, if I am interviewing a developer for a senior-level position I will ask them to tell me about the last project that he/she planned and led. I want to hear about the whole process. Technical screen If they passed the one-hour phone conversation than I do another follow-up but on the technical side. I have one of my engineers do this part (you may or may not be in a place where one of your engineers can do the same). We use a tool called CoderPad with the focus being on coding skills. For example, we do a lot of data manipulation so we ask questions around manipulating the types of data we use. I don't like toy problems so I try to make the problems as realistic as possible. There's three reasons for that. One, I'm trying to deduce if this person can code or not. As I'm sure many have encountered, some people think or say they can code but it doesn't meet the standard for your company. Two, I want to know if they can deal with some amount of ambiguity around the question. I don't want the questions to be complete abstract but in the real world you have problems that need to be figured out. And three, by having a real life problem I'm trying to reduce the nerves that the candidate feels in the interview. Through anchoring the problem somewhat in the real world - as opposed to theoretical problems - we test the abilities that we really want to see in a strong candidate. On-site If the candidate passes both of the behavioral and technical screens then we will bring them in for the on-site portion. This is 5-6 hours worth of interviews depending on the position that we are trying to fill. I have made a prep sheet so that the panels are kept much the same.
- Hours 1 & 2: Behavioral interviews
- There are two hours of assessing the candidates behavior. Each of these hour interviews are conducted by different people. I designed a rubric for the answers in which it outlines what constitutes a good response and what constitutes a poor one. Afterwards the interviewer can take notes which we then review along with the rubric score to determine the quality of their overall behavior.
- Hour 3: Architectural interview
- We eliminate this portion of the interview if the candidate is more junior. Essentially, we ask that the individual design a link shortening system from scratch, similar to bit.ly. We are looking to know is the candidate is asking clarifying questions about the architecture and the requirements of what they he/she has been asked to design. There will also be relevant follow-up questions.
- Hour 4: Coding exercises
- We do another hour long set of coding. This portion is a bit harder than the phone screening.
- Hour 5: Lunch
- Because the interviews last 4-5 hours long, we include an hour lunch break. This gives the candidate the chance to decompress through the middle of the day, have a break and eat lunch, and ask the interviewers any questions they may have. Usually, though, what happens is it's 50 minutes of the team talking and just the remaining 10 minutes for the candidate. After each interview I require that interviewers fill out a scorecard on the candidate. I'm not looking for a simple Yes or No about hiring that person, but I want pretty detailed information and notes on the individual and on the interview. Within one business day we have interview debriefings. With scorecards and notes in hand, we meet and go through interview by interview on a whiteboard. This part of the process is twofold. One, it allows me as a hiring manager to calibrate expectations and make sure that we are maintaining a high caliber of interviewing. Also it ensures that we're not ruling out candidates for arbitrary reasons. Second, it gives interviewers the time and space to uphold their scores and their notes. In this degree, when my team picks up on subtle matters of a candidate, we can discuss the effects it has on the individual's candidacy and their potentiality to integrate with the organization. Based on the debriefing I as the hiring manager make the decision whether to proceed or not proceed with hiring the candidate. My director and VP also have to approve, though typically they trust me, especially with the interviewers scorecards and notes to back me up.
- Standardize the process as much as possible. This is possible for us because we hire for the same role over and over again. Variations come into play when there is seniority involved. We tweak the interview a little bit for seniority, but actually not that much.
- Interview questions are the same for each candidate, although we will iterate and improve on them when necessary. So the questions are written and not derived from scratch during each interview.
- I don't do consensus hiring. Thus during the debriefing it doesn't always have to be a unanimous Yes or No. However, if a candidate received all yeses but a No for technical reasons, then I will not hire that person. If they can't code then it's a strong No from me.
- The debrief lets me ask questions and clarify why people said Yes or No to a candidate. If only one person gave the candidate a Yes, then I'm probably not going to proceed. Or if someone said they answered No but it was a weak No, I would ask if they felt like they could still work with that person.
Himanshu Gahlot, Director of Engineering at Lambda School, explains how he improved the hiring process at his new company by applying the knowledge he acquired working on different teams with different hiring processes in place.
Director of Engineering at Lambda School
Mason Mclead, CTO at Software.com, highlights all the advantages of hiring at once a group of people who have already worked together.
CTO at Software.com
Brian Hough, CTO at Beam Dental, recalls his company’s massive scale from only 12 to over 100 employees including engineers, product managers, designers, and leaders in under 12 months and highlights how hiring in the Midwest differs from hiring on the coasts.
CTO at Beam Dental
Alessandro Pintaudi, Product Management Director at Payfit, dissects all the aspects of the hiring process that will enable you to hire a product person who will take your product to the next level.
Product Management Director at PayFit
Peter Fedorocko, Director of Engineering at Workday, recalls his early efforts to build a large, multilevel engineering organization in a short period of time -- one step at a time.
Director of Engineering at Workday
You're a great engineer.
Become a great engineering leader.
Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.