Don't treat programming as performance art. Some are great performers, but many are not. Don't force them to do something that's unnatural like code on a whiteboard. A whiteboard is not an interactive medium. A computer is. It's OK to riff on a computer the way you do on guitar. I know few that get it right the first time. Everybody thinks its all orchestration but Joe Beda points out the improvisation going back at least five years. He wasn't the first and likely won't be the last.
You may see Donald Knuth once in a career. It's rare. Don't expect it from everyone.
As an interviewee I use badly copied FAANG style as a red flag. Most will cargo cult interview styles copying what they've seen without thinking much about it. I've seen people memorize and pass interviews because Gayle Laakman McDowell's book was so overused. Do we really believe memorizing the book is better than not testing everyone exactly the same? I don't.
As a person who's sat on both sides of the table, I'm a huge believer in technical conversations, but I believe that's very different than code. To me, programming is not a performance art.
I recommend a few things:
1. Ask for sample code, preferably with git history showing that the author did most of the work or it was pairs or something like that. Ask lots of code review questions: why, how, alternatives, etc. Public github repos are fine. Private git repos are fine too. It's the history that tells the story both in terms of code frequency, velocity, revisions, tests, style, etc.
2. Use a pull request style in which the interviewee is the reviewer: what's wrong with this code? How should it improve? Is it good enough for MVP? What about production? Good opportunity to test whether they can speak truth to power when you show them rubbish that is patently wrong. I always hated reviewing bosses code when I had to march into their office and tell them they needed to fix their broken class inheritance or whatever. Interview is a good time to test for assertiveness.
3. Use pairs style where the interviewer is the keyboard/mouse driver and the interviewee is the navigator/commenter keeping the driver on track.
4. Ask them to bring their own hw/sw stack. Examine the choices and reach your own conclusions asking questions about why/how they arrive at their stack when no one is guiding the choices but them or their influencers. They don't really need to do much, more than a show/tell, explaining choices and why/how. To me, this is really interesting philosophically, particularly if it gets into stuff like *nix that are not the typical ubuntu, fedora, etc. and go off into arch derivatives or left field in a telling, R&D way such as shell, package managers, tmux, language, lint, tests, and so on.
Hope this helps.