I agree with the code test, the discussion and whiteboard I would say depends on the type of developer. The former member of my team that produced negative work did well with discussions and popular little whiteboard problems. Our normal policy has become to have applicants do a mini project that represents actual work that we are doing. So far it has worked flawlessly. This guy didn't have to do that because he was so experienced. He ended up creating over-complicated, very buggy code that took more time for us to review than it would have taken for someone else to write. And when we needed to make even minor changes to his code the fastest way to do it was to just delete it all and start from scratch, everything was so complicated and codependent.

He had an appearance of technical skill, was very well spoken, knew all the interview questions and answers, but had really bad judgment and somewhat poor logic when he had to come up with novel solutions. On the contrary, I taught myself and didn't have the CS background to do well in purely technical interviews. But I was given the practical challenge and crushed it. I knew what I needed to know for my job. Of course I had a lot to learn (and still do), but I was productive from the start, or so I have been told.

I guess there is nothing wrong with whiteboard tests, but I think a practical coding challenge where the applicant makes part of an application is much more valuable. You can see that they have basic coding ability, but also how they organize code and break down larger problems. Can they get the big picture right while making clean, maintainable code?