I have sat on interviews and noticed a big disparity between individuals of similar competency at answering questions on a whiteboard during an interview.

Generally, being able to clearly explain your thinking, writing readable code with the dry eraser pen, avoiding long moments of silence tended to result in more favorable reviews of the candidate even though in the end the answers were about equally correct.

How can one can get better at whiteboard interview questions? Are there ways to be better prepared?

  • 4
    You say that you notice "a big disparity between individuals of similar competency at answering questions on a whiteboard during an interview". Are you sure that this is the case? Especially for a team-oriented field like software engineering, I would consider someone who can stand up in front of a group of technical people and explain their decisions and thought processes more competent than someone who can't. Of course, getting to the best answer is important, being able to work with others to get there is also very important.
    – Thomas Owens
    Aug 5, 2011 at 16:54
  • 12
    You can get better by doing it more. I always line up interviews for the less wanted jobs first. That way I can practice with the whiteboard before I get to the interview for the job I really want :-) Aug 5, 2011 at 17:48
  • 1
    Practice makes perfect - probably here too.
    – user1249
    Aug 5, 2011 at 18:26
  • 1
    Be yourself in the interview! This may not guarantee to get job. But guarantees that you get the best job you deserve. Jan 30, 2012 at 12:54
  • Definitely, the answer is practice, practice, practice! A good place to start is here: code-exercises.com/programming
    – kms333
    Apr 17, 2016 at 9:26

7 Answers 7


You should buy a small whiteboard and practice, practice, practice. Have your friends ask you questions from a book such as Programming Interviews Exposed. Then solve the problem and explain your thought processes to them exactly as you would in the real deal. Your goal is to not sound frantic. You want to articulate clear thoughts. Even if you can't solve the problem, show them that your thought process is intelligent and on the right track.

Writing answers on a whiteboard isn't intuitive. It takes practice. I used to be a teacher for one of those SAT training programs, and we spent hours training with writing on the board and explaining our thought processes. In the beginning of the program, most people stumbled over their words and wrote with horrible handwriting. By the end, we looked like seasoned veterans. You don't want to look like we did in the beginning of the program.

Moral of the story: Don't go to your interview unprepared. Solving problems on the whiteboard is something you should practice.

  • 3
    yes and it unfortunately creates a situation where the "best" candidate is the one who has done the most interviews (or is otherwise "prepared"). Sometimes this translates to a good employee and sometimes it doesn't.
    – Kevin
    Aug 5, 2011 at 18:46
  • 1
    Probably translates to a good employee more often than it doesn't, though. Rather, someone who trains and is successful is someone who: A) cares about working for the company and B) is able to succeed at things they put their mind to. If the programming questions are hard/good, then the whiteboard preparation factor becomes less significant. Aug 5, 2011 at 19:19
  • @Kevin: Of course...I'm just playing Devil's Advocate. I've expressed the same exact frustration on several occasions. Aug 5, 2011 at 19:35
  • 1
    @Kevin, it goes both ways and the risk is symmetric, except maybe for laws that protect the dumb programmers from being fired.
    – Job
    Aug 5, 2011 at 19:45
  • A good interviewer is probably going to see the potential in a candidate who is not great at the whiteboard. I totally agree with @CaseyPatton, and would add that being able to communicate will naturally help with whiteboard, and is a critical skill anyway. Conversely, if you don't know your stuff it doesn't matter how great of a presenter you are.
    – gregmac
    Oct 20, 2011 at 17:53

There are three questions that needs to be answered when you're on a white board interview:

  1. Can you solve the problem?
  2. Can you communicate clearly about the problem and the solution?
  3. Are you able to receive feedback from others?

So the solution is not the point, it is how you got to the solution, and that is what interviewers will asses you on.

Can you get better at it? Yes, you can:

Next time you have to explain something with your peers (other students if you're studying or other co-workers if you're working), do this:

  1. Drag them to the whiteboard
  2. Pick up the pen and eraser
  3. Start explaining the problem
  4. ???
  5. Profit

Oh, and don't be embarassed. Just assume that your sketches and pseudo code will suck anyway and improvise instead. The goal is to reach the answer together with your peer and always be open to feedback from your peer. Bonus points if you can solve the problems. The more you do it, the better you get at it. Practice makes perfect.

Other than writing code; learn to draw UML diagrams and to talk about them. It's all boxes, circles and arrows and the types that you usually draw are class diagrams, sequence diagrams and (very rarely) use case diagrams. And in all other cases you only need to draw boxes, circles and arrows.


Whiteboards are not just for interviews

That may strike some as a radical notion, but when I ask a candidate a whiteboard question, I am mentally comparing his or her response to the last few times a colleague used a whiteboard to explain something to me or ask me for help. It's not just a test to be administered at interview time, it's a vital day to day communication skill.

So how does that help me prepare for whiteboard questions when I'm being interviewed? I treat it just like solving a problem together with a colleague, rather than a university exam. That means I present my ideas, and when I need more information, I ask. If something doesn't look quite right, I talk it over with the interviewer until I'm satisfied.

If they want you to reverse a linked list and you don't remember what a linked list is, ask. If the end result is better, I will give you higher marks than the guy who knows what a linked list is off the top of his head, but who writes lousy code to manipulate one. It's not like you will start the job somehow magically knowing all our code and other proprietary information, no matter how experienced a programmer you are.

In my opinion, interviews are not something you can cram for, and if you could, it would skew the perception of how good a fit you are for the job, and vice versa. It's pretty easy to tell when someone's just reciting an answer they memorized. That's one reason I purposefully try to push candidates outside their knowledge zone. I want to see how they react to questions they haven't prepared for.

