Recruitment
I am very proud of our recruitment process. By the end, it was a 100% accurate predictor of success, and the process only took a few hours of work from each potential colleague. We actively removed as many sources of bias as we could, enabling us to recruit from a very wide pool of talent. And we had an 100% acceptance rate when we made a job offer.
Our process was designed to determine whether a potential colleague could do the job within our team. Sadly, this appears to be unusual criteria in the tech industry.
For us, we wanted to know whether the potential colleague could write code in a workplace environment, would thrive in a diverse team who valued learning together, and had a right to work in the UK. Nothing else is relevant.
We also designed the process to give us a big competitive advantage by doing easy things. We were very fast, we respected them and their time, and we let them see exactly what Haplo was like.
Finding people
We preferred early career developers. We found potential colleagues through Cord (a job search marketplace), adverts at universities, placement programmes, and occasionally recruiters.
We focused on places which offered diverse pools of developers, as we were such an attractive proposition for people who didn’t meet the tech company stereotype.
I’m not convinced CVs are terribly useful, and can be actively harmful by reinforcing biases. I mainly used them to make sure I’m not wasting the time of any potential colleague by looking for evidence they’d done some coding before.
Outreach
First impressions count, so we were very thoughtful in our first contact with a potential colleague. Especially at Cord, where you browsed a list of people and made contact with them, we wrote a personalised email which mentioned something about Haplo which was relevant to their interests and experience.
In that email, we included links to pages on our web site which would answer pretty much any question they might have about the company. These included
- a page which went into great detail about Haplo and how we worked
- the team listing, showing every single member of the team with a brief bio
- the technology stack
- a product overview
The first two were the most important. People join a team, and stay for their team.
Phone screener
We received responses to our initial messages about 60% of the time, and would quickly set up a phone screener. Even after the pandemic made video calls the norm, we still used the phone. It’s less pressured than a video call, and removed a potential source of bias.
The phone call was designed to do two things. Firstly, filter out anyone who wasn’t interested in us. And secondly, sell the role, so they would prioritise doing the next steps in our process. We specifically didn’t want to know anything about them at this stage, as any information would be irrelevant and a source of bias.
The call was structured as:
- a few minutes of general conversation to put them at ease and get used to each other’s voices. I found asking about where they were living or their university were good topics.
- a quick check on their right to work in the UK, which we asked even if was obvious.
- “What are you looking for in your first/next role?”, and then drawing to their attention how Haplo met their requirements.
- “Do you have any questions for me?”
- an outline of the rest of the process, asking if they’d like to proceed, and gaining a commitment for a date to return the coding challenge.
We made a point of being totally open about things which weren’t what they were looking for, to avoid wasting anyone’s time. It was rare for someone to filter themselves out, but when they did, it always felt they’d made the right decision.
Coding challenge
After the phone screener, we asked them to complete a code challenge to write a very small web application. This was designed to:
- take no more than 4 hours for a new graduate to complete,
- be solvable in less than 20 lines of readable code and an HTML template,
- have easy to understand requirements, with a video showing a working solution,
- have many different ways of completing it,
- and be interesting and fun.
There were no requirements on the language or frameworks to use, with guidance on appropriate choices to steer them in the direction of rapid success. We asked that appropriate shortcuts were taken, and for a short report “suitable for providing to our clients” to judge their written communication.
To proceed to the next stage, their code needed to be clear enough that we could convince ourselves it worked correctly without running it. This tested legibility as well as correctness.
If the code wasn’t good enough, we’d give them detailed feedback on why we weren’t proceeding, and hints and tips for their next coding challenge. We were careful to be kind, non-judgemental, and provide actionable feedback.
Interview
Before the pandemic, we preferred face to face interviews and only used video calls when they were in a different country. After the pandemic, it was all video calls, for obvious reasons.
Our interview was primarily an extended code review. All we wanted to know was whether they could think about code and learn new things quickly at Haplo.
Preamble
Like the phone screener, we started off by irrelevant chat to put them at ease. How was your journey? How’s the job hunt going? That sort of thing.
When everyone was ready, we’d ask what they thought of the coding challenge. I was pleased that the majority of people said it was fun and different to other company’s tests.
Code review
The code review is the actual test, not writing the code for the coding challenge. We were interested in whether a potential colleague showed behaviours and patterns of thought that predicted success, especially an ability to take on new information and apply it quickly.
Sometimes interviewees are nervous. Possibly more for us than other companies, as it was often their first interview for their first job. Nerves are unhelpful in an assessment, as it prevents the test from being realistic, as people are not nervous in a functioning workplace.
When it appeared that nerves were causing problems, I did as much as I could to dispel them. I found the best way was to explain exactly what I was looking for and what they needed to do to get a job offer, along with some encouragement by pointing out specific things they’d done so far which contributed towards achieving this.
I’d start the review by pointing to a minor opportunity for improving their code, usually around legibility or maintainability. I’d ask what they thought about it, giving any hints needed as to what I was looking for. After discussing why it was important in real code, I’d reassure them it was absolutely fine in a coding test — in a real workplace we have a code review process.
Then, I’d ask them to sketch out the data structures they used, explain how their code works, and how the URLs relate to the data structures.
The coding challenge deliberately had many ways to implement it. We discussed some of the other possibilities, and the trade-offs between each choice. To test the ability to learn, hints were given by providing new information to see how it was used.
We found that if a potential colleague could see two or three different ways of doing things, made good judgements about the merits of each, and used the new information they were given, they would succeed in the job.
Because a conversational approach could very easily lack the structure needed to make it a fair and unbiased test, the conversation was mapped out in a written document. The exact order would be determined by the interviewee’s responses, but overall, everyone would have the same conversation.
Reverse interview
We believed it is important for potential colleagues to interview a company as much as the company interviews them. After all, it’s a bigger decision for them than it is for us, and not all workplaces suit everyone.
We matched interviewees to current colleagues, and invited them to ask them anything. After explaining this was not part of the assessment, anyone involved in the decision would leave the room. It genuinely was not part of the assessment. Of course, any colleague could veto any interviewee for any reason, and when this happened it was about specific behavioural red flags rather than ability.
As well as ensuring we had a good match, this was incredibly effective at selling the job. I am convinced this step is one of the main reasons we had a 100% acceptance rate.
Final Q & A
By this time, we’d all have a pretty good idea of whether things would work out if they joined our team. The final part of the interview was primarily to introduce them to a few more people, and check a few practical issues.
We would, of course, invite questions from the interviewee, but generally we’d find that most had been answered during the process.
While this part usually took just 15 minutes, it was useful for checking there were no negative behaviours which would impact a diverse team.
We would also do a gentle sales pitch for joining us. For early career developers, we’d say the job would be hard work, but it would be the best possible start to their career.
Job offer
We aimed to give everyone a decision by the time they got home. There is no reason to delay, and the speed shows the potential colleague we’re an efficient and decisive place to work.
Our offers never had any hard deadline, and came with an offer to talk about any aspect of the job. “Exploding” job offers which expire quickly are unethical, but we would ask when they might be in a position to make a decision. We were very happy to wait until other offers came in, as we were confident we’d be better.
If we declined to make a job offer, we gave detailed feedback, up to and including a phone call to talk it through. A lot of time had been spent to get to this point, and you can’t just say “no”! To be as non-judgemental as possible, any feedback would be actionable and tied to job requirements.