I Hate Whiteboarding In Tech Interviews

you vs whiteboard

You’ve experienced this before — I know I have.

When you’re at your desk and at the keyboard, ideas just seem to flow out from your brain and into your fingers. Magical characters and symbols representing computer instructions appear on the screen and in just a matter of moments (it seems like) you’ve turned someone’s vision into reality.

You’re a decent coder, always had a knack for it, and you pick up code-related things faster than most people.

One day for whatever reason, you decide to find a new job and you go in for a technical interview. Everything is smooth sailing because you know your stuff; you’re a hard worker after all and most importantly you’re passionate about your craft. But then the interviewer asks you to whiteboard.

As they are giving you some high-level requirements to the system, their voice unfortunately starts fading into the background. Your vision blurs, emotions and thoughts take over, and the voice inside your head interrupts them and says “ARG. I hate whiteboarding. I code for a living, not whiteboard for a living, gosh clackety dangit!”

Embarrassingly, you ask them to repeat a few things. There’s a break in your rhythm. There’s long pauses of awkward silence……… The rare moments you speak, your thoughts now come out in stiff staccato instead of the beautiful and buttery, lovely legato from earlier. Uhhhh. Ummm.. So yeahhh.

You make it through but it’s a struggle. If you’re lucky, they are nice and help you through it. When they’re not, you get absolutely murdered.

Regardless, you walk away feeling dejected. You think that somehow if you were in front of a keyboard on your own computer coding with a familiar face, you wouldn’t have failed so miserably. In reality your results probably weren’t as dramatically depressing as you’re thinking. But in that moment you feel as if all your hard work amounted to nothing.

After the emotions subside, a moment of reflection follows. The voice inside your head asks, “Why DO I do so badly in whiteboarding interviews?”

Maybe this never happened to you. Maybe I imagined it all and it never even happened to me. Maybe we’re all imaginary… But it did happen. And I don’t know about you, but I never want it to happen again so I finally decided to think it through.

The Problem With Being Self-Taught

The first thing I want to point out is that if you started coding as a self-taught programmer, chances are you have picked up a bad habit of solving technical problems by coding and designing (software) at the same time. Even if you get some formal education later, it’s highly likely you will default to this habit when sh… stuff hits the fan.

The reason I say that it’s a bad habit is because for humans it’s generally way more efficient to do one single thing at a time so that you don’t incur the overhead cost of something called context switching. This is the same reason that the assembly line revolutionized manufacturing.

In this case it’s better to separate the planning (analysis and design aka architecting) from the execution (coding) and perform them separately. Both planning and execution are composed of several smaller pieces as well and chances are you don’t have a specific, systematic sequence in mind. You’re unconsciously inconsistent in your approach, even if it’s tiny variations, which makes the habit even worse.

If you’ve been coding for a very long time you have internalized this inefficient, semi-random process in a very specific environment (at the keyboard).

During the whiteboarding interview process you are now

1. asked to do only a part of it independently — something that’s a drastic departure from your default workflow
2. asked to solve the problem in a different environment from what you’re used to (whiteboard instead of keyboard)

And when getting a job is on the line, palms are sweating, and nerves are firing then it’s pooooof! Implosion happens. On the outside it’s deer in the headlights — not a great look when you’re trying to impress.

So how can you fix this? I’m glad you asked, imaginary person.

What’s Going On In Your Head, Eh?

The first thing to do is be consciously aware of the habit you’ve internalized and begin recognizing the different parts. This accomplishes two things:

1. it allows you to identify, group, and batch similar activities together so that you can avoid context switching
2. it allows you to isolate each grouping so you can improve each one independently

As mentioned earlier, the two high-level groupings are planning and executing. When you’re whiteboarding you’re essentially only doing the planning part.

Let’s revisit what’s actually going on inside your head when you’re solving a technical problem ad-hoc on the keyboard…

You think about the problem for a second, then you begin typing code. You then realize you don’t know exactly what you’re doing yet, so you backspace a little bit — maybe a lot — and you think about what you’re doing some more. You think you figured it out and you begin typing some more and then oh wait, you just realized you forgot something. Okay, you get the point.

You’re weaving in and out of planning(ish) and execution mode and it’s repeated a few gazillion times until you solve the problem. As you’re typing code, you realize repeatedly that you can’t proceed because you haven’t loaded the whole problem in your head and you’re discovering different parts of the problem as you go.

Described out loud like this, it sounds like a slow process; but the fact is you may have gotten pretty fast at doing it this way. But imagine how much faster you can be if you reduced context switching and had a more systematic approach. I am betting even faster than you are now.

The Light Bulb(s)

Now that we’ve set the stage and made you read around a thousand words, let’s extract the different parts of the planning process that you’re weaving in and out of and list them all together.

First, your brain tries to interpret, understand, and frame the problem. Somewhere along the way, it gets confused and starts asking questions that need answers. It may ask “okay, who all is actually using this?”. That question may then lead your brain to ask “how does each person use it?”. Which then leads to another question “how does each user’s interaction with the system connect with the other users?” or “what is the complete high-level workflow among all the users of the system?”

At this point, you now probably have a pretty decent understanding of the problem BUT… instead of moving on to the execution part to begin coding, you can still take the planning process even further. You can now begin modeling the whole problem domain and visually create a blueprint of what you’re going to code.

If you think about people who construct buildings: even though they know what they’re building, who they are building it for, and how it all flows, they don’t just try to keep it all in their head — they go off a literal blueprint. Made by an architect.

— aha! just like a software architect!

— another aha! The thing I described is exactly how you should approach the whiteboarding process during the technical interview. But instead of brain asking questions quietly, mouth asks out loud so requirements can be clarified with interviewer.

— aha! this is also how you approach things with a stakeholder when building a product for a real customer!

— zomg another aha! so that’s what all that UML stuff (from CS classes) was for…

That’s right. Whiteboarding Is Not Useless.

Okay hopefully by now, you’ve connected all the dots together as I have. Learning how to whiteboard for a technical interview is not useless and only done for the sake of interviewing.

It makes you faster and more efficient due to the reduction of context switching via correct sequencing of tasks. It also teaches you to go from a primarily ad-hoc planner to a more systematic planner which will result in better software designs.

Whiteboarding teaches you to be a software architect and not just a coder.

So in summary here is my abridged version of the process for whiteboarding and architecting software (in academic circles, also called Object-Oriented Analysis & Design)

1. Identify the users of the system and determine their use-cases
2. Create a flowchart of how the users, their use cases, and the system all interact together
3. Model the system by identifying all the objects (usually some of the nouns produced from steps 1 and 2), what their responsibilities are (usually the verbs), and how they collaborate

It’s as easy as 1, 2, 3! Now you can stop hating whiteboarding in technical interviews — or not. At least you won’t be as bad at it.

But seriously if you want to know more details about this process you can click here. You’re welcome, imaginary person and Omar El Gabry.

Paying It Forward
I try to put a lot of myself into these articles because I feel like if I can help someone avoid the pain of the trials and errors that I went through, then I’m doing something to make a difference. Awww… ain’t that mushy? But seriously though it’s true. If you like what you’ve read please give a few claps or, even better, follow me so I know that sharing my thoughts helped someone think differently.