DEV Community

Sophie DeBenedetto
Sophie DeBenedetto

Posted on

How to Ace the Dreaded Whiteboard Interview

This post was originally published in Break In, a newsletter for people working hard to break in to tech. For more content like this, you can subscribe here.

For many bootcamp grads and self-taught programmers, the whiteboard exercise can be the most dreaded part of the interview process. Those of us lacking a computer science background can feel underprepared for this challenge and don't know how to turn it to our advantage. First, we'll learn what the whiteboard exercise really is and what to expect from it. Then, we'll break down a few strategies for you to ace this part of your interview.

What Is The Whiteboard Exercise?

The whiteboard exercise is really a broad term that encompasses a few different potential challenges. Broadly speaking, its an exercise that presents you with a specific problem to solve and asks you to sketch out your solution for or with your interviewer on a whiteboard.

While the traditional whiteboard challenge (more on that later) is becoming a little less popular, you are still likely to encounter some kind of whiteboarding exercise during your interview.

Why Am I Asked To Do It?

Interviewers use the whiteboard interview to achieve two goals:

  • Learn what you know
  • Learn how you think

We'll help you demonstrate both of these things to your interview. But first, let's learn a bit more about what to expect from this portion of the interview process.

Three Types

There are three common types of whiteboard exercise.

Type 1: Computer Science Trivia

This challenge involves straight-up computer science trivia. You might be asked how you would implement a binary search tree or a bubble sort algorithm. This type of whiteboarding exercise has become a lot less popular as more and more developers enter the field through non-traditional avenues like bootcamps. Companies are starting to realize that you can be a talented and dedicated programmer without knowing how some of these CS concepts off the top of your head.

So, it's become more unlikely that you'll encounter a question of this type, but not impossible.

Type 2: Brain Teaser

This type of challenge has become more common as the first type has waned in popularity. A "brain teaser" question asks you to sketch out some code to solve a logic problem. Here's an example courtesy of Code Wars:

Create a function that returns the sum of the two lowest positive numbers given an array of minimum 4 integers. No floats or empty arrays will be passed. For example, when an array is passed like [19, 5, 42, 2, 77], the output should be 7. [10, 343445353, 3453445, 3453545353453] should return 3453455.

This challenge asks you to write some code or pseudo-code to solve a specific problem.

Type 3: Design Challenge

The design challenge is a little more conceptual. You might be asked how you would implement a simple cache or data storage system. Or you might be asked to model a domain for a Netflix-like app. This challenge asks you to show off your higher-level thinking skills, along with your design skills.

Strategies to Ace It

So, how can you ace any of these types of challenges? A few strategies will see you through.

  1. State what you know
  2. Asks questions
  3. Think out loud
  4. Break down the problem

State What You Know

When you're first presented with your whiteboard challenge, you might feel like you don't understand what's being asked of you. That's okay! Chances are, there is at least some part of the challenge that you do understand. Repeat back to the interviewer your understanding of what you're being asked to do.

This will do a few things for you:

  • Help you gain a stronger sense of what you need to do
  • Demonstrate to your interviewer what you know
  • Invite the interviewer to clarify and give you more information

This leads me to our next strategy...asking questions!

Ask Questions

The most intimidating thing about the whiteboard interview is the feeling that you must have all the answers. Here's the secret: no one expects you to have all the answers. One of the main objectives of the whiteboard interview if for your interviewer to find out how you think and what it is like to collaborate and solve problems with you. Asking questions will demonstrate how you approach a problem and give your interviewer a chance to work with you, instead of just quizzing you. Not only that, it will provide you with the answers you need to solve the problem.

Worst Case Scenario: You Have No Idea What's Going On

If you are presented with a challenge that you really don't have the context to solve, say so. Just because you have no idea what a binary search tree is doesn't mean you're going to blow the interview. Admit what you don't know and ask lots of questions. Chances are you interviewer will provide you with enough background to get started, and you can still show them how you think and solve problems. On top of that, you can blow your interviewer away with your honest and confident approach, and by showing them how you operate in the face of a big unknown.

Think Out Loud

If one of the main objectives of this portion of the interview if for the interviewer to learn how you think, you need to show them exactly that. Stating what you know and asking lots of questions really helps to demonstrate how you solve problems and what it's like to work with you. Beyond that, state out loud your objective before you started sketching out code on the whiteboard.

Every problem can be broken down into smaller problems, so once you've identified the smaller problem you're focusing on, say so. For example:

In our Netflix domain model, we will have lots of different components: users, movies, tv-shows, watch lists, genres, etc. I'll start by modeling the relationship between a user and their watch list.

The more you can illustrate what you're thinking but talking through the problems you're solving and how, the better your interviewer can see what you're really made of.

Break Down the Problem

Every big problem is made up of lots of smaller problems. Identify some of the smaller problems you need to solve and then just pick one. You can identify the smaller problems by relying on the first two strategies: stating what you know and asking questions. By dialoging with your interviewer, you can gather the info you need to pick a starting point for your solution.

Once you've picked your smaller problem, create a solution for it. Only then can you move on to a larger problem.

Resources to Level-Up

The best way to prepare for a whiteboarding interview is to practice and keep learning. There are lots of great resources out there for strengthening your code problem-solving skills.

To strengthen (or create) your CS chops, you can sign up for the free weekly CS problems provided by Interview Cake. You should also checkout the bible of CS interview questions: Cracking the Coding Interview.

To practice your code brain teaser skills, check out Code Wars or Code Kata.

To practice your whiteboard design skills, grab a pen and paper and start brainstorming! Pick a few app ideas and sketch out on paper how you would build out certain features. How would you implement a live-chat in a web app? How would you aggregate and display a user's daily social media trends? How would you model the relationship between trainers, Pokemon and gyms? What about Pokemon trainers and their rivals?

Top comments (2)

jfrankcarr profile image
Frank Carr

I usually ask the design one in interviews. I try to tie it back to something the candidate has done rather than something abstract like "design Netflix". For example, I would ask...

"I see you worked on a web service project at your last job. Could you sketch out how this was built and describe how it functioned?"

"I see you took a class on design patterns. Could you sketch out your favorite design pattern and describe it?"

simonhaisz profile image

The fact that the first two types are still a thing is ridiculous, as far as I'm concerned. Neither is particularly good at evaluating a candidate.

I'm curious about others experience, as either the interviewer or interviewee, on how much a white board is actually involved in interviews. Most on the interviews I've taken part of we just talk most of the time. I almost never ask someone to sketch something out, I just ask them to describe it. If they have trouble articulating I'll offer the whiteboard if they think it will help. But actually asking "please draw your solution" is not something I'll explicitly ask and my colleagues don't do it either.

Does that make me an outlier? Is there some specific value you see in having people sketch out their designs?