&quot;Programming trivia&quot; style interviews are the bane of our profession. They serve primarily to allow the people doing the interview to feel clever and superior when they discover that the candidate can&#x27;t implement a red-black tree from memory on a whiteboard. They tell you little about whether the person is a good candidate.<p>There is a school of thought, baffling to me, that suggests that knowledge is mere rote memorization of facts, so the best way to test people in anything is to check their memorization of the relevant material. This interviewing style derives from that school of thought.<p>This is, of course, utter bullshit, especially given that the details of the topics chosen are almost entirely irrelevant to the actual job of a software engineer. A working programmer who re-implements a red-black tree from scratch is almost always doing it wrong. Someone has already built that and debugged it and optimized it, and you should be using that implementation, not redoing it from scratch yourself. The &quot;programming trivia&quot; interview style is like interviewing an architect by handing them some iron ore and asking them to smelt high grade steel out of it. That&#x27;s not what architects do. They buy premade steel smelted by experts, then use it to build other things.<p>The solution? Real-world programming as an interview. Either give them a toy problem, or pay them to do some minor bit of actual work on your system for a day or two, if that is feasible. Then get out of their way. Give them a laptop and the Internet, leave them alone for a few hours, and see what they can do.<p>Afterwards, do a code review. Then discuss their programming and engineering philosophy.<p>Why don&#x27;t people do this? It takes a lot longer, and requires the interviewer to think more. It&#x27;s much less cognitive load for the interviewer to memorize some obscure data structures and ask candidates to recite their construction.