As many other parts of an interview, I've always found the blackboard coding session extremely strange. When was the last time you coded in TextEdit with no docs around, no time to think, standing up, and being watched over the shoulder?
However I realize I may have a bias as I do ok on most blackboard coding interviews I have done.. maybe been stumped 1 time out of 15 or so in my life? Some of it is a skill, that the more you do the better you get at it, but being good at it does not make you good at actual coding.
I'm very good at memorization (of facts, ideas/concepts, and procedures/algorithms) and that allowed me to do well in my younger years and in standardised testing, so I always just scoffed when I heard other people complain about how it was a poor proxy for knowledge / abilities.
Of course, now I'm terrible at pretty much all the standard ways of interviewing developers (...here's where you say I'm probably just a bad developer) and now I have all this past-due empathy for those I disregarded before.
In my experience, some interviewers, particularly Amazon interviewers, get really anal about putting correct code on a whiteboard, sheet of paper, or bare text document. I personally do not when giving interviews.
My bigger problem, and I seem to depart from the vocal majority on this, is that my preferred normal workflow does not use whiteboards for anything besides task lists and diagrams. In 13 years[1] as an engineer I have never written actual or pseudocode on a whiteboard outside of an interview. I rarely do it on paper. I have never worked with anyone who did this very much, either.
[1] Granted, four of those were as an EE, but I still had to deal with code from time to time
I had that experience with an Amazon interviewer. The guy who told me he expected perfect code also gave me zero feedback as I worked (despite me literally asking if I was headed in the direction he expected) and spent the entire time staring at his laptop. He'd apparently forgotten that he was scheduled for an interview, and also his manners.
A valid question, but paper-code?
Edit: Oh, and how do you version control the white board?
We have a magic white board that can print out a big piece of paper showing everything on it. We also take pictures of it (and lesser white boards) to record designs agreed. Those pictures generally get put into a formal design document that is reviewed, signed, approved and all the rest of it.
Explanations work better without lengthy pauses. Ideally, I can explain the thing without stopping too long.
> Why don't you use documentation?
I do if it's necessary. Sometimes it's not necessary.
> Oh, and how do you version control the white board?
I don't.
My original comment was mostly meant as snark, but I've had an interviewer take photos during a whiteboard exercise for this reason.
The resulting svg or png can be then added to the docs folder of a project. Works well with sphinx, etc.