When screening developers at a startup, you have competing goals. On the one hand, you have limited resources to dedicate to the hiring process, so you want a process that minimizes the work for you and your team. On the other hand, you have a challenging time attracting talented developers, so you don’t want to have a process that puts such a burden on prospective candidates as to scare them off. Having a well defined screening process can help move you towards both these goals though. This guide will outline a basic screening process, which you can adapt to your own needs.
Stages in a screening process
The exact steps in the screening process will vary from company to company, but will consist of roughly the following.
Before you even start soliciting applications, set up some system for tracking applications as they move through your pipeline. If you don’t have a system in place, its easy to lose track of people, and the last thing you want to do is miss out on a great developer just because you forgot to follow up with them.
Although there are plenty of dedicated application tracking systems, in the beginning you can get away with something home-brewed. If you’re already using something like Trello for task management, creating a new board is a quick and dirty way of tracking developer applications.
An application from a developer, be it via your company’s homepage or a job listing point, is the start of the screening process.
The challenge with this stage is that even candidates who make poor applications can turn out to be great developers. Furthermore, as a startup, candidates that don’t look good on paper but turn out to have great aptitude for development can be nuggets of gold, as you’re less likely to have to compete over them than developers with illustrious career histories.
My recommendation is at this stage to only filter out people who are clearly a waste of time: those with no relevant skills nor a cover letter that is custom tailored to your organization. For anyone you filter out, I still recommend quickly following up with them with a rejection email. It could be as simple as:
Thanks for your application. Unfortunately it doesn’t quite match what we’re looking for right now. We’ll keep your application on file, and should something match you in the future, we’ll be in touch.
Phone call with candidate
Should you not outright reject someone in the initial screening of their resume, as a next step, set up a quick (five to ten minute) phone call with the candidate. One useful service for scheduling these calls is Calendly.
During the call, you want to answer any questions a candidate has, and make sure your both on the same page for what the position entails. Especially if you have a limited budget, this can also be a good time to bring up the salary range you’re offering for the position.
Before going through a more intensive interview, you want to ensure that the candidate can actually code. If the candidate already has public evidence of this, such as an open source project they can point to, you can skip this step. Otherwise, ask candidates to solve a simple programming challenge on their own time.
With this task you’re trying to set a minimum bar, so there’s no need for something overly complicated. You’re aiming for a task that would take a junior developer at most an hour to do. Ideally, it is also something that’s relevant to the job itself, so a stripped down version of a problem you’ve faced works great.
An interesting alternative approach is to ask candidates to make a pull request on an open source project. This does put more of a burden on potential applicants, but it also has a benefit to them and the open source community as well.
For candidates who pass the coding test, you’ll want to perform a more in depth interview. How best to perform a technical interview is such a broad topic that I’ll leave it to another article for now.
After you’ve screened the candidate, you’ll need to decide whether or not to hire them.
Besides the steps themselves, you also want to work to make your process overall a good experience for those involved. Even if you don’t end up hiring a given candidate, if they have a good experience, they may introduce other developers to the position, or may even end up being a good hire later down the road. On the other hand, if they have a bad experience, they’re likely to tell other developers about it, which may dissuade people from applying.
Quick and keep the candidate informed
Throughout the whole process, you want to minimize both the time you’re asking of candidates, and the calendar time itself from initial application to offer. If you drag your feet on things, a candidate can end up accepting another offer before your process even ends, making it a wasted investment on both your and the candidate’s part.
Along with this, you want to keep your candidate informed throughout the whole process. When a candidate completes one stage of the process, and doesn’t hear anything back, they start to get anxious, and may assume they didn’t get the position.
Seek to minimize bias
It’s unavoidable that bias will creep in throughout the screening process. Pattern recognition can help you identify good candidates quickly, but it can also end up prejudicing yourself against others.
Having a well defined hiring process can in and of itself help fight against bias. Be explicit about what the qualities you’re looking for in candidates are, and look for how candidates demonstrate those throughout the process.
The contents of this article are based in part on the discussion from the Screening Developer Candidates event of CTO Talk Tokyo. Thanks to all the participants of that event for sharing their knowledge. You can also see this writeup of the event.