I have sat on interviews and noticed a big disparity between individuals of similar competency at answering questions on a whiteboard during an interview. Generally being able to clearly explain your thinking, writing readable code with the dry eraser pen, avoiding long moments of silence tended to result in more favorable reviews of the candidate even though in the end the answers were about equally correct.
I don't remember the last time I worked as an individual when developing software. I always had to coordinate my activities with others, discuss my design and implementation decisions, and work with others to construct software. Demonstrating communication skills in an interview is a huge plus. Interviews can make you nervous, but so can looming deadlines and the pressure of the job.
I would also reiterate my comment. Given the team-oriented nature of software engineering, you have to consider more than technical competence. The ability to speak and write, especially technically, is important for most positions. I would assess the competence of someone on all of the factors relevant to the job, not just their ability to build software.
What are some ways that one can get better at whiteboard interview questions?
Are there ways to be better prepared?
I can think of two reasons why someone might have poor responses to whiteboard questions: they don't have a good grasp of the technical information or they are a poor speaker/presenter. Of course, it could always be both of these.
The way to get better depends on the problem. Technical improvement comes by reading, doing, and asking questions (usually in that order). Poor presentation skills comes through practice, although some people are just naturally good speakers, while others aren't. I think that anyone can develop the communication skills, but personality will play a huge role in how good someone actually is.
Tips for how to proceed during the interview?
More detail is always good, even to the point of total "brain dump" to the interviewer. If I wasn't giving enough information, I've had interviewers ask me to explain something in more detail, and they typically asked explicit, to-the-point questions about my design or code.
Spending a couple of minutes thinking through the problem before hand, without saying or doing anything is always a good idea. You can use this time to also ask questions to clarify what the interviewer is looking for. This will not only give you the opportunity to give the interviewer exactly what they are looking for, but also show that you can think your way through multiple possibilities.