They're too busy writing self congratulatory blog posts on their hiring process to have time to improve it.
https://alexgolec.dev/reddit-interview-problems-the-game-of-...
https://alexgolec.dev/reddit-interview-problems-the-game-of-...
I'm interviewing you too, so give me something that reflects the problems you solve as a team, otherwise my assumption is your office is full of white boards containing puzzles of the day and your tech is all 3rd party libs.
It may also be that anything work-related is actually too long to fit into a limited interview time.
Now, a trivial, brain-teaser, question would be "you have an NxM matrix, and you can either go left or up. How many paths are there from the lower left, to the upper-right corner?"
I consider it a brain-teaser because if you write code that contains any matrix manipulation or searching, you have basically failed. There is a closed-form expression for the number, so...
[1] By "non-trivial", I basically mean that there are multiple correct solutions.
The way I would apply that problem interviewing someone is: We have 1 hour. Here is this problem (to which of course I know the solution to already).
How would you solve it? Let's solve it together so that I can see your decisions, your code, do you use exceptions? do you use specific type of exception for different errors? do you split functionality in a lot of functions? do you know nifty language tricks (maybe a bit of code golfing or functional constructs if JavaScript or Ruby).
The problem comes when the "interview problem" is passed from the creator to the "mid-level" Engineer who now has to do the interview. For them it becomes: "Ok, you gotta implement this in one hour", and they don't know the nuances or reasons for the problem.
I've seen this first hand with an equivalent problem. I had all this nice interview process that I applied, and the first time I shadowed one developer so that he could do the interview, he was just looking at the poor interviewee fail due to nerves, with the aim to evaluate him only on the merits of how far a set of working code did he had.