I think that leetcode-style interviews probably used to be more useful/more predictive when they weren't super common. Also, if you're one of the most-desirabl

I think that leetcode-style interviews probably used to be more useful/more predictive when they weren't super common. Also, if you're one of the most-desirable employers in the market [as Google was at the time it popularized this type of interview], nearly any aggressive interview strategy will be at least moderately effective, as the most dedicated candidates will invest lots of effort in preparation for your interview specifically, and if you reject tons of candidates that would have been effective, it costs you ~nothing, since, as a top target for candidates, you'd never run out of top talent to hire. Google also had an initial product which was primarily based around having a really good algorithm. Actually, several of their top early internal products also were about solving difficult problems with interesting and novel algorithms -- which gave them a huge bias in terms of what they were seeking. Of course, at Google's scale and popularity, books were literally published about their interviews and both how to pass them and how great they were -- so naturally others who either were or wanted to be top-of-market adopted similar strategies. Lots of top companies also had Ex-Googler founders or early hires, which helped perpetuate the familiar structures throughout the industry. For myself, I really dislike leetcode-style interviews. I think there is some value in asking, say, two different leetcode easy problems to verify that the candidate can produce reasonable code samples, and that they can express their ideas in code (and hopefully, also, verbally either while they code or in response to probing questions from the interviewer).