A Detailed Hiring Process

Erik Barbara

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."

Actions taken

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."


"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."

Lessons learned

  • "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."

Be notified about next articles from Erik Barbara

Erik Barbara

Engineering Director at Duo Security

Engineering ManagementTechnical SkillsProgrammingSoftware DevelopmentCareer GrowthCareer ProgressionIndividual Contributor RolesStaff EngineerTech LeadEngineering Manager

Connect and Learn with the Best Eng Leaders

We will send you a weekly newsletter with new mentors, circles, peer groups, content, webinars,bounties and free events.


HomeCircles1-on-1 MentorshipBounties

© 2024 Plato. All rights reserved

LoginSign up