If you're writing code on a whiteboard in an interview, syntax, library calls, etc, should not at all be part of the evaluation process. You dodged a bullet on

If you're writing code on a whiteboard in an interview, syntax, library calls, etc, should not at all be part of the evaluation process. You dodged a bullet on that one. Being able to "get the recursive solution fast enough"? Depends a lot on the expectations, might or might not be an eliminating criterion. Definitely a problem e.g. for functional-heavy environments, where that style of reasoning is expected to be your bread and butter. In the general case, I've seen fairly senior developers crash and burn on basic programming interviews (be they on a whiteboard, on a laptop, or whatever other format) due to genuinely weak programming skills, so I don't agree with the assumption that some candidates are "above" these interviews. Also, a lot of seemingly pointless questions are good questions phrased wrong. E.g. I will never ask you to implement depth-first tree traversal on a whiteboard, but will ask to pretty print a directory structure, and make a note of whether a candidate notices this actually _is_ depth-first traversal dressed up as a practical day-to-day problem. Of course, just because the interview format is not fundamentally flawed doesn't mean that plenty of companies don't mess up implementing it in practice... Then again, your PSes suggest you don't want a reasoned discussion so much as you just needed to get that off your chest, which is fair enough.