you want me το believe that someone who "blows up" a linked list is a programmer? He may be able το serve other tasks but a programmer he/she is not.
Programming in my opinion is a reading comprehension skill, solving cute little technical problems won't build large scale maintainable solutions. Even though they are fun to throw around at interviews they don't prove much. :)
Isn't that the situation during a startup and some companies?
If someone is not able to use a linked list, how are you going to trust them think of/implement something new and harder?
And I never said mistakes are unacceptable.
Second, and more importantly, a coding exercise during an interview is long, long way from working in a startup, or working of pretty much any kind -- unless you've somehow managed to find a way to get paid for solving toy problems. I've done both, and both are hard, but in different ways. To use running analogies, working in a startup (in my experience) is a relay: you have a team, each of you is carrying your own respective bit of the endeavor, but the success or failure proposition is net across the team. In an interview, you're running a sprint, and all eyes are on you, and you alone. One feels completely different from the other, because it is.
Also, half the times (for a sample size of two) I've been asked to do a code exercise during an interview, the interviewer realized halfway through the exercise that he'd misrepresented the specifications of the widget I was supposed to make. The plural of "anecdote" may not be "data", but I've seen and heard, and can conceive of enough problems with the practice of interview coding exercises that I just can't trust them for anything more than exploring how a candidate approaches programming: the way they think.