you are right. But the fact of our industry is there is no way around these interviews. You have to do them.
Actually, there is. And it's quite simple, really:
"Thanks very much for your time, but I've gone through many, many rounds of questions like these, and have come to the conclusion that, while interesting and to some extent topically relevant, ultimately the ability to regurgitate answers to them on the spot has extremely low relevance to the work that one actually does as an engineer. And BTW I noticed your statement of the problem was not only very muddled, but English-wise, barely readable. And actually, as presented, the problem isn't actually tractable, math-wise. And like, you brought me in here to solve the knapsack problem on a quadrillion integers in 2K of space or whatever and yet, you couldn't even think to stock the whiteboard with fresh markers? Or clean it first, for heaven's sake? Really, what's up with that? And gee, isn't the vibe in here, like, really really starting to suck now, given that at one of the interviewers is starting to fumble with his phone already, indicating that he would clearly very greatly prefer to be somewhere else, doing just about anything else - like you know, actually productive - than what you've forced the poor sap to do for you right now?
"But we don't need to dwell on that. The point is that we have different perspectives on these things, which is of course perfectly fine. So if you don't mind, howabout we part ways and do something else with the rest of our respective afternoons?"
You have to do them.
Beyond tending to basic needs (shelter, clothing, food, etc) you don't "have to" do anything.
You may not get to work for those companies (and it is a great many, unfortunately) that have bought into the whiteboarding cult. And that may seem to kind of suck. But it's not like you "have to" work for those companies (as much as they would dearly, dearly like for you to implicitly and unquestioningly believe exactly that).
The truth of the matter is that, at the end of the day, some companies can afford to tell you no, even if you are talented, because they will get other people who want to do what you don't "have to" do. And it works quite well for them, as you can see.
You can look at it that way, if you want to.
My way of looking at is: "Are these people dealing with me in a way that makes me feel respected and valued, both as a potential colleague as a human being? And above all, trusted? Maybe in a 'trust-but-verify' sense, but fundamentally - trusted? If not, then who they are, what they're doing, how successful they are or how many people are supposedly all ga-ga to work for them -- none of that can begin to matter."
With a large amount of experience, we as interviews, should be asking much more about past projects and issues people have run into. I find it much more valuable to understand what real world problems people have faced, and how they solved them. Sometimes you even get to a point where someone actually has a good story about using the wrong algorithm, and so you still get to talk about algorithms.
This tends to also tell you a lot about the candidate’s abilities to work in the environment you are thinking of placing them into. Algorithms questions should be a fallback only when you can’t discover this while running through questions about their experiences.
Good questions are going to be more than, build a linked list in JavaScript or a bubble sort. Those are pure algorithmic questions, but you still need to walk the walk not just talk the talk.
Doctors need a license, and even so, you still hear about people who are found out to be frauds years later.
If software development didn’t have technical interviews the field would be full of people who wouldn’t know anything about programming, but who would call themselves developers anyway.
That is what fizz buzz or basic algorithms are for. Because really,smooth talking incapable collegus do more harm then normal incapable ones.
For example, I recently had someone run through a distributed system's set of questions related to kafka and some AWS services. It became obvious through this questioning that what he had built was not capable of guaranteed message delivery, i.e. the system was lossy.
The rest of the interview was about this system and how he would rebuild it to make sure there were no messages lost between all the handoffs of the system. We got into many very detailed areas about persistence, atomicity, idempotentcy, etc.
It should not be a shoot the breeze conversation about buzz words, it should be a very detailed process of getting down to the most complicated piece of software someone has worked with. It becomes very clear, very quickly, if they are bullshitting you, and then you don't hire them.
Unfortunately I don't have a good solution to this problem.
I'm wondering how interviews in other professions look like. For example when you're a director of a hospital and want to hire a surgeon. I guess you don't ask him to come one day to make a little surgery for free.