I work at Google. We write (diagrams and code) on whiteboards on a regular basis. We don't ask you to do it during an interview because we're sadists, we ask you to do it during an interview because working here, you will be doing it in the course of your ordinary work.
Beyond that, someone who's able to code on a whiteboard will a fortiori be able to code with a keyboard and editor, and will typically code better with a keyboard and editor than someone who relies on the keyboard and editor to be able to code.
I worked at google for four months. That wasn't my experience at all. I ended up on a team that despite working in the same office, barely spoke with each other, rarely ate lunch together, lost 1 member for each month I was there, and I didn't even have a 1 on 1 with my manager until 3 months in when I asked him why he was having 1 on 1s with everyone else, but not me. It was the singularly most soul-killing work environment I've ever encountered. What is this strange concept of whiteboard coding and collaboration of which you speak?
The relevant job skill here would have been the willingness to do anything for the great pay and food. I wasn't and I had other employment options I chose after it became clear I would not be allowed to jump to another project anytime soon.
I love working at the whiteboard -- my best ideas come while working at the whiteboard. But writing code on a whiteboard during an interview bears little resemblance to the code/diagrams written on a board during day-to-day work.
Day-to-day work is necessarily collaborative and productive... Whereas when at the board in an interview one person knows the "answer" and is across the table testing the other. It's a completely different set of pressures and requires different skill.
Further, I must have one of those faces people pity because its often that when I end up at the whiteboard the interviewer wants to "help" me if I don't spout off the answer immediately (I've learned to at least start talking so they will give me a second to think). This sometimes entails them trying to lead me down a path which is not the way I would have approached the problem. I'm confused, they think I'm an idiot, now I'm flustered, could this interview go any worse?
I've learned to politely ask for a second to consider and usually that completely solves the problem. I've been successful in technical interviews -- but the idea that it's the same thing as when working out hard problems with team members seems a little silly?
... will typically code better with a keyboard and
editor than someone who relies on the keyboard
and editor to be able to code
The whiteboard sucks for problems for which you either don't know the solution, or for which you know the solution intuitively, but can't reproduce it line by line in successive order. In such cases people go back and forth, adding new functionality or correcting the existing lines to fit a new condition ... and this happens a lot for recursive algorithms. For instance I cannot reproduce the in-place QuickSort line by line, but I can work it out by evolving it from the basic idea, a process that takes a couple of minutes and a lot of corrections.
So you're basically encouraging people that rote-learn solutions and that line above is bullshit.
Leave room between the lines so you can add stuff. Mark it up as you evolve it. If you need to, you can rewrite the clean version on another part of the board. Better yet is if you can figure it out in your head before you start writing, becaus that will definitely make you a better coder.
> Beyond that, someone who's able to code on a whiteboard will a fortiori be able to code with a keyboard and editor, and will typically code better with a keyboard and editor than someone who relies on the keyboard and editor to be able to code.
That is very subjective and I'd love to see some evidence of this.