When I interview candidates, I definitely use live coding tests as well as whiteboard tests. However, I probably look for different things than most.
With the live coding test, I put them in front of some tools that they've told me they're very good with. I give them some trivial coding test from the perspective of a business user with vague/conflicting requirements. I don't really care about the code they write (face it, it's probably crap as would be anything I'd do right in front of them rushed and under that kind of pressure). But what I want to take away from it is an answer to these questions:
1) Are they really able to use the tool as they said or do they stumble around in it because they've only kinda used it? (This gives me an indication of whether they're misrepresenting themselves or not, as well as how much I can trust their self-assessment of skills.)
2) When I give them intentionally-conflicting requirements, do they push back and demand more info where it's necessary or do they fall into obvious pitfalls that a simple question could avoid? (There is a right and wrong here for some teams, but other teams can easily manage either of these people with the proper support system.)
3) Are they able to fill in the blanks with common sense assumptions when flushing out what business requirements mean? (There isn't a "right" or "wrong" result here, it's more for gauging their ability to quickly analyze things with critical thinking skills while under pressure. This is something some people are great at and something some people aren't so great at even though they're great developers. It simply depends on what the role is for and if they'll be somebody dealing with structured process or putting out live fires.)
For the whiteboard portion, I usually give them a problem that I don't necessarily expect them to whip up a solution to. That's fine but it's also fine if it's a collaborative process (with me). What I'm looking for are answers to these questions:
1) Can they communicate well enough to explain their thought process? I don't need a wiz who can whip out an answer to all technical problems. I need a teammate who can work through a problem and get to a solution.
2) Can they communicate well enough not to just communicate but to also educate? I often ask them to elaborate on "why" not to challenge them but to educate me. I ask things like, "Pretend I'm a new developer learning ABC. Can you explain to me why XYZ?" For some positions, I like to know if the person may be able to mentor others on the team and this is where I can get a good indication of that.
3) Alternatively, are they somebody who would prefer to work through the problem themselves without leaning on others? This is okay, too. I definitely want to know this before hiring, though. Some positions this is preferable for and some positions the collaboration is preferable for. Both have their strengths and weaknesses (even on the same team)!
The point is, I'm not looking for "the right code" or "the right solution" when I put these tests here. The test isn't the end result. The test is the journey. And that journey tells you more than you could ever deduce from a code analysis of a fabricated problem solved with insufficient input.
BTW: Google, StackOverflow, and even texting friends is allowed during these parts of the interview. I actually encourage them to go ahead and look things up online or find snippets to use if they're struggling with anything that they think they could find online. There's value in seeing how they can use resources to solve already-solved problems rather than hammering through everything.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.