I hear you. I'm terrified by the kinds of interviews that want programming trivia. In the last three years I've never had to code a binary search tree. But I should be able to show you I'm very comfortable with Python.
Devil's advocate: Asking highly academic questions allows employers to be ageist without explicitly stating it, since college grads are likely to be the most familiar with them. This lets them select for younger candidates with less experience and thus drive down developer salary.
(Standard disclaimer: Some development positions actually require the academic knowledge mentioned. Most of the time, though, a good developer will use a well-tested library instead of rolling their own.
Why would they want or need to be ageist about it? If it's just about paying low salaries, surely all they need to do to accomplish that is offer low salaries?
(If anything my experience is that older developers have a stronger tendency towards implementing academically known datastructures themselves, whereas younger developers are more likely to make more use of libraries)
Python isn't the only capability you're typically being evaluated for, though. A binary search tree is a very simple thing. I think it's reasonable to expect a candidate to come up with a basic implementation of a binary search tree, especially if you are giving him/she hints when he/she gets stuck -- an interview should be a two-way conversation. If you can't come up with something approaching a binary search tree in an hour and with my help, how can I expect you to design a reasonably complex system when the business needs it?
Now if you are asked to come up with a red black tree without any help, now that is a different story. A red black tree's implementation details are hard to derive given a set of requirements. A binary search tree, not so much.
As an interviewer, I don't ask this question but if I did then you could impress me by asking what a binary search tree is, then I would tell you, then you explain or write how you would do it.
Most of these interview questions aren't designed to be trivia. It's designed because your job IS implementation of technical and business problems.
They might not be trivia, but they're not presented in the same manner as someone would be doing on the job and/or the candidate isn't given the same access to tools they normally have when working and/or there's an 'on the spot' requirement to answer the question.
I don't store everything in my head anymore. I have a general understanding of the concept and a mental pointer in the form of the search term to put in google to refresh how to implement the thing.
I have to implement 10-20 concepts across 5-10 languages or APIs or technologies every single day usually, my brain doesn't work like a database where every record that's inserted is there permanently until I update or delete it. The stuff I'm not using regularly gets fuzzier and fuzzier and goes back to "general concept mode" if I'm not actively using it.
So when someone asks me to write a full iOS app during an interview when I've been making Microsoft business apps for the past year, even though I've written and released multiple full iOS apps at previous jobs, I can't just sit down and produce a perfectly working app like a robot, especially if I didn't have much time to prepare for the interview (that recruiter contacted me three days earlier and didn't tell me he set up an interview until 8pm the night before).
With technical questions it's even worse, because I could have been spending days and days refreshing my knowledge but you happen to choose one of the things I didn't think to refresh my brain on. And so I waffle on the answer and you go "oooh, looks like he doesn't know anything". No, I've got a full decade of making apps and software, in lead roles, in multiple industries with a bunch of different technologies. I know plenty. I just didn't have that question fresh in my head.
Then you pass, and lose out on someone you would have benefited from greatly in favor of the recent grad student that hasn't made anything but toy programs yet got tested on all those concepts within the past six months so it's fresh in their heads.
That's usually not how it works though. You're more likely to be laughed out of the room for asking such a silly question, despite the fact the (presumably technical) interviewer could do no better without the teacher's copy in front of them.
An aside, but I think interviews like this should allow Internet connections. Give the candidate a minute to look something up and digest it in their own way. It should be obvious whether they'll get the concept or just recite the Wikipedia definition. Just as important is how they do their research, and how they draw connections between foreign and familiar concepts given a blueprint of the former.
"As an interviewer, I don't ask this question but if I did then you could impress me by asking what a binary search tree is, then I would tell you, then you explain or write how you would do it."
Maybe. Or you would scoff, turn your nose up, mutter "noob" under your breath, and move on, knowing you're not going to hire me.
I'm sure you yourself would do as you said, but I can't be so sure about random interviewer person.
(Standard disclaimer: Some development positions actually require the academic knowledge mentioned. Most of the time, though, a good developer will use a well-tested library instead of rolling their own.