In my first interview they put me in a room with a PC with Borland C and a copy of K&R and a sheet with a simple problem to solve and some extra enhancements if I had time. They said they would be back in half an hour and left me to it. That I passed fine.

Some twenty-ish years later I was asked to write a C function to reverse a string on a white board and I failed because I'd misformatted the for loop. I don't think it was because I've become a worse C coder in the intervening years.

When I'm actually coding I'm sat with my editor configured Just So with completion, compilation and unit tests at my finger tips. My favourite coding music blasting my speakers and a handy browser window for looking up anything in unsure of. This is my most productive setting and expecting the same performance in a stressful interview setting is foolish in my opinion.

Working through problems on a white board can work well but you are looking for the problem solving approach, not an encyclopedic knowledge of regex syntax. Those same problems get immeasurably harder when explained over a phone call.

My personal preference when evaluating candidates ability to code is reading their actual production code, the break down of commits, the commit messages and the sort of unit tests they add with a feature. The interview is more focused on their soft skills, what about the work excites them and what they are looking to get out of the role.