Yup. I'm one of those people that actually thinks being stuck in a room with an interviewer, a whiteboard and a programming problem is fun and if I were interviewing someone, I'd probably put them through the same hell.
# What, pray tell, is a "whiteboard interview"?
I'm mindful that not everyone who reads these posts is a programmer (sorry about all the mad assumptions my other posts make, it doesn't mean I don't love you), so here's a little context.
When a programmer is interviewed there is almost always going to be a part of the interview that asks them to demonstrate their programming ability by actually writing some code in front of a human being. After all, how else are you going to know if they can do the stuff they say they can? They could just send you code someone else has written and try to pass that off as their own.
Lots of companies accomplish this by sitting with the candidate in front of a laptop and "pair programming" with them. This is pretty much what it says on the tin. Two people, one laptop, some sort of goal, and an hour or so to achieve it. Candidates are usually allowed to look things up if they can't remember, which is completely fine because that's what you'll do in your day job and who honestly remembers what all of the arbitrary commands you have to feed into the computer actually mean anyway?
But there are other schools of thought on how to gauge a person's programming and cognitive abilities. One of them is the "whiteboard interview". In these, an unsuspecting victim is asked to write code by hand on a whiteboard. Gasp! Shock! Horror! No help from all of the comfortable and warm tools that the programmer would normally use to look things up and ensure that their code is neat and tidy. No sir-ee.
# But isn't that an unrealistic scenario?
This is the most common argument I hear from people that dislike the whiteboard interview: it doesn't reflect reality. And they're right, it doesn't. There are certainly times where I'll use a whiteboard to try and visualise the solution to something, or explain something to a colleague, but the vast majority of my day is spent hammering a keyboard with full access to the internet.
# So why do you think it's a Good Thing?
Learning how someone operates when inside their comfort zone, with all of the help of their favourite language and all of the help of the Internet, is not something I'd be all that interested in. It's much more fascinating and useful to see how people operate under constraint and pressure.
Interviews are almost always stressful and candidates will feel under pressure already, but what better way of totally casting them out of their comfort zone than taking away all of their tools and making them work things out from first principles? It sounds harsh, and it is a bit, but to find people who truly excel you need to put them through the gauntlet.
For example: Implement a hash map on a whiteboard. Use the language of your choice but don't use any of its standard library. So what if you've never written a hashing algorithm before, you know what they're meant to do, make one up. Make it a function that's easy to change later when you figure out it's a hard problem and your first go has poor key distribution. If you come up with a decent solution reasonably quickly, try and figure out why the fastest hash maps are riddled with prime numbers.
In a good interview, the question will start out quite simple and constraints will be added gradually until you get stuck and can't get any further in the allotted time. This is a good thing. Interviewers are dying to know where your limits are. If a candidate sails through every question with ease it's hard to know if they're amazing at working things out or they've just seen all of the questions before. There's nothing wrong with the latter scenario (it's actually pretty great, well done), it just gives less information than seeing a candidate get stuck and then working through it until they find a solution.
# Still sounds unrealistic, bro
There are going to be times where shit hits the fan. While writing code on a whiteboard isn't ever going to be necessary regardless of how emergent the scenario is, the point is that sometimes in your job you're going to be out of your comfort zone and there's nothing you can do about it. In these times you're going to have to be calm and work with whatever you have left to solve whatever problem has arisen. If, in these scenarios, you are prone to freezing, panicking, blaming, whining or being otherwise unhelpful then you aren't going to be a useful contribution to your team.
Coding on a whiteboard isn't a perfect simulation of seeing how people react to those kinds of disaster scenarios, but it exercises all of the same muscles: something has happened and you aren't allowed all of your favourite tools, now what are you going to do about it?
It's fine if you don't like it. Almost no one likes it. That's sort of the point. :)