A good whiteboard interviewer will be those things for you. And language details are less important -- "well, let's both agree a for loop has this syntax for now"
I'm not talking about loop syntax or stdlib argument order. I'll google around for algorithms or concepts or data structures too. I'll bring up the docs and study them to figure out what data structures I've got so as to do the least amount of work. Do you want to test the things I've already learned, or how quickly and neatly I can actually get things done?
And it's far too easy to start going down a long and winding dead end path when you can't incrementally run an algorithm. I've had a couple whiteboard interviews where I get the sense that I've gotten something wrong early on that's causing me trouble, and while stopping and pondering on it doesn't immediately reveal a problem (and oh shit, I've only got 10 minutes left in the interview, gah, well, guess I'll just keep trucking), running it once to see the output could easily do so.
It's nothing like real-life coding, is my point.
Also:
> A good whiteboard interviewer will be those things for you.
I applied for a job posting at Khan Academy and ran into exactly this kind of interview.
It shows absolutely nothing about me other than I am not a good test taker, and without incrementally debugging my programs I am a fairly worthless programmer.
I dont see how putting someone on the spot like that really extracts any knowledge about the type of person they are.
All of my peers describe me as 'the best programmer they know' yet every programming interview I've ever gone to in this style doesn't work out for me. Frustrating.
Yes. A good whiteboard interviewer should constantly stipulate things that seem intuitively right, and let you use obvious helper functions that should exist in your environment, without penalizing you for getting the _name_ wrong. I.E. if we're talking java, you should be allowed to use anything that "feels" like it should be in java.util, without having to name it correctly. Because that part can be quickly googled for.
Sometimes interviewers even let me just define the signatures of helper functions whose behaviors are tedious to write out, but in words we can cleanly go over the expected behavior. I have a habit of writing "pre" and "post" documentation for functions that specify finer grained types than the porous Java type system; chalk this up to my love of OCaml, but it greatly pacifies interviewers who know that I am mentally type checking, and will let those helper functions go unimplemented.
Whiteboard interviews have another fundamental flaw. Introverted people (typical for programmers) tend to perform terribly when they're watched and being evaluated. Even when you're provided with Google, docs and REPL the most important tools may still be missing: your mind and your ability to focus. Whiteboarding sessions are useful for many things, but coding is not one of them.
