In that case it's not really particularly a problem of senior vs. junior, but one of software jobs in general. My beef is more with the idea that we shouldn't verify whether people that call themselves senior can actually write any code. I've seen candidates with "senior" on their resume who can't even write code at an intern-level proficiency.
When I'm interviewing, I don't mind reversing a linked list doing a binary search. It gives me an indication that the company is actually concerned with whether its employees have some baseline competency. I regard it as a positive signal.
Writing down binary searches and reversing linked lists is one thing, but what people are talking about here are questions of the nature "write down this algorithm that was publication-worthy 30 years ago," or, what I like to call "stupid programmer tricks." Those would include "implement rand10() using rand7()," or "find the closest palindrome to a given integer n."
I absolutely should be tested on when to use a dictionary vs an array vs a tree. But if finding the "acceptable" solution to a problem relies on remembering one particular algorithm from college that I've not had to use in a dozen years, as some LC problems do, then that's reducing a senior level dev interview down to a junior level dev interview. As it stands, all senior level devs have to do a month of Leet Code just to be competitive. The people down voting me can't honestly say they remember every single one of the algorithms that are popular on LC without studying. That's just not being honest.
When I'm interviewing, I don't mind reversing a linked list doing a binary search. It gives me an indication that the company is actually concerned with whether its employees have some baseline competency. I regard it as a positive signal.