You want a job writing computer programs. To get this job, you’ll almost certainly need to do at least one technical interview. The point of this is to evaluate your knowledge and ability at solving technical problems. A very common style is called the “whiteboard” interview. They are notoriously difficult. Interviewing is already stressful enough as it is, but having to hand-write tricky code in front of an audience who’s job is to judge you is just brutal.

I’d like to offer some tips and tricks to use before and during a technical interview.


Let’s start with a quick definition. To me, whiteboarding is an in-person interview where the candidate has to solve a problem by hand-writing a solution. There definitely has to be hand-writing involved, but a whiteboard isn’t strictly required. Because computer science puzzles are so frequently asked in these kinds of interviews, it’s common for people to use “whiteboarding” to refer to this kind of question. That’s what I’m doing here.

Technical interviewing, and the puzzle-on-a-whiteboard-style in particular, is a very contentious topic. I’ve conducted ~ hundreds of interviews, and for years I asked whiteboard-style questions. It took me an embarrassingly long time start wondering about the effectiveness of this technique, and even longer to try other methods. But, now that I have, I am firmly against this approach. I believe it is a poor evaluation technique. But, what I think is not relevant. It might be losing favor, but it is still very common.

If you want to land a job at a tech company, it’s very likely you’ll have to do some whiteboarding.

Traditionally, a whiteboarding interview was done in person. More and more, interviewing is being done remotely. The whiteboarding interview could be replaced with a pair-programming tool or screen sharing. I have never been the interviewee or interviewer for a remote technical interview. While some of what I cover here might be helpful in a remote context, a lot of it is geared to an in-person setting.


- topics

Focus is often algorithm and/or data structures. Things like linked-lists, trees, and searching within strings. Perhaps the most (in)famous whiteboarding is FizzBuzz. Recursion can come up. Big O and performance is often discussed, can even be a primary aspect of the problem.

- research

This one is a no-brainer. There are numerous places online where you can learn about the kinds of questions asked at larger companies. By no means does this guarantee you’ll find questions ahead of time. But, I think it can be a great starting point for your preparation. Also very helpful if you have target companies and/or interviews already lined up.

- study

Because everyone knows whiteboarding is common, especially at larger tech companies, people study. And I mean I have heard of people doing hundreds of practice problems. I think at least some study is a very good idea, especially for data structures.

- services

I’ve noticed others enjoying both leetcode and codesignal. I haven’t used them much, but they do look like they add some fun elements to the work.

- reading

I know of two books written on the subject, if that’s your style. Check out De-Coding the Technical Inteview Process and Cracking the Coding Interview.

- flash cards

I stumbled across a pretty noval way of studying programming problems: flash cards! Might be just the ticket for certain people.

- hand-writing code

I think there is enormous value in just standing at a whiteboard and writing code. The first time I ever did this was while being interviewed. Not ideal. Have you ever tried to write an actual curly brace? This all sound silly, but the hand-writing element can really throw you off. Do not underestimate how different it is from using a computer.

I think it also could be quite useful to practice writing code with a pairing tool. Even though a lot of the challenges of the physical whiteboard are removed, it’s still something you don’t want to be doing for the first time ever in the interview.


- make sure the task is clear

This is your first priority. You must make sure that you understand exactly what problem you are being asked to solve.

- come up with test cases

For questions that involve accepting input, write down some test cases. This also helps to confirm you understand the problem. Start trivial, and build up. Move on to edge-cases. Think about zero-length arrays, null pointers, negative integers. Don’t let them surprise you.

- talk about performance

Performance can be a critical part of the evaluation. Be ready to talk about Big O (Big O).

- be extremely careful with names

Go very slow and deliberate when naming functions and variables. A poorly-chosen variable name can really add difficulty. As you work, make sure you update names as logic changes.

- manage space

Be careful with the physical writing space you have. Things can go from a big, intimidating empty board to a cramped mess fast.

I’d recommend thinking about three separate areas. One is for discussing the problem and writing out test input/outputs. The other two are coding areas. You cannot copy/paste, so two spots give you space to rewrite, if needed, without having to erase.

erasing code

I’ve noticed one almost universal problem people have when writing code on a whiteboard - they are hesitant to erase. This results in so many problems. Someone’s first thought is a for loop, and now they are struggling because it would be much easier to do recursively. A variable is named “currentNode” when “nextNode” is what they need. It might sound surprising, but people get locked into what they write. Particularly for names and flow control.

You have to be really consious of this problem. This is one of the reasons I recommend keeping two separate spaces for writing down code. This way, if you being to have issues, you can try another approach without losing any work.

if you get stuck

- explain the problem

Talk about what isn’t working. Don’t just stare, think out loud.

- fall back to your tests

Stop, take a breath. Run though a simple case again.

- reset

Are you using the right kind of loop? Is there a tricky case you can handle before/after your main logic? Is your function signature ok? When in doubt, start again.

- finished vs perfect

You should assume that it is better to finish and acknowledge weaknesses in your solution. If you are struggling to handle an edge case, state that and continue. If you have time for another attempt, you can refer to your previous work (two coding spaces!).

you got this

Whiteboarding can be brutally difficult. Standing up in front of people to hand-write code is such an unusual and uniquely stressful experience. Many people, myself definitely included, have stories about whiteboarding interviews they completely bombed.

But, hopefully these tips on preparation and hand-writing code help to improve your chances.