This year my work has increasingly involved recruiting developers for EmCasa. As I envision the need to involve our team in this crucial part of my job, and to hand over hiring responsibilities in the future, I thought I’d like to put my current process into words to share it and hopefully receive constructive criticism.
The complete hiring process involves more steps than the initial screening itself. Here I will focus on the step going from receiving applications to deciding who are the ones to set up interviews with.
The setting in which the selection process takes place has always been, for me, one in which this is one of many tasks running in parallel: currently I’m also continually reviewing (code and QA) our web frontend client, our mobile clients, our backend, the visual design of the applications, hiring designers, developing macro strategies with my co-founders, building a culture from scratch and the occasional meeting with people from other companies and investors.
Another factor to take into consideration this time around is the relative abundance of candidates, with perhaps 120-150 total this year.
Right now we are 4 developers at EmCasa, working remotely, using Elixir on the backend and React / React Native. We have been emphasizing Brazilian developers since we’re in Brazil.
Oh, and do I need to tell you we are hiring?
Given this scenario, I’ve been using a few heuristics and biases.
1. Good Github page
If the candidate has very few commits over the last 365 days, I move on to the next candidate. A couple of commits a week on average is a bare minimum. It’s ok if it’s clustered recently, it may mean that the person is looking for work.
If no pinned repository uses the technology we’re hiring for, I move on.
If the candidate’s repositories don’t have READMEs, I generally move on.
2. At least one strong public repository
Having found repos using the technologies we’re hiring for, I try to find one that is particularly strong: one where I can understand what it does, how to install and run, is at least a degree above trivial and a glance at the file structure and a few files show care on their part.
I should say that 80-90% of the candidates I review don’t get past this point.
Having installed and run the application, if it does what it needs to do, I take a more detailed look at the code. Perhaps 10 minutes typically.
3. Ability to communicate and think outside code
Having reached this step, and this means only 5-10% of the candidates, I look for evidence of good ability to communicate and think in the broadest terms possible.
This is the moment where I’ll look for the link to their website, blog, Linkedin, and other social media, in decreasing degrees of importance. If I see signs of sloppy writing or thinking, I move on to another candidate.
As you may have noticed, this process is heuristic-heavy and geared toward my specific situation at this moment. Some blind-spots are inevitable, such as the percentage of great developers that don’t use Github all that much. I try to avoid that by taking a quick glance at other possible indications that this is the case. If I can’t see any code, I will move on eventually. If I notice some outlier information, I will bypass my own criteria to some extent, which happens in less than 5% of the cases.
On average the screening of one candidate takes 5 to 10 minutes, but seems to require about as much to clear the mind. For the ones that do well, I will spend between 1 and 4 hours reviewing.
After these screening steps, I send the candidates an email for a quick hangout, which is the beginning of the next step in the hiring process.