[usrbinbash]

> If you aren't willing to do that, it's not the employers problem

But these sure look like employer problems:

a) Risking to miss out on good engineers that happen to be bad at skills that don't have a lot to do with the job.

b) Risking to hire people that are really good at prepping for standardized tests, but not at the skills the job actually requires.

c) Risking to have qualified people whith a choice simply walking out because they don't like companies using this hiring practice.

[edanm]

For most companies, a bad hire is much worse than missing a good hire. That's why in many ways, companies optimize in that direction.

[usrbinbash]

And, looking at this threads article in the OP, how exactly do puzzle-style-interviews "optimize in that direction"?

[edanm]

As I said in a different comment, I don't think they're necessarily optimal. But a lot of companies do them, which is at least some sign that they have some value. Personally I think slightly different approaches are better, but there are some benefits to a standardized, easy-to-administer test that is better than your random personnel at your company can come up with on their own. (I've seen many far worse ways to value employees than Leetcode-style interviwes).

Also, I'm not sure how easy Leetcode is to practically game. I may be way off here (truly), but most people who can get good enough at solving Leetcode-style problems (and are willing to put in that time) are probably better than those who can't. This certainly misses some people, but as I said, finding a filter that only lets through above-average candidates, even if it misses some others, is what a lot of companies are looking for.

[usrbinbash]

> But a lot of companies do them, which is at least some sign that they have some value.

"A lot do XYZ" is not a sign that anything has "some value".

> that is better than your random personnel at your company can come up with

I'm sorry, what are companies hiring for: To solve the problems they are trying to solve? Or to solve the puzzles in a standardized test? And who knows these problems and the skills involved in them better, a standardized test, or the people already working on them?

> are probably better than those who can't

Better at what?

[edanm]

> "A lot do XYZ" is not a sign that anything has "some value".

It is a signal that maybe there's something you're missing. "I think everyone else is doing this thing wrong" is sometimes true, but often wrong, or at least incomplete (because goals might be different).

> I'm sorry, what are companies hiring for: To solve the problems they are trying to solve? Or to solve the puzzles in a standardized test? And who knows these problems and the skills involved in them better, a standardized test, or the people already working on them?

The problem is that being good at hiring and at evaluating people is itself a skill. A skill that some people have, and some people don't. It isn't necessarily correlated with how good a developer someone is.

The other problem is that if you come up with a different "test" every time, it will make it much harder to compare different interviewees. I still ask interview questions that have to do with a system I built 10 years ago. I of course could update the question to something I'm working on now, and I certainly change the emphasis on what exactly I'm asking. But sticking to a question that I know works well, and that I've used many times, makes it much easier for me to evaluate people.

But let's just be clear - what would you suggest as a hiring criteria? Do you think the team that is hiring (which in large corporations might also not be the team that gets the hire, but that's another story.) You think the team that is hiring should come up with specific questions based on their current work? How often? How often should they change them? Who should be doing it, every team member?

I'm trying to get a sense of where we actually disagree.

[usrbinbash]

> "I think everyone else is doing this thing wrong" is sometimes true, but often wrong, or at least incomplete (because goals might be different).

That isn't the point. The point is, just because a lot of X do Y doesn't indicate that Y is the best solution, or even a good one.

> The problem is that being good at hiring and at evaluating people is itself a skill.

Yes, that's why we have HR departments, and why these can take input from the technical departments to do part of the evaluation.

> The other problem is that if you come up with a different "test" every time

Why would I do that? I am not advocating designing completely new interviews for every candidate, I am advocating not using the same interviewing process for every candidate in the entire industry.