Lesson Sunday

Many jobs have a multi-step interview process that includes a technical interview where you'll whiteboard a solution to a coding problem. Whiteboarding is the process of solving a coding problem on a dry erase whiteboard. It can be a very stressful process, even for experienced developers, and the practice has fallen out of favor in some tech companies. Proponents of whiteboarding argue that it's a quick way to get a sense of someone's actual coding ability. However, there are a number of issues with whiteboarding as well:

  • Whiteboarding doesn't accurately simulate a real-world environment where we have documentation, a code editor, and other resources at our disposal.
  • Whiteboarding can disadvantage people from underrepresented groups that might already have to contend with going through an interview process at a company that likely is already lacking in diversity.

As a result, some companies don't do whiteboarding technical interviews. Instead, they might do an interview about technical concepts (with no whiteboarding involved) or you might get a take-home test where you have a certain amount of time to solve the problem on your own. In the latter situation, you'll often have a follow-up interview where you'll be asked to walk through your code.

However, whiteboarding is still a common part of the interview process - and the best way to get better at whiteboarding is to learn how to do it and then practice until you're comfortable with it.

We provide whiteboards in person at Epicodus. For students working remotely, you may want to get a personal whiteboard to practice on. At Epicodus, students often use 9" x 12" whiteboards to practice, so if you want to get one for personal use, this size is available at a low price point online.

The act of whiteboarding is very different from writing code in a text editor. That's why we recommend that you practice on an actual whiteboard - though it's also fine to practice with pen and paper, a blackboard, or for that matter, even with chalk on a sidewalk or a dry-erase marker on a bathroom mirror. The point is to get away from your computer and to actually write out your code without referring to any documentation.

In this lesson, we'll walk through the process of how to whiteboard. Even if you can't solve the problem you're given, you can use this process to solve as much of the problem as you can.

We'll use a very simple problem as an example. Let's say an interviewer asks us to write a function that adds two numbers together. Here is the process we'd go through to whiteboard this problem. This same process will apply regardless of the difficulty of the question. In fact, you'll never get a whiteboard problem as simple as the one we are using as an example. However, we want to focus on the process itself in this lesson, not the problem to be solved.

Whiteboard Interview Steps

Our interviewer has asked us a whiteboard question: write a function that adds two numbers together. However, we won't start coding yet. The first part of a whiteboard interview is to talk through the problem.

Talking Through the Problem

  1. Ask clarifying questions. First, we need to ask clarifying questions. Often, your interviewer will intentionally be vague about something or leave out information. Don't be shy about asking for clarification or more information. Here are some questions that we could ask about a function that adds two numbers together:
  • Can we assume that both arguments are numbers or could they be strings or another datatype?
  • Should the function be able to add floating point numbers (decimals)?
  • What should the function return?

There's nothing wrong with being thorough here. For example, the third question above probably seems obvious - this function should just return the sum! But it's often not obvious in an interview. And what if we'd missed a small but crucial piece of information where the interviewer asked us to sum the numbers and then return whether the sum is positive or negative? By asking clarifying questions, we are actively communicating and thinking about the problem.

  1. Talk through the most basic solution. We're still not ready to start coding yet. At this point, we can talk through what our function will do. This should be the most basic implementation. We might say something like this:

"I'm going to write a function named add that will take two parameters. Since you mentioned that we can't assume that the arguments passed into our parameters will be numbers, we will use parseInt to convert them to numbers if possible. If they can't be converted to numbers, our function will return a string that says 'please input a number'. Otherwise, if the arguments are numbers or are strings that can be converted into numbers, our function will add them together and then return the sum."

Here we've talked through the problem and how we'll solve it. Even if we have issues writing out the code, we already have a good start - and verbalizing the problem should help us write it down, too. Note that we added a wrinkle to our problem - our function might be accepting values that aren't numbers. That doesn't just affect the function itself - that affects what it returns. That means the clarifying questions we asked in step #1 were necessary to help solve our problem.

  1. Talk through a better solution if possible. If we are interviewing for more advanced engineering roles, we'll likely be asked to solve a problem that has both inefficient and efficient answers. That's beyond where we are currently at right now! However, we can always look for opportunities to make our code better. Here's an example for this problem:

"The solution I've already suggested is the most basic implementation but we can improve it further. A function for adding numbers shouldn't really be returning a string. So let's have it return NaN instead if something isn't a number - and we can always have another function that returns a user message if needed. Alternatively, we could have a separate function that checks whether the parameters are numbers first before passing them into our add function. Would you prefer one or the other or should we just stick with our most basic solution?"

