Is asking a person to solve a problem by whiteboarding code a good practice for conducting interviews?
Is this a good method for determining the qualifications of a candidate? What does this accomplish? Assuming the candidate has shown to sufficiently know the language in question, is whiteboarding code necessary? Might some developers perform more poorly than their capabilities under pressure?
How useful is this as a device to determine whether a job candidate is qualified?
Most people, in an interview, will react differently than they do in a day-to-day situation. As long as you realize that nerves play a role, I don't think there is necessarily anything wrong with whiteboarding code during an interview. However, just like testing, there are some people who will do much better at this than others, and I don't think this is necessarily a good indication of their ability to be productive on a routine basis.
I personally don't bother with this when I interview candidates. A few pointed questions, asked in a non-threatening way, goes much further to finding out how a programmer thinks about different situations, and how they might try to handle something.
If I really want to see them write some code, I'd probably ask them to do it there, but not necessarily with a bunch of people watching them, in an already tense situation.
I always ask candidates to write something, usually on paper. Typically they're not very difficult problems but at least something that shows their understanding of the language and object oriented concepts. I will adjust the difficulty depending on the level of the candidate. Joel Spolsky wrote an article a long time ago and it said that you wouldn't hire a magician without seeing him do tricks. It's the same thing.
Part of being able to work is working under some pressure, so a simple problem shouldn't be too difficult to solve.
There are somethings a programmer must know off the top of their head. I use whiteboard questions to filter out the candidates who can talk well but don't put their head knowledge to good practice. Sometimes a (very) simple question about string manipulation or recursion will tell immediately how well a person knows there stuff. I try to relieve the pressure as much as possible by offering paper if they prefer, and giving as many hints as possible.
Solving problems is certainly valuable.
Coding, at a senior level, is worthless, IMHO.
I hate hand-writing. I can't do it for longer than maybe 10 minutes, without getting annoyed. There are no legitimate problems that I solve daily that can be written in code on paper. Either the code is so obvious that it's a waste of time to write it (i.e. Serialise this thing, write this collection). The things I write down in day-to-day work are plans and ideas, not actual code.
I can be fairly arrogant, and a few years ago I was asked to solve some silly puzzles (write a tic-tac-toe game) and I effectively walked out and told them just how silly I thought it was. So for me, asking me to write code is an effective way to have me leave. If that's what you're after, good for you :)
On the other hand, I have been asked to write code at a computer; and I'm more than happy to do that. I've also been asked to solve general problems on a whiteboard, and I'm happy with that as well.
I believe coding makes you have a lower risk. You can find developers who can talk a lot, but when they need to write something, they simply get stuck, or come up with completely inefficient implementations.
But don't expect interviewees to come up with something good immediately. Try to let them improve their code while you discuss it. I believe the process of improving code is more valuable than just writing it (by improving I mean making it not only more efficient, but more readable, more testable, etc). That's what he'll probably spend most of his time.
Another possible suggestion is to give him some pre-written (maybe inefficient) code, and let him refactor it, or change a little what the code should do. This should help you notice how he behaves when he needs to understand and improve somebody else's code (another very important aspect).
Finally, try to put him in a more familiar environment, and bring a laptop with a text editor (possibly with main IDEs from that language), so that he'll feel more comfortable.
I would say that whiteboarding code it is useful but not so much seeing if they know a particular language but to gauge how a candidate thinks - the way they approach the problem, how they refine the solution once they figure it out. This tells us if they think the same way as the rest of the team or bring something new to the table, I believe that it also goes a long way to seeing if they will fit into the team.
In our interviews when asking people to whiteboard code we deliberately avoid specifying the language rather preferring them to write psuedo code instead, as generally their qualifications what you need to know there, we approach it as syntax is easy - concepts are hard.
Personally I feel it is not. Many good programmers fall short under that type of pressure. This is particularly damaging because about any programmer I know makes small mistakes during code writing that tend to add to stress of the moment if under the pressure of an interview. They will not relax and the problem will amount. You are also forcing the candidate to write code outside their traditional element (that of a code editor and compiler). This does have an effect on the ability to reason about the code one is writing.
That said, a whiteboard can be a good tool, not so much to write a solution, but to inspect an existing (bad) solution and suggest a correction. Or to observe code and comment on it. There's less stress under this situation and you may get a more approximate idea of the candidate real value.
If however you do insist in having the candidate write code outside his natural element, do try to stick to theory and avoid delving into the language proper. A whiteboard can be a lot more efficient tool if the candidate uses it to write pseudo code, for instance. Also, leave the room. Let the candidate alone. This will ease the tension.
Using a whiteboard in an interview can be very effective, but whiteboarding code is not a necessarily a great idea. Whiteboards are not a normal environment for programmers to write code, so there is an element of awkwardness that is added to the general discomfort that an interview brings.
Using the whiteboard as a vehicle to discuss design, whether it be of systems in the candidate's past or of systems that result from tricky questions that you pose, is a great way to loosen up the conversation and understand, still in the constrained interview context, how the candidate can communicate ideas both verbally and visually. Because of the higher-level of these conversations, I would generally reserve the whiteboard for senior programmer candidates.
We have all seen the guy that talks a good game, starts the job and then leaves after a week because he really couldn’t do it.
Most programming technologies have a well worn path. We are an ASP.Net, C# and SQL Server shop, so I ask them to walk you thru getting data from a table and displaying it on a web page will tell you a lot. Even for senior developer positions this will end in a candidate with a glowing resume hemming and hawing for 10 minutes before they end by saying “I’m not sure how to do that”.
The other thing to look out for during a phone technical interview - you will ask a simple question (i.e. how do you get the current date in SQL Server), you will get a pause of 30 seconds and then they will read you the answer they just Googled. We had to change our questions to make them no so Googleable.
So if I were going to make them code, I would make it a very, very simple task. Something like, create a table, put your name in the table and then build enough code to display it on a web page. You would be surprised at the number of candidates that will fail this.
Finally, it's not unreasonable to ask to see some of their work.