For coding, if a coding question boils down to implementing KMP string matching or something that's only realistically solvable by memorizing the entire algorithm and writing it out on a whiteboard, then it's not any different than any of the puzzle type questions like "why are manholes round?"
The proper way to evaluate coding questions, and what is mentioned in the article, is that one is evaluating general intelligence in the context of software programming. Is the candidate coming up with a reasonable solution? Are they asking questions to understand the problem better? If they get stumped by something, do they stay stuck on it, ask for help, or think through it? Can they find the issues with their code and improve on it?
I haven't heard of a better way to interview engineers, but if there is I'm definitely all ears.
And that's the reason many companies have to set the standards so high in the first place: excluding false positives (bad hires) is so important in practice that this distorts the whole hiring process. Fine as far as that goes of course, but it does mean that people who practice their leetcode questions are basically stuck with very expensive (per B and C) lottery tickets.
I think everyone knows at this point that algorithmic puzzles are not desirable; the real question is whether one can do better, even at FAANG scale.