As I get it, having an error (even a typo like or missing ";") in your whiteboard code will often cost you some interview points. Avoiding that will inevitably make one proof-reading code again and again (losing time and possibly neural energy / concentration) or even using a simpler (and thus less effective) algorithm -- and both these ways are "costly" again!

So, why not just fast write code as elegant and effective as you would having a (unit) testing framework at your disposal and then just normally test it it (just on the whiteboard)?

Has anyone tried / seen this approach? Is the whole idea worthy?

[this also applies to the pen-and-paper case of course]

  • 23
    If I wanted someone to write code on a whiteboard or paper during an interview I wouldn't expect it to be 100% syntactically correct - that's putting them under too much pressure. Yes it should be broadly correct, but missing semi colons or even getting a method name/parameter profile slightly wrong is (or should be) OK.
    – ChrisF
    Nov 4, 2010 at 12:25
  • 17
    I'm a big fan of whiteboard coding in interviews, but anyone who's expecting your whiteboard code to be syntactically perfect is doing it wrong. The point is to see how you attack a problem, not to see that you can produce syntactically perfect code in a totally unrealistic environment. Nov 4, 2010 at 12:57
  • 3
    you should be able to tell which is which by asking them to give a running commentary on what they are doing for example or discussing the solution with them after they finish.
    – ChrisF
    Nov 4, 2010 at 13:07
  • 6
    Being overly concerned about exact syntax and spelling will cost the interviewer points in my book.
    – JeffO
    Nov 5, 2010 at 16:17
  • 2
    this is what psuedo code is for
    – jk.
    May 18, 2012 at 12:33

8 Answers 8


I absolutely want you to test the whiteboard code I ask you to write. I want you to talk out loud while you write it, look it over, spot most of the syntax mistakes you made, and point out how it could be more efficient. In fact, that's kind of the point of doing it at the whiteboard. It's not a one-shot, write-it-all-out, uh-huh-you-get-70/100 kind of thing. It's a conversation, mediated by code and held at the whiteboard instead of across my desk.

Here are some great ways to fail the "Whiteboard coding" test:

  • refuse it
  • don't ask a single clarifying question (language, platform, something about the requirements) AND don't tell me your assumptions about any of it AND make assumptions that are way off what I would have answered

(eg: write it in Fortran, interpret "display" or "print" as "write to the event log", that sort of thing. I might allow it if you told me in advance those were your assumptions)

  • ask me what language I want it in, receive an answer that is in the job description, and then write it in a different language because you're not comfortable in the language I asked for.

(We're consultants here. I am testing for consultant behaviour as much as coding. Asking the client is only correct if the client actually has a choice. Controlling conversations with people who will pay you is hard. This is lesson 1. It's a mark against you on any topic, but for the specific "you're hiring an X programmer but I don't want to write in X for you" you now have two big black marks.)

  • show me what an architecture astronaut you are by filling two whiteboards with interfaces, factory patterns, abstractions, injections, and tests when I wanted you to "print the numbers from one to 5".

