As someone who does a lot of interviewing at RethinkDB I agree that these numbers are in many ways bullshit. Firstly they're pretty clearly hyperbolic (I think

As someone who does a lot of interviewing at RethinkDB I agree that these numbers are in many ways bullshit. Firstly they're pretty clearly hyperbolic (I think we all knew that already). However I think they also tend to be the result of a short memory span. Whatever the actual numbers may be (we should keep track) they are bad enough that every once in a while you get a run of ~5 interviews that really make you scratch your head. Which is about the time that these posts get written. The linked list question is designed as a smoke test. Admittedly it's a piece of code that one can do loads of coding without ever having to write. But bear in mind that in an interview we're looking for some code indicative of one's ability in the space of an hour, code that you actually write for production takes weeks-months-years and we simply don't have that kind of time. Questions like this have a high signal to noise; they're just esoteric enough that few people actually have a full implementation committed to memory but simple enough that anyone who gets the concepts of pointers and recursion should know just what to do. When runs of bad candidates pop up we do indeed reinspect our process. One major improvement to the process is to ask people question their resume suggests they should be more comfortable with. Ask questions in the more esoteric languages they know, ask questions in the field they did their research on. Obviously this greatly increases the chance of correct answers, thus these type of questions have a smaller correlation between a correct answer and a good hire. But what these questions can really do well is convince you that when this person understands something, he really understands it; he gets it well enough that he can very quickly explain it to me. This is very good sign in a potential hire.