It's not about the fanciest solution. And anyone who does it that way is foolish. It's the purest test of Language facility, and a really good springboard for all kinds of questions.
Downvoters: have you actually tried to hire someone?
In short, interpretation of whiteboard questions is too damn subjective.
I use whiteboard coding .. and it's not to catch you out on semi colons. I even tell my candidates that they can use any language they want or even mix them together or make up their own.
What I want to see on the whiteboard is a logical, working solution to a simple problem. And if your brain freezes up because it's an "interview", I'm going to push you in the right direction.
Once you have an initial working solution, we're going to chat about how it works. If there are cases where it would fail. What assumptions we've made about input. Maybe we'll (both) even jump over to another whiteboard and write a new version based on our discussion. (Do your eyes light up when we've found a cool optimization??)
The only language caveat I use: you can't have a call a function called doitforme()
(If you or anyone you know is looking for a senior PHP job in Melbourne.AU, I'm hiring. Hit me up and I'll send you to the ad on Seek)
I think far more people use whiteboard questions in that context than the article's author thinks.
" If the candidates guess incorrectly, they will fail the question, regardless of who they are or how good they know their trade."
I don't know about your experience, but in my experience candidates actually ask questions if you properly set up the problem and present an inviting atmosphere. And in my experience the best programmers are those that aren't afraid to ask good questions.
None of your alternatives "algorithms? Concurrency? Databases? Testing?" really test language facility. Those are important, and they have their place in the interview process, but so does language awareness.
And anyway, what better test of language facility is there than having the person code something? Or looking at code they've written? Whiteboarding is a weird, artificial environment that's not going to represent the coder's natural behavior in the wild.
"Whiteboarding is a weird, artificial environment that's not going to represent the coder's natural behavior in the wild."
You don't use a whiteboard when you code? I love them. The whiteboard is a nice tool for doodling and free exploration. I used to print out code and write on it, but I found that process to be much slower than the whiteboard.
So? I use google all the time while coding.
No, I don't. I find them very uncomfortable to write on, and when I have to, I thus try to write as quickly as possible, resulting in messy lettering and not caring at all if I get every (or any?) semicolon in, just so long as I get ideas across.
I suppose if I had to use one in an interview I would try harder to write neatly, but my real-life day-to-day use of whiteboards is minimal.
And what's wrong with that? I use google several times/day to help out with programming problems. This is 2013; if your company doesn't have access to the internet (and thus Google) then people aren't going to want to work for you anyway. The problem is you're trying to set up some kind of artificial situation where you want people to solve a problem without access to readily available information.
Sure, you could have them sit down at a computer that you've unplugged from the network and have them solve your problem, but why bother?
Would you hire someone who has to google for an answer to fizzbuzz?
No, but there's very little utility in someone solving fizz buzz with or without google. Give them a real test and let them use google.
But I think there should also be a real test, with Internet access available.
I had an interview several years ago. Talking with the owners, small shop (6 people? 8?). We get to a "let's code something on the white board" segment. Fair enough. "Write me some code that does XYZ" (I honestly don't remember what it was - something basic but not trivial).
I took the marker, went to the board, put the marker to the board, then turned around and asked a couple questions. They answered, I sketched out a few lines of code, and that was that.
I sat down and one of them said that I was the first person ever to ask a question before writing. Everyone else had started writing, got part way through, then asked for clarification on the ambiguous parts (or worse yet, never realized part of it was up for interpretation).
Everyone handles whiteboard tests differently, but it was interesting to me to get that perspective shared with me about asking questions before writing on the board.
I always assume that part of the evaluation is on my ability to resolve ambiguity, and always try to clarify anything I can, sometimes including writing out an example or two and verifying we agree what the expected output should be.