I only skimmed the parent article, but I tend to agree with you. I would add that a lot of the job entails quickly learning new things and solving new problems

I only skimmed the parent article, but I tend to agree with you. I would add that a lot of the job entails quickly learning new things and solving new problems. For example, just yesterday I had to work with RavenDB, which I've never seen before. The complaint that you shouldn't need to know how to, say, write a BFS because you never have to do that IRL has only surface validity when you consider that much of your job amounts to doing things you've never done IRL. In other words, if you can't (re) learn certain CS fundamentals in preparation for an interview, perhaps you'll have trouble on the job as well. This isn't to let interviewers off the hook, however. Standard whiteboard problems like "reverse a linked list" are still suboptimal, IMHO, and even with these, there are better and worse ways to handle them. Do you focus on the interviewees reasoning and use the problem as a basis for deeper discussion or simply focus on their end result? Do you treat Sr & Jr interviewees the same? Do you seek out curiosity and ability to learn or a specific knowledge set. IMHO, if the latter, you're probably doing it wrong.