You might think I'm crazy, but I feel so strongly about the benefits of evaluating someone's thinking process vs. their memorization ability, that I've told interviewers when I'm essentially regurgitating an answer I've given to the exact same question at 3 recent interviews, and ask if they would like to pick something more challenging. They always ask me to "humor them" anyway, just in case I'm bluffing I suppose, but at least they are getting an honest assessment of my skills.


I have sat on interviews and noticed a big disparity between individuals of similar competency at answering questions on a whiteboard during an interview. Generally being able to clearly explain your thinking, writing readable code with the dry eraser pen, avoiding long moments of silence tended to result in more favorable reviews of the candidate even though in the end the answers were about equally correct.

I don't remember the last time I worked as an individual when developing software. I always had to coordinate my activities with others, discuss my design and implementation decisions, and work with others to construct software. Demonstrating communication skills in an interview is a huge plus. Interviews can make you nervous, but so can looming deadlines and the pressure of the job.

I would also reiterate my comment. Given the team-oriented nature of software engineering, you have to consider more than technical competence. The ability to speak and write, especially technically, is important for most positions. I would assess the competence of someone on all of the factors relevant to the job, not just their ability to build software.

What are some ways that one can get better at whiteboard interview questions?

Are there ways to be better prepared?

I can think of two reasons why someone might have poor responses to whiteboard questions: they don't have a good grasp of the technical information or they are a poor speaker/presenter. Of course, it could always be both of these.

The way to get better depends on the problem. Technical improvement comes by reading, doing, and asking questions (usually in that order). Poor presentation skills comes through practice, although some people are just naturally good speakers, while others aren't. I think that anyone can develop the communication skills, but personality will play a huge role in how good someone actually is.

Tips for how to proceed during the interview?

It depends.

More detail is always good, even to the point of total "brain dump" to the interviewer. If I wasn't giving enough information, I've had interviewers ask me to explain something in more detail, and they typically asked explicit, to-the-point questions about my design or code.

Spending a couple of minutes thinking through the problem before hand, without saying or doing anything is always a good idea. You can use this time to also ask questions to clarify what the interviewer is looking for. This will not only give you the opportunity to give the interviewer exactly what they are looking for, but also show that you can think your way through multiple possibilities.


Standing up in front of others and giving a presentation is a learnable skill. If you are weak at it, I recommend joining your local chapter of Toastmasters. You will practice some of the "here is a topic you've never seen before, now stand up in front of strangers and explain it" stress that you encounter during interviews, and especially the whiteboard portion (if any).

  • 2
    being able to talk about something you've never seen before is commonly known as BS-ing. Being able to whiteboard a solution to a technical interview is generally known as being qualified. I know because I'm terrible at the first and pretty good at the second. They're entirely different skills.
    – Kevin
    Aug 5, 2011 at 18:43
  • @Kevin, there are a lot of knowledgeable people who choke up under stress, and the OP was pointing this out. Public speaking is terrifying to many people and Toastmaster's exercises are intended to break that fear - like boot camp in the military. Feel the fear and survive it. The next time you're in a fearful situation, you recognize it, you remember that you've survived it before and it stops being scary.
    – Tangurena
    Aug 5, 2011 at 21:11
  • It's a nice theory but I'm not sure it really works like that. I've taken public speaking classes and it still terrifies me, but whiteboarding for a handful of people about a technical topic doesn't (and it never really did). It's different because it's vastly easier to speak with confidence on a technical topic that you're well versed, than on some random other topic that you know little about. Or maybe that's just easier for me?!
    – Kevin
    Aug 6, 2011 at 6:19

While others have covered the physical aspects (practice!), I'll touch on the mental aspects. Regardless of how much practice you do, interviewing is a different type of environment. You won't be alone or with your friends - you'll be with someone you've never met who's trying to judge your ability.

When practicing, always keep that environment in mind. You don't have to flatter or suck up to them - your goal is to display your competency and attitude. Speak naturally and explain what's going on in your head. They want to see how you think, so think out loud, talk, discuss, and get them to be involved in your mind.

Another important factor is rebounding. Practice problems always have solutions - when you get stuck, you can check the next step, write it out, understand, and learn. But your interviewer is not a solution manual. They will help you out, but nobody says "the next step is to do x," - they'll say "have you thought of y (which is related to x)?" So practice without always referring to the manual. Have a friend give you some vague but related suggestions, and try to build from there. Explain how their suggestion helped you solve the problem. Always show them how you are thinking.

Hope it helps!

  • +1: very helpful ...I have whiteboard interviews coming up and it is a bit nerve-wracking when you don't know what the expectations will be. I know I can explain my thought processes and that will be very important.
    – IAbstract
    Aug 12, 2011 at 14:07

Asking questions and avoiding assumptions is another point for some whiteboard questions. What may seem like, "Hey, I've done something like this before and here is the solution..." is really a question of seeing whether you'd make those assumptions and shoot off your foot. Not that it is intended to be a trick question or embarrass you, but there are generally lots of little things that if you hit any of them it'll show rather easily. A few example areas:

  • How specific are the requirements? Are you sure what the result would look like?
  • Which complexity metric is more important, time or space, and are some operations worth more considerations than others,e.g. if you are building a data structure there could be the desire for access to be faster than adding or deleting or vice versa?
  • How well can you explain why your solution is good?
  • Could you walk through an example or two showing how your theoretical solution would work? Testing cases here can be interesting to discover as if there is user input, where is that validated and how are error messages communicated, etc.

There are other areas of course but those are the main ones that I'd consider when analyzing how did I do in a mock interview.

Not the answer you're looking for? Browse other questions tagged or ask your own question.