Well if that is what they expect, then they should make it clear. Something like don't say you are finished till you have verified your solution. They didn't.

"If an engineer misses details and won't spend time looking for a more optimal solution on a white board, I wouldn't expect them to do it in the day-to-day work of their career either."

What a foolish generalization. This is exactly the kind of attitude that I don't like. Just because someone starts with a sub-optimal solution doesn't mean he can't/won't improve it. Also my approach was to start with a sub-optimal solution so that we have a foundation to build on, which I think is much better then spending your entire interviewing time thinking up a dynamic programming algorithm and leave a blank board at the end.

Optimizing a solution is an art, and can take varying amount of time, and sometimes even your sub-optimal solution might be better than a more complicated optimal solution.

Let me ask you this? How much time did you spend coding the sub-optimal solution?

For many of the questions I use during the interview process, I have a pretty good calibration level regarding how long it should take someone to answer a question. If the last couple of times I've used the question, the candidates were able to come up with an answer in 5 minutes, and then another candidate spends 10 minutes writing down an O(n3) solution, and then tries to come up with an more optimal solution, it might be understandable why I might give that last candidate a somewhat lower score.

One thing that can help is to also keep talking so the interviewer knows what you are thinking. That way if you outline an O(n2) solution very quickly, and then say, I think I can get a O(n log n) solution this other way, then you're showing your work, and it's a lot easier to get partial credit on a question.

In general it's better to explain the approach you want to take before you start coding. If an interviewer knows that you're going off in the weeds, perhaps because you misunderstood the problem, that will be an opportunity for the interviewer to clarify the problem, and perhaps give you a hint to steer you in the right direction. (Remember, most of the time the interviewer has used this question multiple times in the past, so s/he know where people are likely to get stuck, and very likely has hints prepared if people stumble --- and one or two stumbles does not a No Hire make; the goal is to see how someone codes and how they think, you don't get a 0 or 1 grade.)

It's tragic that engineering interviewers extrapolate a candidate's mistakes on a whiteboard during a tense, time pressured interview situation to the calm day coding at a keyboard during a real day at work. It's almost as if we forget what it's like to be an interview candidate when we're the interviewer.

Tragic? What's the alternative? Should we ignore mistakes made at the whiteboard because someone was under time pressure?

Sure, most software engineers (aye, even Google software engineers) are not under significant pressure on an average day. We get to work in the morning, we sit down at our desks, we hack on our code with our 30" monitors and customized editors, and we go home. It's a nice job, really.

But there are occasions when engineers are under pressure. There are deadlines. There are revenue-impacting bugs that need to be fixed while millions of dollars are at stake. There are segfaults in some new code you just deployed and the SRE team that's getting paged at 3am is threatening to burn your house down if you don't fix it before the weekend. Time pressure is not utterly foreign to a software engineer's life, and it's not unreasonable to do what we can to see how an engineer will function under such pressure. An engineer who can only properly function sitting at a desk with his 30" monitor filled with vim instances and ample time on his clock is lacking some measure of flexibility and capability that we reasonably expect to find in the best engineers.

No, we don't forget what it's like to be an interview candidate. You're just forgetting what the point of our interviewing is.