I'll admit this mostly comes from frustration standing by a whiteboard. If I did the same thing on a computer, I'd maybe just have a different set of frustrations.
As someone who does a lot of TDD, I is quite frustrating that a whiteboard can't run tests though...
What I have seen work well, from both sides, is interviewing by pair programming. Not for everyone, for sure.
Just write the test cases as bullet points and actually run through the algorithm with them when done coding. Don't declare success the instant you wirte that last curly.
Doing that gets a big plus from me (I'm 100% tdd personally).
Remember I know the answer to the question. The instant I can tell you do and for reasoning is good, I'm going to stop waisting time getting fro 95% sure to 100% sure on that part of the question and get another piece of data.
Usually that for me is to add some system design, speed consideration or other area of investigation and try to get another overall compentency covered. And just keep doing that till we run out of time.
It's very often other interviewers aren't able to hit things so backup signals are great.
And interviews are risk mitigation really. The more 80% certainties I can get on the more areas of coverage the Better if the interview team is doing a good job.
As someone who does a lot of TDD, I is quite frustrating that a whiteboard can't run tests though...
What I have seen work well, from both sides, is interviewing by pair programming. Not for everyone, for sure.