←back to thread

56 points mooreds | 1 comments | | HN request time: 0.204s | source
Show context
MontyCarloHall ◴[] No.45413429[source]
Why?

Because the vast majority of job interviews are with terrible candidates, even if the majority of candidates are excellent. This apparent paradox has a simple explanation: excellent candidates selectively apply to a few companies and get interviews/offers at almost all of them. On the other hand, terrible candidates are rejected at every step of the hiring process, and have to constantly reenter the interview pool.

Suppose 90% of candidates are excellent and 10% are terrible. If the excellent 90% only need to interview at one company, whereas the bad 10% need to interview at 20 companies, then only 0.9/(0.1*20+0.9)=31% of interviews will be with qualified candidates. To retierate: almost 70% of interviews will be with terrible candidates, even though 90% of people applying for jobs are excellent.

Because the cost of a bad hire is so consequential, the interview process is not designed to efficiently handle a minority of qualified candidates, but rather efficiently weed out a majority of horrible candidates. It is therefore a terrible process for the people actually qualified to pass it.

replies(11): >>45413500 #>>45413504 #>>45413589 #>>45413605 #>>45413646 #>>45413652 #>>45413685 #>>45413803 #>>45413961 #>>45414929 #>>45421716 #
mooreds ◴[] No.45413589[source]
Ah, the "market for lemons" argument: https://www.jstor.org/stable/1879431

> Because the cost of a bad hire is so consequential,

This is stated all the time and I feel it is true. But is there any way to make it less consequential? That was my main argument for contract-to-hire (though I know there are downsides to that approach).

Are there any other ways to make hiring less risky?

replies(6): >>45413629 #>>45413700 #>>45413728 #>>45413750 #>>45413857 #>>45414927 #
gwbas1c ◴[] No.45413750[source]
> Are there any other ways to make hiring less risky?

Professional licensing.

Many other fields require professional licenses. I don't understand there's so much opposition in our field.

(Ok, I do understand.) In general, licensing has some risks:

The lemons will get excluded from the field. (Which is kind of the point.)

Or, the lemons will decide what the criteria for a professional license is; which turns it into a BS hurdle.

---

That being said, the article gets closer to the point of what a professional license is for: "An interview is like running 100m and a job is like a 10k.". If the license is more like running a 10k, then interviewers can rely on it to do a better screening than they could ever hope to do.

replies(4): >>45413878 #>>45413921 #>>45414122 #>>45416863 #
ChrisMarshallNY ◴[] No.45413878[source]
The issue with professional licensing, is that it's very, very specific.

In things like civil engineering, there's usually mandated context. You have to work within certain parameters, so it's not too difficult to test with real-world criteria.

With software engineering, it's all over the place. In fact, one of the most exciting things that I used to look for, in potential candidates, was people who were not bogged down with dogma, and would bring alternative viewpoints to the team.

Since anyone coming into my team would require a ton of training; regardless of their seniority, I always had a nice, long on-ramp, in which I could evaluate people.

replies(1): >>45415532 #
ryandrake ◴[] No.45415532[source]
There can be a halfway solution that helps: A professional software engineering license that signifies an extremely basic, barebones level of skill. Companies would still need to interview candidates, but they wouldn't have to do FizzBuzz or "write a for loop" types of interviews with candidates who literally cannot write code at all. It wouldn't guarantee the person was an expert in inverting binary trees, but it would at least represent a minimal knowledge and skill bar that one would expect any software engineer to meet.
replies(2): >>45416180 #>>45416495 #
1. gwbas1c ◴[] No.45416495[source]
One of my interview questions used to involve putting up a parameterized SQL statement on the whiteboard, (select userid, email from users where userid=?), give the candidate instructions on how to use a data reader, and then expect them to construct a "user" object.

I did this because I was part of a project that failed because the leads did not know how to work with a database. They thought the ORM would just magically load objects. Without understanding the basic limitations of data readers, they painted themselves into a corner.

Licensing basically needs to filter this kind of thing. IE, you don't get a license to work with a SQL database unless you can work with a data reader.

---

The irony was that we very rarely touched SQL, but the question was one of the greatest filters out there! It showed who understood basic concepts, who was just BSing their way though, and who would get stuck in high-level abstractions.