It's not that they're irrelevant, it's that the problems can't be done in a disruptive environment with $100k on the line, by asking questions that must be memorized by chance first.
Well the idea is that they aren't memorized by chance first, they are known pretty well because ideally you have a track record of applying them to real life problems (even if they are just school projects or side projects). I can describe times I've used queues to solve various problems, for instance. The other thing is, as others have pointed out, seeing how someone breaks down and approaches and unfamiliar problem is very valuable.
It sucks that we have to do it under the pressure of a 45min-1hour conversation, and I totally get that the stakes are high and so nerves are a problem. In general I think the best way to handle this stuff is to give candidates multiple paths to succeed.
I think the nerves problem is slightly overstated though, because I do think many companies do give candidates multiple paths to succeed. For instance, if you have trouble performing well in an interview setting it's pretty crucial that you have a wide array of work on github proving you can code and that will give you an opportunity to have some complicated but familiar code that you can talk about in the interview. If someone comes in with this but is shy or gets frustrated or something, as an interviewer I'm really going to try and pull the magic I see in their github out of them in that interview. Keep in mind that people hiring engineers really want the candidate to succeed in most cases. It's so difficult to find good talent that while I'm never going to lower my standards to hurt the company, I'm definitely on the candidate's team in an interview, trying to get them to shine as best I can.
Very few people are working as comp scientists, but rather software engineers, making BFS=Queues a random trivia question that must be prepared for in advance.
BFS queues are not particularly difficult to describe, and deciding whether or not to do breadth or depth first is something I think about all the time. Frequently, for instance, in data access patterns, that decision can have a very big effect on performance. I can't agree that it's a random trivia question.
Edit: Ok, let me add some nuance here. I think we both probably agree that implementing a shortest path algo perfectly in an interview setting is beyond reasonable or useful. But I would expect an engineer to be able to have a discussion about it that shows me they understand the basic concepts and given google and a bit of time could relearn that. But without the complexity of shortest path I would not expect basic BFS to be outside of the scope of an interview. I guess that's just where I draw my lines.
Hmm, their difficulty is irrelevant. Your experience (like everyone's) is anecdotal and not representative of the immense fields of CS and SE that no one person can know all of, but could certainly look up.
If you are looking for a computer scientist, ask for one in the job req. No shame in that, it would save everyone time.
I added a sneaky edit (sorry!) that may address some of this, so I think we probably largely agree. I'm responding to a relatively specific claim, frequently heard by bootcampers and inexperienced engineers in web development, that foundational CS isn't useful, which my experience is somewhat representative of, though you are correct it's still anecdotal.
