Well doing it on a white board in the same room as the interviewer allows you to see how some one approaches a problem - which is more important than the quondam task of coding.
> allows you to see how some one approaches a problem
I've never jumped to a whiteboard. Rather, I've researched the problem. If they really wanted to see how you'd approach a problem, they'd give you the problem before the interview, and then when you come in, ask you to explain it, allowing you to use the whiteboard.
I've also never had to reverse a BST in place outside of an interview setting.
I personally like technical questions in interviews. I've had some good experiences with them, but that may be because I have always been a good "test-taker". I feel like I understand what tests (and interviewers) are looking for and can tailor my response accordingly.
For an interview, I've learned that the question isn't "come up with the best solution". The question is really "demonstrate how you approach this problem". I've learned to vocally explain that I'm starting with a naive approach. Then I explain how I'm considering the constraints for optimization. I state out loud any patterns or similarities between the optimizations I am trying to make and ones I've made in the past. (ie, "To make this O(logn), we need to find ways to eliminate half the data set each iteration. Is this similar to a BST at all?"). I pursue paths I know might not be correct, and backtrack when I see the fault in the idea. The key is to narrate for the interviewer.
Maybe I've had good interviewers, but 7 of the last 8 interviews I've had resulted in job or internship offers and I felt the interviewer was able to get an accurate picture of my abilities.
No matter how much interviewers say they are just looking for solutioning, they are not being honest with themselves because when they see code that is not their style or they see someone make stupid mistakes (which we all do) on the whiteboard, it embeds in the mind. It such an overpowering signal that it outweighs all other evidence. An INT already knows this and would therefore prefer to present finished code, not how you get there, which finished code is all that really matters, you can walk them through how they arrived at the finished code, and they will have a far more competent answer because they are not trying to code and drag people along with them at the same time.
Even if a developer makes 20 mistakes, and uses the compiler/debugger to catch them, then fixes them, if the code that they are going to check in is always clean, is his process bad? on the whiteboard it is, but for me personally if said hypothetical coder never checked in a mistake, he would be my top pick. There are just too many failure points for me to recommend the whiteboard. I believe that they provide no use in an interview and I believe they hurt companies more that employees.
Organizations that utilize the whiteboard are doing themselves a disservice because they are setting introverted people up in a situation where a portion of them are naturally going to fail, in a situation that send such a strong false signal that all other evidence is negated. Then some of them are complaining that they cannot find talent. If a company is whiteboarding then they are filtering INTJ's out no two ways about it. As such, they are filtering out a lot of people that combine technical skills with creativity.
Although the whiteboard is good for some purposes, the author specifically mentions "brainfuck" coding questions.
Having them do those on the whiteboard really only tests how the think on their feet in high pressure situations... Something not really required of 99% of coders.
White-boarding in a high pressure situation is simply a different "skill"... I think it's fair to say that most coders are "internal" thinkers / introverts, that do their best work when they have a chance to quietly think about a problem.
On the whiteboard, you're asking them to do the exact opposite.
Eliminating the "brainfuck" white-board questions doesn't mean you need to soften the interview. You can actually give a more substantial take-home problem to your final round of candidates.
But, I'm biased. I would never do a take home interview shrug
Though as my first job was at a RnD Organisation this was expected from everyone from the shop guys to the Boss (the then president of the mechanicals) I might have a higher expectaion than most :-)