"You need to be able to write a BFS cold, and you need to understand how a hash table is implemented."
Great advice! The list provided in this blog post is an excellent description of what you should know, cold, before you go into an interview. The reason you need to know them "cold" is that you (probably) won't be simply asked to code up mergesort. Instead, you'll be presented with a problem that can be reduced to mergesort. You need to know it cold so that you can reason more abstractly with it.
While this is great advice, it also demonstrates why people eventually develop interview fatigue over a career. I'm not talking about fatigue from your third interview this week, I mean, I mean fatigue that sets in over decades.
See, a year ago, just before I interviewed at google, I could have done all this "cold". I could code up a BFS, mergesort, find the shortest path between two nodes, print all permutations of a set, and so forth. Cold. And you know, I think in many knowledge-intensive fields, most practitioners are required to do stuff like this cold. But I probably wouldn't be able to do it all cold now. I could figure it out, but not in 45 minutes at a whiteboard, and certainly not in time to reason abstractly. I wouldn't be able to do this with partial differential equations or shakespeare's plays, two other subjects I was highly prepared for exams in a couple of decades ago.
See, people in other professions have to do this, but they do it once. Actuaries need to know vector calc and linear algebra, cold, to take their exams. But they don't have to remember how to integrate by parts when they are interviewing for a Sr Actuary position 15 year later. Physicians need to know Organic Chemistry, cold, at some point in their lives. But an experienced anesthesiologist isn't expected to answer whiteboard questions about undergraduate oChem.
I don't have an easy solution, since I actually do completely understand why tech employers rely on these exams. But I do think they take a serious toll on the field, and are a major contributing factor to attrition (as well as aversion among people who never go into the field at all). We, as developers, really do have to re-load complicated undergraduate coursework into exam ready memory over, and over, and over.
I'll finish the way I always do: if you interview like this, that is your choice, and you should feel free do do so - I really mean this. But why then do these employers act mystified that there is a "shortage" of developers? It seems to me that aversion and/or attrition is a very natural outcome for the way we do things in software. "No thanks, I'll do something else" seems like a very reasonable response to an industry that hires like this.