From my perspective, a big part of the problem is that companies don't let you know they'll be doing something like this (a simple "the 1:00 section of the interview will involve giving you a task using some tech you're not familiar with"), so it's a surprise (interviews are already stressful in ways that real work pretty much never is, "surprises" are deeply unhelpful for evaluating candidates outside very rare and particular kinds of work), and then also often forget to provide extremely useful information like "we know this isn't a familiar language or environment for you—we specifically want to see how you work in something you're not familiar with, so don't stress out if you aren't close to a complete solution by the end, we don't really expect you to be."

So what would you like to be interviewed on? If it's not based on your CV/experience, general CS best practices, neither known nor unknown technologies, nor general problem-solving questions...

People ask all of these for good reasons. You can write literally anything on the CV, so people ask about your experience to check you're not lying (you'd be surprised how many people do lie and at least misrepresent). People ask coding challenges because they expect you to code (and we've all heard horror stories about like the head of IT security not actually knowing how computers work). They ask you general problem-solving questions to test your intelligence, mental models, and behavior under stress/adversity (again, you'd be surprised how many people just suck here, or worse, get insulting etc. ALSO - note that I'm not saying that all such questions are good, they're mostly bad, but with a little bit of thought and planning you can design a good question). People test for basic CS knowledge because it's important in almost all situations (would you hire a brain surgeon that didn't know what a spleen was?).

(Not discounting all the actually terrible interviewing practices, e.g. people asking impossible questions to feel good about how smart they are, etc.)

I don't think I've directly ruled out much in the way of interview questions on in my comments on this thread, I basically just think not telling people the sorts of questions to expect and in which sections of the day, and not making it very clear what you're evaluating and why you're asking the questions, is harmful and inhumane.

A simple "this part of the day will be algo questions, we do expect actual solutions for at least some of the questions, but we're happy to talk through your process with you as you solve them, and none will be more involved/complex/deep-lore than [a couple examples]" would go a long way. For one thing it'd let people just "nope" out of interviews they know they aren't prepped for ("well they should just know they can't do the job in the first place and not apply" that'd work if interview practices/questions and actual work-on-the-job—let alone what's asked for in job postings—mapped even somewhat closely to one another, across the industry, but they very much do not).

I don't think mystery-interviews and having no clue whatsoever what might be covered in the oft-featuring pop-quizzes probably does much for improving the quality of passing candidates, but it does waste a bunch of time (for everyone) and make the whole thing way more stressful.

[EDIT] tangentially related, I find it really weird that most every company says they want people who can learn new things and get shit done more than ones who just know lots of stuff, but act like if they provide enough information that a candidate might conceivably be able to even kind of study or prep for their interview process, that'll ruin it somehow. WTF? If the candidate is not capable of doing much with red-black trees in an off-the-cuff kind of situation because they're rusty or whatever, but then you tell them a week out that you'll be asking some questions about tree and graph structures more complex than simple binary trees, so they brush up over the weekend then ace the interview including some red-black tree stuff which they couldn't have done under those conditions a week earlier, isn't that precisely what you claimed you wanted in a candidate? How is that harmful?

I think I'd like something like this.

The company has a given technology stack and rather than asking for anything which would directly benefits the company asks you to do some task that might be similar to their tech stack, but instead for the public domain / some open source project.

Programming: We've picked 10 problem tickets from various open source projects that are similar to things that might happen at work, show us what you can do in an hour.

DevOps: There's a local charity that needs a small version of infrastructure similar to what we have in house. Here's some old hardware we're donating and the things we'd like to see on it.

etc.

Whenever I've worked with a new $TECH for an $IMPORTANT_PROJECT_WITH_A_DEADLINE the timeframe for getting up to speed with the new tech has been days, not minutes.

I was on a python/javascript team that transitioned to kotlin -- everything went well, better than I would have expected tbh given only 1 of us even had any production java experience, but 50 minutes would not have been enough time to figure out how to usefully set up the IDE, let alone build anything beyond FizzBuzz.

There's a big difference between spending 50 minutes fiddling with that stuff when you're employed and evaluating it as part of the research phase for a project vs. in an interview with a gun to your head.

we only got half of the story here, but if the workplace has a history of switching technology and trying new things often interviewing a specialist was still their mistake, not the specialist's, that wastes everyone time.