Even with this very basic example, we found a way to think about improving our code. It's a best practice to keep our functions simple and focused on one thing. That makes our code more modular and easier to scale up and refactor. If possible, we should always talk through a better implementation. Even if we are only able to code the basic implementation, the interviewer knows that we have ideas for improving our code.

Now we're ready to actually start coding!

Whiteboarding the Problem

  1. Draw it out. If relevant, draw a sketch of the problem. In this case, you won't need a sketch, but anything you can use to help visualize your solution is good. For this problem, we might just write down a few example arguments as well as what the function looks like. We could start with something like this:
add(7, -5)

We might say: "When I call the function like this, I'll expect 7 and -5 to be added together and then the function will return 2."

We could be more thorough:

Arguments

3, -8
"7", 5
"wow!", 0

Function

add(num1, num2)

Then we might say:

"Here are a few different arguments the function should take. In the first example, our function should return 5, in the second, it should parse the string 7 and return a sum of 12, and in the final example, we can't parse 'wow!' so we'll want our function to return NaN."

Being more thorough is fine, especially if it helps you prepare for solving the problem.

  1. Use space wisely and write clearly. This is more challenging when working with small whiteboards. However, you'll likely be working with a full-sized whiteboard in an interview. Even so, it's easy to run out of space! You should do the following when writing out your code:
  • Start at the top left corner of the whiteboard. That way you'll have plenty of space to work with. Too often, we see students starting in the middle of the whiteboard - and then they run out of space.
  • Give yourself ample space between each line. Think of this as making each line double-spaced - with about the same height of whitespace as the code you are writing. This is because you may well need to go back and add additional code as you refactor the problem - or even if you realize you've forgotten to write a line of code or have made a mistake. This way, you'll have the space to add that code in.
  • Write clearly. This is hard for many people - especially since we spend so much more time typing than handwriting these days. Make sure your handwriting is clear and not too small. If you think it might be difficult for your interviewer to read the code, that's not a good sign. How will they be able to tell if you've written good code or not?
  1. Verbalize your process. This is very challenging at first, but you should be talking through the problem while you are solving it. Verbalizing what's happening can feel a bit like patting your head and rubbing your tummy at the same time - but it does get easier with practice. So we might be writing something like this:
function add(num1, num2) {

}

Meanwhile, we might be saying this:

"We want our function and parameter names to be clear and concise. Add seems like a good name and num1 and num2 are concise but clearly state that the function takes two numbers. And our function needs to take two arguments because it's adding two numbers together."

  1. Test your solution. Once you are done, walk through the problem again with some sample arguments, again verbalizing the process. For instance, if we've already written the following on the whiteboard:
3, -8
"7", 5
"wow!", 0

We could then walk through each line of code with these sample arguments. In the process, we may also find ways to refactor or fix our code.

  1. Admit when you don’t know something. If you don't know how to solve part of the problem, admit it. Don't try to fake your way through it - your interviewer knows how to solve this problem and different approaches. It's okay to ask questions as well. Interviewers will collaborate with you and will give hints as needed. Getting a hint or two doesn't mean you won't get the job. Of course, if the interviewer needs to write out most of the solution, that wouldn't be a good sign.

Sample Questions

The next step is to practice. You will get many chances to practice with pairs and groups at Epicodus but we also recommend practicing on your own. When you do, make sure you follow the steps above even when you're by yourself. This includes writing out the problem by hand and verbalizing your process every step of the way. The point is to write the code by hand and explain what you're doing while you're doing it.

Here are some sample challenges to work on from CoderByte. You can also find more challenging prompts in Project Euler's archives.

  • Using the JavaScript language, have the function Flip(str) take the str parameter being passed and return the string in reversed order.
  • Using the JavaScript language, have the function Factorial(num) take the num parameter being passed and return the factorial of it (ie. if num = 4, return(4 * 3 * 2 * 1)). For the test cases, the range will be between 1 and 18.
  • Using the JavaScript language, have the function Cipher(str) take the str parameter being passed and modify it using the following algorithm. Replace every letter in the string with the letter following it in the alphabet (ie. c becomes d, z becomes a). Then capitalize every vowel in this new string (a, e, i, o, u) and finally return this modified string.
  • Check out this video of two software engineers at Google performing a mock interview. Notice how the interviewee asks questions and makes a plan before starting to write. Notice how he is always communicating with the interviewer. At the 21:05 minute mark, the interview also recaps important parts of the process.

  • The articles Rock Your Next Whiteboard Test by Debbie Chew and How To Pass a Programming Interview by Ammon Bartram are also excellent resources to learn more about whiteboarding.

Lesson 2 of 11
Last updated more than 3 months ago.