Doesn't this just show that the ability to write code in an interview situation is a poor predictor of future performance?
If people who have actually produced vital code aren't passing your interview test, your interview test is poorly conceived.
The whiteboard test may be unfair to those who melt under interview pressure, but if the greatest danger is false positives for the "can they code?" test---if it's a startup where the price of one bad hire is very possibly if not likely the failure of the entire venture---it's the best test we've got.
Note that the test doesn't have to be "tricky" or anything like that, e.g. a simple "reverse a doubly linked list" will weed out a surprising number of candidates. My three basic tests, back when C/C++ were the only choices to use, were that one (tests groking pointers), do a recursive factorial (any language will do for that), and "find the errors in this block of code".
Mistakes in doing any of the above are perfectly fine, what you're looking for first and foremost is "do they have a clue?"
Or use another higher level test from one of the best managers I ever had: if you have any doubt about the candidate, don't hire them. And if you doubt they can really code....