Hiring Remote

Running a remote team means you hire with a remote process. What does that hiring process look like? In this post, we’re going to explore a few aspects of the flow and how we handle them in a virtual context. We’ll use an example of hiring a front end developer so we’ll include assessing their technical skills.

Team-Driven

Hiring is best as a team process. The composition of this group should include peers from the team that is hiring along with the hiring manager. In this example, I handle the initial screening and two of our front end developers handle the technical assessment. Involving a team provides more perspective on all the candidates and helps neutralize biases.

Grading Candidates

You need an explicit system that the team can all understand and use to fairly evaluate your candidates. For this, we use a hiring rubric. This is a list of desirable qualities or attributes that you would like to see in a candidate. These qualities are both technical and non-technical and encompass all the qualities that matter for someone to do their job well. The rubric should vary some by position but will likely have a core list of qualities that a good remote candidate should possess, such as autonomy, empathy, self-motivation, communication, curiosity, and problem-solving.

As part of the rubric, you will establish a scale to evaluate each quality. We use a 5 point scale with 1 meaning novice, no experience or strong no, depending on the quality being assessed. A 5 would indicate expertise, mastery or a strong yes. Each quality should have a description to inform the team what it encompasses and guidance on how to score.

You use the rubric to filter through resumes, focus your questions on your screening calls, and get detailed impressions during your technical interviews. The goal with all of these steps is to be able to rate each attribute with confidence. We use Google Spreadsheets to make a rubric template and copies of it for each candidate. Each hiring team member gets a column to score based on their experience.

The rubric isn’t there to make the hiring decision a simple mathematical formula but to give you some objectivity and metrics to a process that often is driven primarily by gut-feel.

Interviewing process

In our current example, the interviewing process of a front end developer follows this flow: screening call with hiring manager, technical take-home exercise, two technical pairing sessions, and final interview.

An entry level position will require less rigorous steps than a senior type position. We add additional steps for more senior positions to provide a deeper understanding of the candidates. I also want this process to include multiple steps that can expose the candidates to a diverse cross-section of the team.

It’s important to note that your time and the candidate’s time is valuable. I don’t want to waste either. This is why it’s important to get crystal clear on your process and how that helps you find the right candidate based on your rubric. If a candidate clearly isn’t a fit, don’t advance them in your process.

Screening

The screening call doesn’t happen over a phone call like it does in traditional hiring, it happens over video. We prefer Zoom and it’s surprising how well a video call can perform for screening your candidates. Most people have access to good bandwidth so the quality of video calls is usually solid.

Though you might feel a face-to-face interview offers higher fidelity than a video call, I see other benefits that sway the video call as preferred to face-to-face, even if that’s an option.

First, it’s incredibly convenient. Neither person needs to travel anywhere so it saves time that way. You can have multiple people join the call if necessary and no one has to be in the same place.

Second, conducting the interview through video allows the candidate to pick a place that is comfortable for them. Most will do the interview from their home, which will be a place of comfort compared to visiting your office. This helps to eliminate the nervous factor. I don’t want to make a decision or get a strong impression of someone who’s incredibly nervous and not themselves. That’s not how they’ll be on the job hired, so anything I can do to make them more at ease and themselves is a plus.

Third, how well do they handle video? If they struggle with it or haven’t made proper preparation to be in a quiet space with sufficient bandwidth, then it raises a red flag for me. Especially since a remote team will do so much work on video calls.

I prefer screening calls to be short and sweet, 30 minutes tops. The goal is to figure out if this candidate is in the running before you involve more of their time and effort as well as your team’s valuable time.

Technical exercise

Once a candidate makes it past the screen, then it’s time to move to a hands-on exercise that they finish on their own time. For a technical position like software developer, this is a crucial step. I want most of the assessment around technical skill to not be driven by whiteboard exercises or interview questions but by seeing a small example of their work.

It’s important to stress that we want this take-home project to be from scratch with directions provided after the screening call. If you just review someone’s Github profile or look at an existing project, you don’t know how much time or outside assistance went into it.

The first aspect is the instructions of the exercise. We want the instructions to be sufficient to get started but not be too prescriptive on how to solve the problem. They may be vague in parts but this is purposeful as we want to see how the candidate interprets them. We also want it to mirror the kind of work we do and it’s often the case that feature requests are not fully spelled out. We look to see what sort of clarifying questions they ask and how they choose to follow the instructions. If they need a lot of hand-holding then that’s a sign of how they’ll be on the job.

We don’t want the project to take too long but it should demonstrate the important parts of the skill set they’ll need for the position. We’ve found something in the 4-8 hour range feels reasonable.

Technical interviews

For our technical interviews, we prefer to do two pairing sessions remotely that run in the 1.5 to 2 hour range.

The first session is a follow-up to the take-home exercise they submitted. We start off this session with a discussion about their submission and why they implemented it the way they did. I stress to the team to not be judgmental but try to understand their thought process and intentions with the exercise. Then we look to extend it with a change in requirements that usually forces the candidate to rethink their solution. We want to observe how they problem solve the issue.

The second session involves a short technical task that the technical members of the hiring team have come up with. Ideally, the task will shed light on a different part of their skill set than the first session covered.

There are some interesting aspects to running the technical evaluation this way.

We ask the candidate to use their own computer. This will help in a few ways. First, since this is their own machine, they will be most comfortable developing software on it. It removes the extra stress and uncertainty around using someone else’s computer to do the technical exercise. Second, as we’ll be in a remote pairing scenario, our team member will see how well they collaborate in that mode. This mimics how it’ll be when they’re part of the team so it’s good to see that in practice. Third, we can assess how optimized their development environment is. How well do they use their editor and the command line? All important things to assess and it’s easily done during this pairing session.

When pairing, our team member will primarily observe as we want the candidate to do the driving. We do want to see how well they communicate and work with a pair. How well do they take suggestions or feedback on what they’re doing? It’s okay for our team member to help some, it should feel natural after all, but they shouldn’t take over. Ultimately, the pair can evaluate if this is someone they’d want to work with on a regular basis.

Another important piece to this is we want this session to be very much like how we work normally. The candidate should get a taste of what to expect and thus they can help decide if this is a good job for them to take. Often times, the conversation may drift to asking what it’s like to work at Haught Codeworks and I encourage our team members to have an honest conversation with them.

The goal, in the end, is for each team member to fill out as much of the rubric as they can after their session.

Final Selection

We close the interviewing process with a final interview over a video call that follows up on any aspect of the candidate that the hiring team wants more clarity on. We also use that interview to explore the details of the position and encourage more of their questions. Upon completion, the hiring team completes the rubric for the candidate and adds any important observations they made during the interview process.

Once the current candidates have completed the process and you have a sufficient pool of qualified finalists, the hiring team reconvenes over a video call to review their rubrics. From there, the team will select the candidate to make an offer to.

Remote vs Face-to-Face

I have heard from some that feel face-to-face is the only way to conduct your interview process. We’ve run our hiring process completely remote for several years now and haven’t felt it hindered our ability to hire great team members. Since we’re a remote team, knowing that potential team members can work effectively with us through this hiring process is key.

For co-located teams, you can still borrow many of our remote-centric processes and adapt them to how you hire. Starting the interviewing process remote then moving to onsite as you narrow down your candidates feels like a natural compromise between both approaches.