At a high level the interviewing process we use looks like this:
- Review resumes
- Screening call
- Technical interview
- Final interview
Depending on the position and how the hiring decision is made, you'll want to adjust it. My philosophy is that I don't want to waste my time or the interviewees time so I look to fail fast. Thus how I handle each step is to get through the important stuff that might be a deal killer on either side.
- Review resumes
Before I bother to set up a screening call, is the resume even close to what we're looking to hire. Before you do this, have a rubric in mind on minimum requirements. If you set the minimum too high, then you'll skip over more resumes. You set it too low and you'll be spending more time on screening calls. If I feel confident someone is not a fit, I'm not going to waste their time and get their hopes up by setting up a screening call.
A quick note on resumes, I tend to not be too hard on them. Many resumes are terrible but as I read them I try to piece together the candidate's story. From this there are things I'm curious about so questions to ask pop up.
- Screening call
I like to keep this to 30 minutes, which can be hard but I suggest you stick to that. If you have a lot of interest, trying to fit in 10+ screening calls and you'll be very thankful you did. I have a tendency to want to chat with people so it's hard for me to keep it short.
I use a conversational style and do this over a video call. Since we're a remote team, our candidate's ability to use a video call is pretty important. I also like that it doesn't require anyone to drive and commit more time around the screening process.
My goals are to get a sense of this person and how they're likely to work on the team. I try to figure out where this person is technically based on their experience and self assessment. I rarely throw out technical questions to answer.
I also make sure to spend some time on who we are so they can be clear what they're getting into. This is super important because folks will have their assumptions/expectations and I'd like the purpose and vision of the team to be crystal clear.
As you can guess, I do all these things to make sure there are no show stoppers on either side before proceeding.
I have some sample questions that I ask but it varies by position and I will often follow interesting responses with follow-up questions so the conversation can go in unexpected directions.
I do have a rubric in mind so I do try to make sure I touch on all the important parts before the interview is over. Many times, I'll have to bail on less important questions if our time is passing too quickly. The goal by the end is being able to rate the candidate on the position's rubric.
- Technical interview
This part of the process is where you vet their technical skills and non-technical skills that are required for the position. There are a lot of options here.
I do like some sort of take home exercise that they can work on after they pass the screening call. The purpose of the exercise is to get a sense technically of what they can do before we go further. It also allows the candidate to take their time to complete it without the stress of doing it on the spot. I try to keep any take home exercise to a couple hours so I'm not asking them to spend an entire weekend prepping. We found it easiest when the 'submission' of the exercise is a PR. It does mean we need to setup a special repo for them to access but it's pretty nice if you're willing to prep that. Another variation we've started to do more is make their exercise to review a PR.
Next, we do 1 or 2 pairing sessions where we work on a real coding exercising. I typically grab an open source project that I know. First, I don't want to even suggest we're using this step to get 'free work' out of them. Second, there are confidentiality concerns that you may violate by letting them work on either your product or one of your clients' projects.
The reason I like pairing is that it's more relaxed than a typical 'whiteboard' exercise and it's can most closely match the actual work they'll be expected to do. I have them pair with members of the team, not me, so that they're pairing with people they'll work alongside if hired. This has given the team an excellent sense of what this person will be like to work with.
There's quite a bit you can get into in how to run a pairing technical interview but the short version is that you just want to probed all the important aspects of the job so the pair can fill out the technical rubric.
We do two pairing sessions of 2 hours so that two different perspectives can be explored. We also vary the kind of problem the pair is working on so that helps to paint a broader picture of the candidate's skills. Another thing that we do here is I prefer one of the pairs to be on the junior end of things while the other is a senior. I also love it if one of the pairs is a woman as that'll show how well this person can work with a woman teammate (sdaly you'd be surprised how often this exposes something).
Depending on the position, we'll have a final technical interview that does a deep dive on technology and how they've worked on projects. I follow a conversational style like in the screening call except I allow a full hour and we get into the nitty gritty about projects.
Another aspect to consider for this phase is how important it is for them to have all the skills you're testing for. I expect folks will learn on the job so I'm trying to figure out how far along they are in each aspect of the job. I'm more willing to take someone that might be junior in some aspects as I know our team's mentoring culture can accommodate that. If you're hiring someone to be lead and will need to work independent then that's not as much of an option. So know where your team and this position is on that spectrum.
I would also like to stress that I find it just important to know how they're going to work on the team. Are they a jerk? Do they work well with others? Have they worked on this kind of a team with this sort of process? Some candidates will really struggle if those things aren't close to what they're comfortable with. Like the technical skills, most all of this can be learned/changed but are you ready to do that work?
- Final interview
After the technical interview portion is complete, we typically have a final interview that can cover anything not sufficiently addressed. This is where you'll typically get into job duties, career growth opportunities on the team, compensation and benefits. The candidate will usually have a lot of questions for me at this point.