Hire people who are going to do their best work ever, for you, after having partially but not fully mastered everything you want, via their previous jobs. It's easy to evaluate a resume. It's harder -- but not impossible -- to assess potential. Working inside a big tech company for six years, I saw that PM hires were done almost entirely on pedigree: find me another Stanford grad. These tended to produce a lot of fast exits as well as some comically bad and totally predictable fails.
Engineering hires were done on hunger, drive, scrappiness (and networks). They fared better.
Press (politely) for extra details via follow-up questions. Make it easy for the legitimate doers to share specifics of what they've done and learned, while the posers get vague in a hurry and change the subject.
Even very smart people aren't going to waltz in and be able to code fast enough to solve harder interview problems without practicing.
So, people who can pass algorithmic interviews are smart people who also had the hunger/drive to study up/practice some.
Back when people did in person interviews, people were writing psuedocode on whiteboards, so knowing the right algorithm and being a strong programmer was necessary, and I can see how one might not need to practice.
However, with the move to online interviews where people are expecting running and debugging some complex solutions (so you cannot hand wave trivial but potentially time consuming helper methods), coding speed can easily become the bottleneck.
> 2) give a lot of preparation to candidates beforehand, even for non-leetcode interviews, as it helps filter who can efficiently and diligently use provided information to increase their performance.
Yes, this reminds me of the netflix interview process where they told me to read the culture packet thoroughly, then quizzed me on it! It was quite easy, but you can bet that a lof candidates don't take that seriously.