“The candidate didn’t manage to come up with the most performant algorithm. Thumbs down 👎.”
“They were very slow and didn’t get to a working solution on time. Hard no ❌.”
How often have you seen scorecards like that following a coding interview? Interviewers are often quick to make snap judgements about candidates’ performance without asking themselves questions that really matter such as: Does the interview performance reflect the candidate’s ability to perform real-world tasks? Is the person actually unable to work through a problem or were they just very nervous? Did the candidate have a positive interview experience that will encourage them to recommend us to their friends?
Here we’ll share a few tips and suggestions on how to create the best candidate experience and gather the most signal in a coding interview.
Define the signals you’re looking for
The most important thing to figure out before going into a coding interview is knowing what questions you want to have answered by the end. It’s rarely only whether the candidate can think of a great algorithm. Your scorecard should be structured to reflect all of the signals you’re looking to gather.
For example, the ones we look for in one of our interviews at Metaview are:
- Problem understanding: How good is the candidate at grasping the problem at hand?
- Communication: Do they communicate well how they plan on approaching the problem?
- Clean coding: Are they able to turn their thoughts into clean code? Are they someone who codes on a daily basis?
- Going into detail: Do they think about edge-cases? Is the solution always accurate or only most of the time?
- Debugging: How good are they at debugging? This includes typos and logical errors.
- Collaboration: How easy is it to follow along as they are working through a solution?
Set expectations upfront
Once you're in, make sure that the candidate has the correct expectations before they start coding. Are you looking for maximum performance or code quality? Do you want the solution to run, or are you just interested in seeing whether they can write readable code?
For instance, we start by saying:
- Our number one priority is to have something working
- Code quality is second on the list
- We are not concerned with performance at all
Make sure to reiterate these expectations throughout the interview if you notice misalignment.
Present a multi-stage problem
Understandably, candidates can be very nervous in a coding interview. They need to solve a complex task as someone looks at every character they type and the clock ticks. Something that helps put candidates at ease is having a multi-stage problem. Start with a very achievable goal and make sure to celebrate every milestone as the candidate progresses. Present the next stage of the problem only after completing the last one. The candidate needs to know they are making progress and that they can forget about the clock. After all, it’s the interviewer’s responsibility to time-keep.
Start helping only after you’ve gathered the signal you need
Interviewers often either aim to be friendly and help the candidate with every hurdle or do the opposite and sit silently for minutes while the candidate is looking for a typo. You have to remember that you want to extract as much signal as possible and neither approach helps with that goal.
Remember to keep the questions you want answered about the candidate top of mind. Start by not offering help and once you’re confident you have a good signal on the question you’re looking to answer, just move on. For instance, you shouldn’t start by telling the candidate about every typo or off-by-one error they make as they are coding. Let them find a couple by themselves and then start helping. If they can’t debug issues on their own, that’s fine—you can then focus on their clean coding skills.
Communicate with intent
It’s the interviewer’s job to help the candidate focus and do their best. This doesn’t mean you should always sit quietly as they’re coding, nor should you aim to keep them talking for communication’s sake. People have different settings that let them operate well and you should gauge what the candidate needs.
If they are crushing it in silence, a simple “mhm” and “ok” from time to time is enough to let them know you’re present and paying attention. If they are just staring at the screen and not doing anything, make sure to direct their thoughts away from any worries by asking: “What’s on your mind?” or “What are your thoughts?”.
Have an ease-off prepared
You should have a way to end the coding section of the interview with enough time for you to take some questions. You should make this transition in a way that takes the candidate’s mind off the task and stops them from thinking about how they did.
If they are on time and just finished a stage of the problem, it’s simple— just say: “Nice! This is what we wanted to achieve. You can relax and stop sharing your screen.” Or, you can ask them what they thought of the problem. If they are in the middle of something and it doesn’t look like they’ll finish it, stop them and ask them to explain what else needs to be done.
After the interview
Coding interviews can be a challenge for all parties involved. But interviewers who are prepared will come out of the interview confident with their assessment and leave the candidate with a feeling of achievement.
