I've consulted with quite a few companies on their interview process. Almost all of them had adopted Leetcode style interviews. My first question to the team always is: what exactly are you evaluating when you interview someone?

And I rarely get an answer that makes sense. Instead I get mostly rationalizations for Leetcode. The thing is I recognize those rationalizations because I was certainly guilty of it in the past ("We're evaluating intellectual curiosity" is one I cringe at now).

The real problem from my perspective is that most teams have never taken the time to really think about and identify the underlying principles about how they want to work. We go through a process of defining those principles and all of a sudden the interview gets a lot clearer. Do you value the highest quality code? Do you value getting things into the world quickly and then iterate towards the final solution? Is security always at the front of your mind?

Getting really specific about what exactly being "excellent" means to a team is really critical.

Because then you can design an interview process that actually selects for those things. I've never had a team define "the ability to solve leetcode problems under pressure quickly" as an endpoint they actually care about. Some teams continue to use leetcode, but only as a small part of the process with problems that ARE actually directed at what they care about. Having been through a bunch of interviews in my 25 year career I instantly know when a team has actually done the work to design a good interview process (which has been far too rare in my experience).