[Bengalilol]

> "Another benefit of LeetCode style interviews is that they are somehow standardized. Standardized processes help large organizations stay consistent."

I may be overlooking some really important concepts here, but there I bug. It looks like the need is not for a "good programmer" (the article should define what is a good programmer btw) but for a programmer who applies to the standards for whatever it means. It is a bit chilling. And afaik those leetcode interviews tend to fade away.

> "How they navigate unknown codebases." That point seems very short-term sighted. For how long a codebase is considered as being "unknown" ?

Globally, "good" is not defined and the "scope" of the programmer's job isn't even touched, which I think changes the way you hire someone.

Anways, it was a nice read although I don't really know what to conclude. The pair programming concept is, for sure, the best I would like to experience in an interview.

[kasey_junk]

If you ever spend much time trying to _build_ a competent hiring pipeline (and every dev should it’s an eye opening experience) you come to realize that it’s very hard to evaluate the process itself.

For instance I found, the same questions, from a script, asked by different evaluators would regularly perform differently. But getting statistical relevance is hard!

So that’s the allure of leetcode. You can get a large population with standardization, relatively cheaply. That it’s actually a bad eval method gets lost in the wash which is unfortunate but I certainly understand it.

Conversely, “talk about your project” was a completely useless eval when I tried to use it. Good candidates failed, bad candidates passed, evaluators had all manner of biases to the point I started being suspicious that _time of day_ mattered more than the answer.

I’d 100% buy that an individual can accurately judge candidates with this approach, but I’d want heavy evidence if you claimed you could scale it.