In principle, my interviews, which tend to be a lot more about "take this text from a DB and process it in this way and display it on a web page" are algorithmi

In principle, my interviews, which tend to be a lot more about "take this text from a DB and process it in this way and display it on a web page" are algorithmic too. I mean, if anyone's writing code, they're writing algorithms. But there's day-by-day algorithms where you're basically gluing lots of things together, and there's Project Euler problems. In my 20+ years of software engineering, I've personally encountered maybe 3 or 4 Project Euler-type problems in my real job. (And even those weren't as clean as those problems; I still had to integrate them back into some other real-world code base.) Expecting your candidates to be good at inverting red-black trees recursively when you want them to hook databases to web pages without massive security vulnerabilities or performance issues is silly. "Gluing lots of things together" is a descriptive term, not a derogatory one. There's a ton of things you need to know to be a good gluer nowadays; security, performance characteristics of all the pieces, we're adding more and more distribution into our systems, higher level stuff like integrating with teams, documentation of your code, how your workflow goes... there's more than enough to interview all day on these issues without ever having to quiz the candidate on puzzles from the back of a Knuth book. (This is agreement with you, not disagreement.)