[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.

[edanm]

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

HR departments can't do technical interviews. You need technical people for that. But being technical isn't sufficient, you also need to be good at interviewing.

> I am advocating not using the same interviewing process for every candidate in the entire industry.

Is it the same process for every candidate in the industry? I'm not in SV, so maybe it's different here, but I've seen many different processes at many different places, and they were definitely not all identical.