There’s no way around it: live coding is stressful. If you just ask your coding problem like a robot and sit down in silence, you will fail to create an environment in which you can evaluate candidates fairly. In this guide, we’ll go over the steps you can take to make an interview less stressful, conversational, and ripe with opportunities for a candidate to shine.

Before the Interview

I’ll leave the subject of choosing the right problem for another day, but before you continue I’ll assume you have a question (somewhat) ready and that you’ve made sure it is adjusted to the experience level expected for the role.

Here’s what you should do next:

  • Code out multiple solutions to the question yourself. Don’t just think through the problem, do the work and have your own verifiable solution.
  • Solve the problem in at least one more programming language. (Unless your company is explicitly hiring for a single language.)
  • Keep a note ready with all the solutions you’ve figured out, as well as their time and space complexities. (As a cheatsheet you can reference if needed.)
  • What were the tricky bits of each solution? Write down those notes as well!
  • Calibrate the question with another colleague or a friend outside your company. Grab them for 20-30 minutes and do a mock interview with your problem. Gather their feedback and adjust as needed.

Of course, the general best practices for conducting an interview still apply.

Next, plan out a timeline of how the live coding should (ideally) go. For example, this is how I plan a 30-minute loop:

  • 4 minutes to disambiguate the problem
  • 6 minutes for problem-solving and choosing an approach
  • 12 minutes of coding and discussing
  • 8 minutes for follow-up problem coding or discussion

Let’s break down each of these sections and what typically happens in each.

Part 1: Framing the Question

As you go into the interview, you need to already know how you will deliver the problem to the candidate. You will need to include some level of ambiguity so that you can measure their problem-solving skills and give you a deeper insight into their professional experience.

Is it a junior role? Then give them most of the details, maybe even some sample input/output data. Is it a senior role that requires software design skills? Then frame an ambiguous problem and let them dig a bit.

Measuring how the candidate deals with ambiguity is a very important part of the coding interview. This part can quickly help you figure out if this is a mid-level or senior candidate! It’s a very important component for running a good phone screen and figuring out if the candidate has a chance.

Here’s how this part could go:

  • Scenario 1: The candidate disambiguates the problem quickly, yet thoroughly.
    • Next step: Guide them to move on to thinking about the solution.
  • Scenario 2: The candidate is doing ok, but struggling to understand completely. They understand that they are missing something.
    • Next step: Give a few hints, if they are really stuck after 4 minutes, reveal what is remaining and guide them to start solutioning.
  • Scenario 3: The candidate thinks they have it figured out, but they don’t. Instead of continuing to think through the problem, they want to rush to the coding.
    • Next step: Interrupt them and point out what they missed as a hint. Consider it as scenario 2.

Part 2: Solutioning

Some candidates will try to jump into coding too early and some will spend too much time thinking through the problem without getting to a possible solution. You need to keep both of these types of interviewees on track.

If they’re rushing too much, tell them you would like them to first explain the solution to you. Ask them if they’re considered anything else and if so, why did they choose their current solution? If they are stuck on just one approach, give them some hints for other possible solutions, even the less optimal ones.

Why you might ask? Because your goal here is to understand their ability to problem solve, compare solutions, and make trade-offs. This is another skill that is a must at senior levels.

For the other type of candidate, who is stuck, you need to start giving hints early. Do it through conversation and ask leading questions. Don’t let them shut off and sit in silence and don’t reveal the answer either. If they can’t come up with a solution on their own, it’s your job as an interviewer to guide them there. But how?

There’s two things that you know:

  • All the different solutions to your problem, and
  • What the candidates seems to be good at and what they lack.

If the optimal solution involves creating a tree data structure and they clearly don’t have the knowledge needed, you need to nudge them towards a different approach that is a better fit for their skillset.

