How we updated our interview process to provide a better experience for candidates.
Since September 2018 we’ve used a straightforward process for interviewing candidates for our software development positions.
This consists of:
- An initial screening call with one of our engineering managers.
- A call with one of our developers where we go more in-depth with knowledge of technical concepts.
- An on-site interview with more technical discussions and a pair programming component.
What we’re trying to ascertain during this process, is whether a candidate will be a good fit for us, and whether we’ll be a good fit for them.
At Limejump we want to build an environment where developers are given the freedom to solve the complex challenges of the energy industry. We look for developers with strong problem solving skills, who are good communicators, technically proficient, and all-round nice people. The interview process is our opportunity to learn as much about a candidate as we can in these areas.
We don’t have much time to figure this out (approximately three hours of contact during the process), so it’s important to maximise what meaningful information we can obtain to help us come to a hiring decision.
For candidates, we understand how stressful and tedious interviewing can be. Therefore we want to make the process as enjoyable as we can so that even if the result is not a hire, candidates won’t feel as if they’ve wasted their time (at least not too much).
This has led us to reconsider our current interview process to identify what we can improve to help us make more informed decisions.
Reflecting Upon The Current Process
After retrospection on our current process, we identified a number of things that could be improved. We have a bank of technical questions to ask candidates, but some of these are trivia-based questions. Issues with these types of questions are well-known in the tech industry. We want to ask more open-ended questions so that interviews are more of a discussion, and less a Q&A session between interviewer and interviewee.
We also didn’t communicate which interviewer would ask what questions. This resulted in us frequently asking candidates the same questions multiple times throughout the process. This is not inherently a bad thing, but during the limited time we have with candidates we want to cover as many different topics as possible. Candidates should not have to repeat themselves over and over, and this limits opportunities to show us their breadth of knowledge.
For the pair programming component of our interview process, we want to see how candidates approach problems and apply their technical expertise. Our exercise bank contained a lot of algorithm-based questions, which has similar problems to the aforementioned trivia questions. These exercises were also detached from the actual work we do at Limejump.
Outside of how the actual interview process is organised, we had no tangible evaluation model that was more than general intuitions about a candidate. Hiring will inherently rely on “gut feeling” at times, but we realised that having an evaluation rubric would assist in comparing candidates against our expectations for what comprises a good skill-set for a software developer at Limejump.
Refactoring the Process
In September 2019, we updated our interview process. We believe these changes will create a better experience for candidates, and allow us to get a better understanding of a candidate’s abilities.
Not much has changed for the initial screening call as this only briefly touches on technical concepts. During the call with a developer we have updated our bank of questions, removing the trivia ones and creating a focus on providing candidates the opportunity to show-off the depth and breadth of their knowledge.
The biggest changes come during the final stage of the process. When a candidate comes on-site, a typical interview will be:
- A 30-minute session with a developer and an engineering manager discussing technical concepts and other soft skills.
- Another 30-minute session with two developers focusing on system design.
- A 1-hour pair programming session with a developer, solving problems similar to those we tackle at Limejump everyday.
Adopting this structure allows us to address some of the issues we had identified. Creating distinct stages of the on-site interview reduces the chance a candidate will be asked the same question multiple times, and providing a system design session is a good way of allowing candidates to really show what they know.
The pair programming exercises are now a better reflection of some of the big challenges we face, and give candidates a better insight into what we work on at Limejump.
Finally, behind the scenes we have started to create model answers for technical call and system design questions for junior, mid-level, and senior candidates. This has been helpful for various interviewers coming together to agree upon a consensus for hiring decisions.