Sorry, this is too black-and-white. Of course it's stupid to ask somebody to write down red-black-tree rebalancing algorithms from memory. Especially on the wh

Sorry, this is too black-and-white. Of course it's stupid to ask somebody to write down red-black-tree rebalancing algorithms from memory. Especially on the whiteboard without any syntax/compiler help. But given a more-or-less concrete basic problem that every programmer should be able to solve with just basic knowledge of the chosen language hands-on (at a computer, not the whiteboard) is a different thing. It can be a collaborative process where the candidate can sketch an approach on paper/whiteboard, then write code. While doing that they can query API question to the interviewer, which, if they are doing a good job, will be giving that information willingly. Watching the candidate building their solution towards something that works tells a lot. It's not just whether the code works. It's communication too. Code organization. How they think, how they approach a problem, what to do when they get stuck (ask for help? run in circles? just get confused?), what do do when their code has a bug etc. Take-home exercises seem to be praised as the key solution, but I think that's fundamentally flawed as already discussed here. If done badly, it's just as bad as from-memory-whiteboard stuff. In-person-problem-solving can be done quite well. And the market proves that it works. Successful companies do it. If their hiring would suffer substantially, then they'd have stopped doing it, because their competition would have a substantial edge.