All your points are good--and they are part of the overall problem with whiteboard coding: A whiteboard is not even close to a realistic modern development environment.

How many times, for your job, have you had to code up a solution to a problem, even a trivial one:

1. Just given to you 5 seconds ago

2. With no access to documentation (paper, textbooks, offline or online resources)

3. With no access to mentors or colleagues

4. With an editor crippled as you described

5. Have to get it right within minutes?

6. And then have to defend your code against someone who's had plenty of time to think about the problem.

I can tell you, throughout my programming career, the answer is "never".

This, to me, is the most important point. We make such a big deal about making sure our tests actually test the thing we care about; why aren't we doing the same thing with our interviewing processes?

I absolutely agree that whiteboarding is a skill that requires practice. That said, with a reasonable interviewer, the first couple things you're discussing really don't matter. The trick is to understand that no one cares if you're actually writing working code, and that the important thing is communicating your intentions and process.

> There is no insert.

This really isn't a problem. If you need to insert a line, in most cases you can just draw an arrow and then describe what you forgot to do there. Code may not even be necessary. Anyway, an arrow is fine.

> There is no context driven autocomplete or quick method lookup

Again, not really a problem. Just say "I forget the method name here, I'm just going to assume it's called 'append'" (or some other appropriate name). No reasonable interviewer cares in the slightest as long as it's clear you know what you're doing and it makes sense.

> If you code iteratively the whiteboard is not your friend.

This is absolutely an issue. Everyone codes iteratively though. Successful whiteboarders learn to do the iterative part of coding verbally instead of in code. You talk through the algorithm you're going to implement, and refine your plan in words, and then only when you've got a solution you're happy with do you pick up the marker. As a side benefit, this demonstrates your thought process much better than coding would. Actually, this is just a better flow even for development on your own computer. Once you develop the skill, you'll find that a little more planning time before you touch the keyboard almost always leads to faster implementation overall.

> The trick is to understand that no one cares if you're actually writing working code, and that the important thing is communicating your intentions and process.

This is absolutely not true. I've interviewed at many major companies (Google, Apple, Snapchat, etc.) and they all say at the beginning "Make sure you have working code". They don't necessarily care about syntax errors or spelling errors, but they absolutely want working code.

> They don't necessarily care about syntax errors or spelling errors, but they absolutely want working code.

I'm not sure how code with "syntax or spelling errors" qualifies as "working code." The fact that they don't care about those things is pretty much the exact thing I was trying to communicate.

Other things they probably don't care about: unimplemented placeholder functions (they might ask you to go back and fill those in if they thing it would be informative and there's time), or misremembered function/method names (though it's important to communicate that you know you don't remember).

I mean, obviously they do want code that demonstrates a well thought out solution to the problem. But no one expects that you could just copy it into a text file compile it, and have it run - that's what I meant when I said no one cares if you're writing working code.

I am assuming that you can use pseudocode

Exactly! The above comment assumes that a linter will be run against the core on the white board. Jeez.