Tech hiring is a hot topic nowadays as companies scramble to attract and hire the best devs. And while there are a lot of tactics different hiring teams use to try and get the leg up on each other, I’ve found that the most important factor is to get the basic skeleton of your process down pat.
In the first post of my mini series with Codility, I’ll discuss the four main elements of an effective interview process.
So, let’s walk through this process each stage at a time.
The phone conversation is a high touch but low investment session. It doesn't take long to organize and is typically a 30-minute call. It's a brilliant way for both the candidate and hiring manager to find out more about each other.
I always suggest starting the call with a brief introduction to the role and company. This sets the scene and provides the context for further discussions. The candidate is then given time to ask any questions before moving on to interview questions.
The phone interview works best with a hiring manager and a developer conducting it. This tends to make the interview less daunting for the candidate and they can ask a wider range of questions.
Try using video conferencing instead of a phone call. Being able to see each other can make the call more personal. Be sure to communicate call details to the candidate ahead of time and allow time at the start for getting the conference call connected.
The next stage is a technical challenge for the candidate if everyone is happy to continue.
Technical challenges are a great way for the candidate to show off their technical skills. They are also a way for the hiring team to assess a candidate’s skills and experience.
The technical challenge should be time bound and completed on the candidate’s own time. By setting a deadline, it gives the candidate a clear delivery expectation. It also helps to keep the interview process moving at a fair momentum.
The technical challenge should be relevant to the role and the skill of the candidate. There is little point in setting an advanced challenge for a junior candidate. The challenge should be fun yet challenging. If it’s not fun, there will be less enthusiasm and engagement from the candidate. If it’s not challenging enough, you are unlikely to discover the candidate’s real potential.
Candidates can also choose their own coding language for completing the challenge. However, I do recommend suggesting they complete it in the same core language that your team uses.
Once the coding solution is complete and meets expectations, it is time to move to a face-to-face interview.
If the code does not meet expectations, the candidate will receive feedback. Someone from the hiring team will explain what the hiring team was looking for. It’s important to be transparent in the criteria around technical assessments.
Good candidates expect feedback about where they may not have met expectations.
The face-to-face interview is an opportunity for the hiring team to discover more about the candidate and whether they can fulfil the needs of the role.
It’s also an opportunity for the candidate to meet people from the team and understand more about the role.
There is very little reason not to complete the face-to-face interview in a single interview. Good candidates won't like to take multiple days away from work for interviews. The norm now is for single interview sessions, it makes sense to offer the same option.
A good face-to-face interview lasts anywhere between three to four hours. This is an intense interview, but it is over in a single session. With proper care and attention there is no reason why it can’t be an engaging process for all involved.
I recommend splitting the interview into three distinct sections:
During this challenge, the candidate must extend their initial solution to the first technical challenge. This simulates a change of requirements and how the candidate copes with extending their own code.
There are many reasons for asking candidates to extend their original coding solution. One reason is to understand how they cope with having to change and extend their own code. Another reason is an opportunity for the candidate to ask questions of the technical people in the team.
A final reason to extend the code is to ensure the candidate wrote the original solution. A very small number of people have submitted code that someone else has written. This was either copied from the internet, or they submitted code a friend had created for them. It doesn’t happen very often and as such is not a primary reason for extending their original code, but it can happen.
During this technical challenge, the hiring team must discover as much about the candidate’s approach to writing code as they can. It’s important that the candidate writes new code during this section and discusses their implementation with the technical hiring team. After all, this is what they will be doing as part of their role.
The third and final section of the interview is a chance for someone from HR to ask questions. This section focuses on career ambitions, candidate strengths and company fit. This section should be around 20 minutes in length and conducted by at least two people.
I recommend a short break between each section as it can be a long and demanding interview. After the interview the candidate has a tour of the office. This is so they can see others at work and get a feel for the environment they may be working in.
The last stage of the interview process is the decision-making meeting. This is where the interview team comes together to make a decision about hiring the candidate.
Everyone involved in the interview should share their observations and evidence. The evidence from the technical challenge should form part of the discussion, alongside the candidate's answers to behavioral questions. The discussion should center around evidence and observations to root out biases and opinions. This is also why each interview section should have at least two people present, to ensure a fair and unbiased assessment.
After everyone has aired their evidence and observations, there should be time to discuss anything further. A decision-making process follows this. The goal is to decide whether to hire the candidate based on the presented evidence.
If there is no consensus, then a discussion should be had based around the evidence. People may then change their minds based on the discussions. To avoid influencing based on hierarchy or bias always return to the evidence.
If somebody still does not want to hire the candidate, then my suggestion is not to hire that person. Hiring candidates should be a democratic consensus based on available evidence. No consensus to hire, no hire.
Communicate the decision to the candidate as soon as possible. Do not leave it too long though as good candidates don’t stay on the open market very long.
The interview is a two-way process designed to give both the candidate and hiring teams information to make a decision. As such, it’s important to create space for the candidate to ask questions, show off their skills and discuss technical aspects of the role with the hiring team. Equally, the interview is the best opportunity hiring managers have to see code being written and to ask relevant behavioral-based interview questions.
An effective interview process can help you to keep the bar high whilst also ensure you hire the best technical talent.
If you're looking to revamp your tech hiring, I suggest reaching out to the Codility team!
© 2009–2016 Codility Ltd., registered in England and Wales (No. 7048726). VAT ID GB981191408. Registered office: 107 Cheapside, London EC2V 6DN