It seems pretty obvious to me that this kind of interviews are simply there to assess how much you want to work for a certain company. As in: would you be willing to study for months, go through mock interviews, read books, test your skills etc. to have a shot at working for us? Even though the majority of that stuff will likely have zero impact on your day to day work? That's all there is, really. I've had no proble…
If not algorithms then what would you use to test a generic programmer? You would have to setup a custom panel based on each candidate. A person who has only worked for PHP would need a different panel from someone who has worked on C++ all his life. Algorithms is language and framework agnostic. It doesn't matter if you work in embedded or data science. It doesn't matter if you code in C or Python. The same question…
Most devs use a handful of algorithms in their entire career. And any algorithm they do use was probably adapted from pseudocode on Wikipedia.
It really comes down to what do you want the developer to do? Are the things you're testing them on even relevant to the job?
I'd argue what most companies are testing through their interview process is largely irrelevant.
If it's a generic programmer, then it's perhaps a position where's there's a range of technologies, maybe a range of languages to pick up and a range of existing software to support. Well in that case you want someone who's quick to learn and eager to train themselves, not afraid to ask questions, not afraid to admit they don't understand something, etc. Whether they can write quicksort on a whiteboard is probably the stupidest thing you could interview them on.
I think the best kind of interview isn't overly technical, but rather one that prods the interviewee to think about problems. Describe a fictional system, what would they suggest to make it scaleable? What would they suggest to improve performance? What would they suggest to reduce the time between writing the code and shipping it. Do they understand what a CI/CD system is? Are their first thoughts "rewrite everything!"? Do they think about iterating software development or are they the kind to dump 200 files on someone for code review?