Two examples:

  • During a phone screen I interviewed a candidate who came up with an initial solution of O(n^2) time complexity and constant space. The optimal solution would have involved an O(n log n) algorithm, but they didn’t have the skills needed. However, I could see they have knowledge of other data structures and I softly nudged them to think if they can trade space complexity for time complexity to optimize the runtime.
  • In another interview, a candidate could not come up with any solution on their own after a lot of subtler hints. I then chose to guide them towards the easiest solution I know. I would write up some test cases and lead them to think through the steps. They still had to lead through and complete my thought – this makes the experience much better and less patronizing.

Part 3: Kick off the Coding

Like I stressed in the previous sections, you have to keep time and you have to push them towards the coding part. Without seeing them code, you won’t have the right data points to make a good judgment call. Any assumptions you may have made during the first 2 sections will now be put to the test.

Before you begin, encourage them to talk through the problem as they are solving it. They can either write a section and then talk about it or talk as they write – whichever is easiest. If they start to over-explain, you should cut them off and tell them to focus only on the most important bits. Tell them that over-explaining is not bad, it just takes away a lot of time!

During coding, you need to pay attention and try not to interrupt unless it is important. If they made a typo or got the syntax wrong, don’t stop their flow.

As they’re typing, keep notes on:

  • How familiar do they seem with the language and the standard library?
  • Is their code well-structured? Do they go back and tidy things up?
  • Are they clearly following some sort of convention or coding style, or is it all looking chaotic and unorganized?
  • Are they thinking about extensibility at all?
  • Are they doing any form of debugging/checking that the code will do what they expect?
  • Are their explanations of what the code does clear and well articulated?

Part 4: The Follow-up Problem

Not every interviewee will reach this section and instead you’ll just do the coding part until time runs out. Generally speaking, this should be a clear sign that their performance in the coding interview did not raise the company’s bar. This can still mean that the performance could have been sufficient and enough to get them hired if the behavioral interview went well. But, you will have to think really hard on whether you’re really hiring the best or not.

However, just because you’ve reached this point doesn’t mean the candidate is exceptional either. A good follow-up will help you get the data that supports that.

If the candidate did not solve the problem via an optimal route, the follow-up can be used to prompt them to look for that solution. In this case, we’re not really going to prove the candidate is exceptional, but you will be able to collect the data they are still pretty good.

If they already solved the problem via an optimal or close-to-optimal route, then your follow-up problem should expand the scope further and in a new way.

For, example if the problem was previously limited by an input that fits into the machine’s runtime memory, you can now push the candidate to think beyond the limit. They might have to figure out a streaming solution or come up with a distributed processing idea. Engage them in whatever path they choose and continue to challenge them to think big. It would also be great if you can get some pseudo code or diagram out of them.

Just like with the initial problem, you should be a master of the follow-up as well. You must know the most common approaches and solutions so that you can both guide the candidate and fairly evaluate them.

Summary and Goals

To summarize, let’s look at the sections again and their goals:

  1. Problem analysis: You are looking at how the candidate handles ambiguity and how they communicate through it.
  2. Problem-solving: You are looking at the candidate’s problem-solving process and their ability to compare solutions. You’ll also get a good idea of their computer science fundamentals based on all the approaches they identify and which they are not familiar with even with hints.
  3. Implementation: You are looking at whether the candidate can actually write code and bring their ideas into reality. You’ll also look at how they write, test, and reason about their code.
  4. Follow-up problem: You will challenge the candidate further to see how they deal with a problem of higher scope and complexity.

What if the Candidate is Clearly Not a Good Fit?

All of this advice becomes completely irrelevant if the candidate is clearly not a good fit. This can happen a lot during a phone screen or if you have a bad system to filter candidates.

What I am referring to are candidates that obviously lack fundamentals and quite possibly cannot even code independently. This isn’t just a matter of stress; you will know it when you see it.

In these cases, your goal is no longer to conduct an interview and collect data on why this candidate could be a great fit. Instead, your job is to make the rest of the interview relatively enjoyable and non-awkward. You don’t want to do or say something that can negatively impact the candidate’s perception of the company.

Focus on working with them, as you would with a mentee, and getting some solution out the door. Give positive reinforcement when things go well, but keep presenting challenges. Never act or talk in a patronizing way.