(you think I'm exaggerating but I had a guy who generalized my problem dramatically - sticking to the example above let's say instead of 1 to 5 his solution would do any arbitrary sequence of integers (got from where? I wondered) and was 5 times as long as anyone else's - and he forgot to actually call the function that did the work. Repeated prompting and suggesting that he walk through it as though he was the debugger did not lead to his noticing that the function was never called.)

I always say "do you like that?" "can you improve that?" "walk me through that" and the like. Typically the missing semi colon gets spotted, or the off-by-one, in that conversation. If not, I usually mark it up to nerves.

Other things you may not think matter at the whiteboard that matter to me:

  • when you're done, can I still read it? Have you smudged, scribbled over, switched colours, drawn arrows, crossed out and generally left a mess that can't now be used? Or are you aware that whiteboards are erasable, pointed to lines of code in the air instead of circling/arrowing them, and left me something I could take a picture of and keep in the design file?
  • how much did you ask me as you did it? Do you like to be left alone and not discuss your code, or do you see code as a collaborative thing? How did you respond when I asked you things while you were still writing it?
  • did you sneer at the "easy" task or faint at the "hard" one? Were you rude about being asked to show you can code? Are you easily intimidated by a technical problem, or arrogant about your ability to come up with a good algorithm?
  • are you working it out in your head, or remembering a solution you read somewhere? I can usually tell for the hard problems.
  • did you plan ahead about where you started writing? Folks who run out of whiteboard usually start too low or write too big - I can tell they didn't know this was going to be 20 lines of code and so only left room for 5 - believe it or not this tiny detail is mirrored in bigger estimating tasks as well.
  • did you look it over before you said you were done? Did I see you pointing or tapping your way through it and testing it yourself before I asked you to? When I prompted you, or asked you specific questions about it, did you look at it again, or just go from memory? Are you willing to consider that your first draft might not be complete?

I strongly recommend practicing coding at the whiteboard. I always warn interviewees that they will be asked to do it. If you have access to an actual whiteboard then set yourself some simple problems and practice doing them there. It will help your performance and your confidence.

Sorry I know I'm in TL;DR territory but here's the thing - coding at the whiteboard is about more than coding. It's a test of more than your grasp of syntax. There are a lot of behaviours of good programmers that are demonstrated in your response to this task. If you think it's only about coding you are missing the point.

In other conversations about whiteboard testing, people tell me I may reject a good candidate with it. Honestly, that's a risk I'm willing to take. Every hiring round contains several people I could hire. Some people with great resumes, who are doing ok in the question-and-answer part of the interview, fall apart at the whiteboard and clearly cannot (with any amount of prompting) write simple code in the language they claim to know. I might have hired some of these. Any tool that prevents that is a tool I will continue to use. I have never ended up in a no-one to hire boat because all my candidates messed up at the whiteboard and I don't expect I ever will.

  • 2
    Seems to be one great answer (and to be honest far more intersting that I initially hoped to receive). Many, many thanks.
    – mlvljr
    Nov 4, 2010 at 15:55
  • 9
    @KingOfHypocrites did you actually read the answer? I don't care about missing a semicolon. Look what it says I care about. 20 minutes at the whiteboard tells me a lot about you. May 18, 2012 at 13:56
  • 7
    I am curious if any research has validated the whiteboard interview. Full disclosure: I became curious after just failing a whiteboard interview, hard. I haven't interviewed in a few years, have never been a good performer/presenter and pretty much froze up. Your insights are excellent and had I read this first I would have thought about that part of the interview process much differently (and talked more). That said, many people have strong opinions on this topic but that appears to be all. I assume there is an objective justification for this practice, backed up by supporting data. Is there?
    – Suboptimus
    Jul 30, 2013 at 5:22
  • 3
    +1 To be honest, I'd approach the whiteboard as a proxy for an exercise in pair programming, hoping to keep up a flow of conversation about the task as Kate suggests - though I'd rather have a machine and actually pair program with the candidate (or be the candidate pair-programming with the interviewer). How you code together is as important as how you code alone, in an organisation of any size. Dec 12, 2014 at 11:41
  • 4
    I know this is old but I just got linked to it, and I wanted to point out: one of the hallmarks of a visual processing disorder is lack of ability to estimate the space you're writing in and therefore ending up running out of room. If the person you're evaluating not only runs out of room for more lines, but also has characters get smaller toward the end of a line as they realize they've begun too big, they might just have a learning disability rather than not understanding how long the code will be. Ask them to estimate something non-spatial and you may get a better result. Dec 12, 2014 at 14:00

I think you've made an incorrect assumption here. There's no way I'd expect a candidate writing up code on a whiteboard to be able to get every ';' perfectly in place. If you're interviewing at a place which does penalise you for that then I suggest they're not an organisation you want to work for :-).

  • 3
    I failed one interview because, as they said, I hadn't written perfectly optimised code on the first pass on a pen-and-paper test (being from the get-it-working-with-unit-tests-then-optimise school). Then again, they had no testing framework in place, they just assumed they had coders who did it right first time! Dec 12, 2014 at 11:38
  • 3
    @JuliaHayward - A Lucky escape for you by the sounds! Can't believe people still do that. Dec 12, 2014 at 13:03

Paper or whiteboard tests are extremely ineffective. I remember once I had an interview where I had to look for errors in some code on paper. One of them was that the class inherited from an interface but was missing the implementation of a member. I knew this was likely to be one of the errors, I was looking for it and for whatever reason on the spot I just couldn't see it (although I did mention that I was looking for that as one of the issues).

As it happens, I still got that job, but it did make me think about what had happened. In a realistic scenario for that sort of thing I'm going to get squiggly lines the moment something's wrong (this is C# in Visual Studio) and the thing isn't going to compile. I never check for this in real life because it never happens (it is impossible) and hence I'm de-tuned from seeing this sort of thing. Missing semi-colons are an even more extreme example of this - totally unrealistic in the real world unless you're writing in notepad and e-mailing your code to someone else to compile!

If someone asks to use a whiteboard during an interview to support something they want to say then great, but I'd never do it the other way around.

  • 2
    Your story seems to prove that your test was effective. Instead of generally asking "How do you review code?" they gave you some to review. You talked out loud and said something like "must make sure it implements everything" and even though you didn't happen to spot the missing one, you showed them that you actually know how to review code for errors, not just answer questions about it. You also probably didn't point out a bunch of non-errors that some folks might have, and perhaps you saw some other errors too. And then you got the job. That sounds effective to me, for everyone! Nov 4, 2010 at 16:33
  • 2
    Also, missing semi colons keeps being dismissed as not a real negative. Consistently mistyping the syntax of your preferred language means you are a slower developer than someone who has internalized all that syntax. You are constantly going back and fixing stuff you forgot. There's a good chance you are thrown off your rhythm with the constant nagging from the IDE. In addition, the people who leave off all their semi colons at the whiteboard and don't notice when you prompt them are not at the same level as the good devs who once a week forget to type a semi colon in the IDE and then fix it. Nov 4, 2010 at 16:41
  • 3
    +1 it's ineffective. It prove absolutely nothing. I'm pretty sure a lot of people that fail the test are better than the average guy that pass it.
    – user2567
    Nov 4, 2010 at 18:22
  • 4
    @Kate - I get where you're coming from, but I disagree - especially as I now sit on the other side of the table. If someone is missing semi-colons regularly I want to see that in the IDE not in an artificial setting. It's like the keycode to my office - I can type in the number without thinking, ask me to write it down with 100% confidence and I'd be struggling. An interview is never going to be 100% realistic so I don't want to go out of my way to make it even less so.
    – FinnNk
    Nov 4, 2010 at 22:37
  • 1
    I am much less likely to omit important syntax at the keyboard than at a whiteboard, because typing is reinforced by muscle memory. However, mistyping (and a nag from my editor, or the pair partner), especially in a pair programming situation, is likely to throw me into a feedback loop where the errors reinforce nerves that cause errors. I think polyglots are likely to be disadvantaged over monolingual candidates.
    – dcorking
    Mar 18, 2015 at 9:57

I've done that. At an interview I was asked to implement run-length encoding on the whiteboard, and while I short-cut some of the code (explaining what I was abbreviating) to fit the whiteboard I still came up with a collection of tests for this unit, and ran through one of them to validate my solution and show how the testing would help. I was offered that position so I assume the testing was helpful, or at worst not annoying.


Asking a candidate to code on a whiteboard is silly. There are modern tools like snippits, jsfiddle and intellisense. In addition no engineer should be required to memorize syntax. Syntax is looked up and referenced. If you are memorizing code, you probably didn't spend any time in your career learning how to code in a mult-tenant environment, optimizing syntax or even a hosted environment.

  • 3
    Anyone halfway decent in a particular language should have the syntax memorized from simply using it a lot. If a guy writes C# code all day, and doesn't know most of the syntax off the top of his head, he's going to be slow and terrible. You can also look up what 2^8 is, but any developer worth their salt should know what it is off the top of their head just from having encountered it so often. Same goes for syntax. Mar 18, 2015 at 4:24
  • 1
    That is simply not true. Memorizing syntax in this day and age is not necessary. To say developers that know how to code in numerous languages like sql, vb, c#, javascript and use json, angularjs, telerik and others are not worth their salt because they cannot memorize syntax is silly. There is more to being a good software engineer than mathematical operators like you list. How about understanding requirements, design structures, patterns, industry experience? There is literally enough syntax in languages and libraries to fill the back of a truck. Mar 19, 2015 at 20:37
  • It's not a matter of being "necessary". It's that if you use something often enough, you're going to remember it. If some guy claims to be a SQL developer but can't write a join statement off the top of his head, it's because he is either a) incompetent b) was lying about his qualifications, or c) has a very strange brain, all three situations I don't want to have to deal with. Mar 19, 2015 at 20:49
  • 1
    A "join" is not what is typically asked on a whiteboard. It's often riddles and things not relevant to the job. What if the candidate is certified, has a degree and has a robust resume. You still think he is "incompetent" because he doesn't code on a white board for a living? Marketing people are not asked to white board a quarterly marketing strategy on interview spots. It's silly. You should be able to talk with the candidate and easily deduce if they can code. Mar 20, 2015 at 15:57

I use this approach when taking tests for school. I first write the function, then off to the side I write a little table of inputs, outputs, and vars. I've caught a few stupid errors this way. Testing, even on-paper/whiteboard testing, is always better than not testing.

I disagree with freaking out over semicolons in a professional setting, though.


When a restaurant wants to hire a chef, the owner doesn't ask him to cook a "pot au feu" with a toothpick and a cap.

Don't ask a developer to code on a whiteboard in an interview.

  • 3
    And when asked?
    – mlvljr
    Nov 4, 2010 at 13:05
  • During the interview
    – user2567
    Nov 4, 2010 at 17:55

White board coding is tough. I was never introduced to that until I was interviewed by Disney. Not knowing what to expect and not being able to debug it, I stumbled through it talking it through and solving the problem, but in a pseudo code kinda of way. When they asked could it run.

I mean sure it could you just have to fix the syntax errors, correct. I believe they lost a very good candidate if I was not hired because of the whiteboard. I look at the qualifications and it looks like I am way qualified for the position and can do the job. I excel at the current job I am at and wished I could with them.

Thanks for your input Kate, I read every word. It's just to me as a programmer, white board really doesn't show your skills. I'm a great programmer that work in multiple languages. I knew the language I was asked to program in, but on white board I suddenly forgot.

I build complex integration and credit card processing, but on white board I couldn't remember how to even do proper syntax nothing prompt me.

As an employer I do like the white board testing; however, I am hiring a programmer I want to see their actual skills if they do the job. It's great if they can communicate, but I need to see them be able to solve problems.

  • 1
    Thanks for the input, seems, it's right about what I was thinking when asking the question -- one can really stuck in a whiteboard code not knowing if it is (already) correct, and having no means to "actually" check it. A tricky solution -- write a whiteboard test! ;)
    – mlvljr
    May 18, 2012 at 21:19

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