Expecting perfection on a white-board test is setting everyone up for failure. At best that's a large napkin exercise. Though having a failure, or a point where for whatever reason production is a bottleneck (if they happen to do it without obvious faults) is an opportunity to identify that either thing is the case in that section and move forward with how they'd react; what should be changed, etc.

We're all still human; expect failure to happen. See what happens next.

100% agree. I interviewed at Microsoft nearly a decade ago now. I was told I'd be interviewing for the company, and then if I was hired, based on preference and ability and need I'd be placed with a team

When I got there I was told I'd be interviewing for the SQL Server team, interesting work, but not something I'm interested in. I had never taken operating systems in university because it was always available at a time that another class I HAD to take occurred.

So by some random chance, I'd never heard of a semaphore. Perhaps inexcusable at this point in my career, but I was ignorant of the topic at that time.

My first interview question was to write a way to let many readers on a resource, and only 1 writer, with no readers reading at the time of the writer writing. I decided to use lists of something or another, ProcessId, or something similar.

Every time I would go to write the code, i'd get a few characters in, and the interviewer would interrupt me and ask me questions to help me along. Since I had no idea what a semaphore was, much less that I was supposed to use it, we spent like 30 minutes of this back and forth, me trying to write, him interrupting me. By the end of the session I had a single line initializing a list written.

Some of my other interviews during that battery of interviews went better than that one for sure but, needless to say, I didn't get the job.