Hiring at SPOC has been — is still — a pain. However, over time we have been able to create a process that works for us.
There are about four stages that a candidate passes before they can get hired.
- Contact the candidate
- Technical test
- Onsite interview — remote if it can’t be helped
- Final chat
Contact the Candidate
A lot of the people working with us today were hired through referrals and Twitter. The thing is people will refer people they trust to get the job done; not just anyone, so chances are that the person being referred is a quality hire. Though some have come in through other means, which was a blessing, — in terms the quality of work they put out — we do not use it as our goto when hiring. In the past we ran a recruitment drive where over 5000 people applied for about 10 different roles. That was a really bad idea; things didn’t really go as planned and sadly a lot of the non-technical roles are still not filled till date.
We’re a relatively small team, so when a candidate’s resume — for a technical role — is dropped in my DMs or mail, I do a short background check on them and send them an email or slide into their DMs (to be fair, other times I enter people’s DMs and shoot my shot 😅). If the person is chatty, we’d engage in a short conversation where I try to find out as much as I can about them without being invasive. They are told what the job is about and what will be required of them, then an email is sent to them containing a technical test and instructions.
Technical Test
We send them a technical test which should take at most seven days to complete. Our test is designed to test the candidate’s use of our tools. We know not all the candidates would be comfortable using the tools in our stack, well, we expect them to try at least. After the test is done, it’s reviewed by two or three of our engineers and we grade them on a pre-defined criteria.
What we look out for:
- Quality of code — DRY stuff, code readability (if I was going to modify that piece of code I should understand what the person did).
- Project architecture/design — how are the project folders organised, what design patterns are being used.
- Test coverage — some people don’t even attempt writing tests 😭
- Use of suggested tools —we have set of tools we use and we state them explicitly in the instructions.
We send candidates a technical test mainly to gauge their level of expertise and see if they can be a fit to our current style of work. We’re always looking out for people that are hardworking, and are ready to learn. We’ve had people come in for the interview and tell us that our test made them learn how to use Docker or Redis (win-win right?).
You can view the tests here:
As you can see the tests are very direct and practical, I personally don’t like algorithm tests or HackerRank type tests because they don’t help give us insight into how well the person can actually do the job we want them to do on a daily basis. The tests have evolved over the months and probably still will because it seems like they’re now too easy —haha, actually our stack is evolving, so it’s only fair the tests also evolve.
Interview time
If the candidate is successful we invite them for a chat which doubles as a technical interview. Asides the technical questions which are based on the test itself and on their programming background, we ask a lot of open-ended questions to gauge their personality, thought process.
This part is usually done by myself and two or three other engineers. We take turns asking questions and encourage the candidate to ask as much questions. On a good day depending on the candidate the interview becomes a chat and we get a very good idea of how the person thinks, the problems they have solved and their motivations to work. On a not so great day we have to literally pry the answers we want to hear from the candidate, at least we try, then we give them the answer if they don’t know it.
Ideally, we should have a script ready so we have a large database of questions we can ask depending on the candidate, well, we have a makeshift list, it’s not complete… yet. So we let the candidate’s experience drive the interview and ask questions relating to what they have done, where they have worked, etc, then lead with the questions from our short list.
Final Chat
We invite the candidate to a culture-fit interview after about a week or two, if they pass the technical interview. This chat is for the mostly the candidate to ask us more questions to see if we’re a fit for them, what the day-to-day is like, how we work; what to expect generally. I mean, we ask a lot of questions too, to get to know how they work and if they permit some personal questions to gauge what kind of person they are. We’re going to be working together so you have to be able to make a judgment call there in that meeting room.
After all this the candidate is given an offer. The whole process usually takes about a month.
Hiring has been pain and has been fruitful, we had to be creative with the process, the team has really put a lot of effort into making sure it works from first contact to onboarding completion.
Reviewing CVs, giving up my remote days to come in for interviews, grading the test submissions, rolling my eyes and being impressed at the interviews, having a blast at the final chats; I’ve felt almost every kind of emotion —even jealousy guy, when Andela or Paystack hires all the great devs, what can you do? 😭— as a result of hiring.
For those of you who asked, hope it helped.
PS: Check out our other open-source stuff, hope it’ll be useful to you. 😬
