Yeah without meaning to I think the author wrote the most effective condemnation of white-board-coding interviews I've ever seen. And for whatever it is worth,

Yeah without meaning to I think the author wrote the most effective condemnation of white-board-coding interviews I've ever seen. And for whatever it is worth, I've been hacking code since 6510 assembler on the C64 and I'm (still) enamored with recursion as a concept but would virtually always avoid using it both in real code and as an interview answer (unless requested) because it is firmly in the bucket of programming concepts that are Cool and sometimes (though VERY rarely) The Right Thing, but are usually just unnecessary abstract complexity when trying to reason about a system during debug/maintenance. Of course, this is something you have to internalize after being bitten by doing the Cool thing multiple times in the past, which is likely why the interviewer is seeing people with more real world experience avoiding the overly clever solution. Counting this against them is insanity. And, yeah, the whole interviewing developers thing is a complete mess from start to finish, with dozens and dozens of different "best-practice" systems, none of which even come close to approximating actual work conditions (and all fraught with deficiencies allowing for all sorts of false positive and false negative results). I don't think there's a single job I've eventually left due to unhappiness where I didn't stay quite a bit longer than I should have just because dealing with interviews is such a terrible chore, almost completely divorced from the work it is supposed to test proficiency for.