I mostly agree with this.
I do believe that basic generic algorithms are absolutely necessary for programming roles as they their uses keep showing up; Things like algorithmic complexity analysis are quite essential for most non-trivial programming jobs.
However assessing interviewees by unrelated questions totally irrelevant to the problem domain of the role is a prevalent anti-pattern that plagues the industry.
Riddles/adhoc-puzzles may have their uses but for a large number of programming roles there is absolutely no correlation with that skill set with the every day work that candidates would end up doing as a part of their job.
Last time I got asked computational geometry algorithms for a Rails developer position, I politely thanked the interviewer and declined subsequent interviews. In another bizarre scenario the interviewer, in a surprised tone, asked me why I was not using an "efficient" language like C/C++ for solving the problems; their own codebase mostly used node.js.
Most of the good interviews I have been through used a live programming environment. The best interviews I have been through used TDD. TDD may not be ideal for all development, but it works pretty well for programming related interviews.
In all interviews I have myself conducted I have encouraged candidates to freely use REPL (I mostly work with dynamic languages) or other tools they would normally use while programming. I do, however, take note if the editor of choice is nano.