I'll address your second paragraph before returning to your first question- I think my answer will be a little more cohesive that way.
The fundamental problem with whiteboard / live coding technical interviews is that you're selecting for candidates whose strengths aren't necessarily useful on the job.
They:
- have memorized answers to solved problems
- work well under immediate pressure
- demonstrate knowledge of basic programming techniques
They do not:
- demonstrate collaboration
- demonstrate researching and gathering requirements (i.e. no access to the internet)
- demonstrate planning or reasoning about business requirements
In short, yes, they're solving problems, but they're not solving the same kinds of problems that you'll need them to solve on the job, nor are they solving them in the same way they'll be solving them on the job.
These interviews select based on superficial qualities, and practically ignore the qualities of top candidates (teamwork skills, interpreting technical requirements from business requirements etc.)
I had typed out a lengthy explanation of the process I'm currently using, but I realized I don't want to go too deeply into the weeds. In short, design a small challenge application for candidates to build, with the expectation that it'd take no more than a handful of hours, and let them turn it in on their own time (say, within a week). If they "pass", bring them in for a second, technical interview, which is a conversation based on what they submitted (i.e. how could they do X better, how would they add new feature Y, etc.)
The benefit of that kind of process are numerous:
1- The time commitment of candidates is the same as a long whiteboard interview (or set of them), and they don't need to commit to all of the time at once (takes less time away from their current engagements)
2- The time commitment of employees is reduced to ~2-3 hours (one to evaluate, one to interview)
3- candidates are building a small application, meaning there's not an objective answer to be found on stack overflow to memorize
4- candidates have time to ask questions and demonstrate skills they are passionate about, but might not have been specifically requested- say, testing, user experience, flexible architecture to support future features, that sort of thing
5- The second interview becomes a relaxed conversation, where a broader selection of engineers perform well, as opposed to the more biased high-pressure scenarios that aren't typical of our day-to-day
To do this well, of course, you ought to review the challenge and process each year, and have (preferably junior) employees test it to ensure that it will be respectful of candidate's time commitments and the value of the information the challenge will provide an evaluator. Given that you want to keep it limited to a few hours, you'll need to balance features that you think will be interesting with features that actually yield interesting information about the candidate for a second interview- anything that can be learned by simply asking a question doesn't actually need to be included.
Finally, to return to the original topic of this thread, you potentially eliminate certain cultural biases that are irrelevant; not only is the candidate demonstrating capabilities more reflective of the job itself, but they are doing so before ever meeting in person.