[akbiggs]

At least in my experience, the main point of coding interviews has always been to expose and analyze the way that you approach and solve problems, not to see how fast you write code. It's usually better to take a step back and re-evaluate the design of your solution rather than dive into the first solution you create, since you'll usually find a better way to express the solution that is short enough to write down on the whiteboard without pressing against the time constraints.

It's also important to see how reliant people are on their tools.

[thoughtsimple]

Why shouldn't a programmer be reliant on their tools? What a bizarre idea.

I like to measure a carpenter's skill based on whether they can build a nice looking bookshelf with just a pocket knife said no one ever.

[sangnoir]

I don't think the whiteboard interviews expect an executable at the end of the process. It's not a complete test, but a partial one: testing if you can come up with suitable algorithms within a reasonable time - and perhaps how you work/your process. None of which is dependent on any (software/IDE) tools

[vertex-four]

If you're asking them to design something rather than build something off a pre-existing design, you might like to know that they actually understand the principles of design, and aren't relying on a tool to pretend they do.

[superuser2]

It is completely reasonable to rely on a text editor and the language interpreter. Hell, even the language documentation.

This could be an issue with really fancy IDE features, but there's a world of difference between a whiteboard and an IDE - namely, a text editor and an interpreter/compiler.