The best whiteboard experience I have ever had was at my current employer. The key difference was targeted questions with specific answers based upon code.

In this case there were 3 code scenarios written to the whiteboard. The interviewer asked questions expecting a definite specific answer based upon the provided code samples. This did only a few things: forced me to read the code, forced me to carefully consider the question, and finally answer the question. They went through about 30 questions like this and treated like a casual conversation. Things were not rushed.

What this did not do:

* They did not ask me to brainstorm anything until the end as a bonus round once my nerves were down and my confidence was high. Normally, as in normal development where there isn't performance pressure, it takes a few minutes to think through an ideal solution to a given problem and then execute on it. If an interviewer expects equivalent performance with a gun to somebody's head be prepared for disappointment from multiple perspectives. I say this even though I am one of those few people who perform better under pressure.

* They did not ask me to write a bunch of code on the whiteboard before. I have been through this before and the results are mixed. On one hand the interview is pleased that I can answer a given question immediately and under pressure without delay and that the answer appears correct. On the other hand they are sorely disappointed in that my answer does not reflect their favorite code style or require use of their favorite tools. This is stupid nonsense. If that pettiness really is that important for the interviewer then address it after candidate selection. Otherwise the interview is simply wasting everybody's time including their own. Simply: If they didn't want the answer then why did they bother asking the question in the first place?

* They didn't ask me random code trivia. I have seen some code interviewers go off on tangents about irrelevant factoids and edge cases that don't matter to the performance of anybody. Instead this employer focused their attention on whether I understood how the code in question works and things like scope, order of precedence, and common code behaviors. Clearly the goal was to separate those who could code from those who could not. If additional filtering is required then they could solve for it with an additional interview.

--

As far as being the candidate and participating in whiteboard interviews my only advice is this: Answer the question as directly as possible and be done. Do not be fancy or clever. If they want to circle-jerk you with nonsense and continuous edge cases to see how you perform under pressure just repeat the advice. Answer each question as directly as possible with the least effort possible and be done.

The goal here is to use this as an opportunity to evaluate the interviewer. This is primarily why you want to spend as little time and effort on the whiteboard as possible. Instead read the interviewer. Determine if they are randomly all over the place. Are their evaluations of you simply pass/fail or are they full of subjective stupidity. When they do come back with subjective stupidity ask them very pointed questions about their decision making. An interview can go both ways and if they don't have their stuff together you may not want to work there.