I can safely say that recruitment is the most difficult part of this job. You desperately need to expand the team, you know the right person will add tremendous value - but you only get a few short sessions to determine who fits into that category. It’s difficult to get it right every time and I'm still searching for the best process that will always leads to the right decision.
When we designed our current software engineer recruitment process, we first had to identify what we wanted from the process. We want to hire good engineers but what does that mean? A good engineer for Goodlord might not be the rightÊ engineer for Goldman Sachs or for Google - there are other factors that are important to us as a company. In particular, we want to make sure that everyone gets an equal opportunity and that, regardless of the outcome, the experience is enjoyable. With all these thoughts in mind we settled on four key objectives for our recruitment process. It should:
With these clear objectives, we would be able to tell if the process we defined was a success.
The first stage of the process is the phone screen, to know the candidate and answer any questions they may have about the role. The goal is for both parties to gather enough relevant information to determine if they want to move forward in the process.
The phone screen is the stage where bias is most likely to creep in because it risks being an assessment of conversational skills. To combat this, we’ve adopted an evidence-based format where we focus on what the candidate has done using a combination of closed and open questions. We focus on six key skill areas and score each using the following system:
Passing the phone screen is then a matter of getting to a certain overall score which increases with level of seniority.
On a side note, I’ve noticed a peculiar phenomenon recently. Candidates have been showing up for a phone screen without taking the time to explore what we do as a company. We usually take this as a signal of a disengaged candidate and end the interview early.
Next comes the technical assessment. This is where things start to get tricky. Are whiteboard exercises the most effective way to test a candidate’s technical ability? Are take-home exercises a way to get candidates to work in the comfort of their own environment or just another way of discriminating against those that have a family? Perhaps we should look at their open-source work but then we penalise those that cannot or don’t want to contribute to public repositories.
There really is no consensus out there and each approach has fierce critics or die hard supporters. At Goodlord, we’ve tried all the different approaches and, at one point, even gave candidates the choice of which approach to take. We’ve now settled on a face-to-face pairing by default - where the candidate works alongside a Goodlord engineer on resolving a task - as we found that it gave us the best balance of skills assessment, time management and building rapport.
Before the interview we send the candidate the problem we’ll be working on, which is typically a stripped-down version of a challenge we’ve faced internally. We spend the first 15-20 minutes of the interview answering any questions they have and discussing their approach to solving it.
After that, we pair to implement a solution. What we’re really looking for is a candidate's ability to:
We’re not interested in their ability to recall esoteric API definitions and method signatures so we encourage them to use the internet, look up previous similar implementations, ask questions, etc. Depending on the seniority of the candidate, we also do an architecture review, where we ask them to walk us through a problem they’ve solved recently and the architectural patterns they adopted.
At Goodlord, we have five values that are really important to us. They influence the way we work and our decision making on a daily basis. They are:
I like to tell candidates that this stage of the interview is about values compatibility - we’re not necessarily looking for them to share our values exactly but Goodlord’s values and their personal values should not be in conflict. We also try to use this opportunity to bring in other members of the organisation into the interview process. That way the candidate gets to meet people from the wider business and not just the tech team.
We’ve been running this version of the process for about a year now and have generally met our objectives. The evidence-based questions work well with the more senior candidates but, unsurprisingly, aren’t as effective for junior positions. We also had one person pull out of a face-to-face interview as they found doing a pairing exercise too stressful.
That said, the overwhelming majority of candidates have given us positive feedback on their experience regardless of the outcome. We find that the candidates that we bring on board closely match our expectations from the recruitment process and they also feed back that the job matches their expectations as well.
We now have a very diverse range of individuals with over 12 different first languages in the team and multiple ethnic and racial backgrounds. Our process is not perfect yet - but we're getting there.
Want to advance in your tech career? Check out the jobs we have available.