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.
