Why are interviews harder than the job?

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?

Trial periods. Asking employees to do less in their first months.

Maybe not great mitigations, but that’s what I could come up with

After interviews, you hire Alice but Bob was a close second. Bob goes to a competitor. Alice doesn’t work out. A double whammy. Why not immediately try to get Bob? I’ve only seen this a few time.

In the US at least it seems common to review performance and put certain benefits on hold for 90 days to see if it's working out. This wouldn't mitigate the costs of the initial hiring or the opportunity cost of not selecting another candidate, though.

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

The 'cost of a bad hire' is received wisdom that needs to go away. The first order effects of your team's time investment are easy to see and make good content for your engineering leadership blog when you're aiming for promotion. The second order effects are what get debated in threads like this ad infinitum.

Paradoxically, a higher bar for hiring increases these consequences for everyone. A bad hire is only consequential in the first place because hiring managers are slow to cut them loose. Managers are slow to cut loose because they are morally culpable for the consequences to the individual they hired. When a manager extends an offer, they are accepting some responsibility for a significant change in a person's life. It's very difficult to walk that back when it's a bad fit, knowing that hiring is a slow process and every other company out there is scared of making a bad choice. But at the end of the day, interviews are an approximation of the candidate/company fit in what is ultimately a matching problem. More attempts make for better matches. Companies and candidates both would be better served by being faster to hire and faster cut loose.

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.

One additional downside to professional licensing is that it can be time consuming and costly. For example, to bring a new physician on board to a practice they must be:

* Licensed (allowed to practice in that state)

* Credentialed (degrees and experience verified)

* Enrolled (able to be imbursed via insurance)

* Priviledged (authorized to perform certain tasks/roles)

This could take weeks or months per physician and there is usually an entire team (Medical Staff Office/MSO) dedicated to the work.

Relatedly, if you hire Alice and she works out, but in months or a year, you hire for the same role, why not reach out to Bob again?

You invest all that time into interviewing Bob, but then if they don't get the offer, you never reach out to them again. I don't get it.

I don't think I've ever seen this done well.

Kind of like how the CFA used to be in finance.

In my experience, the hiring managers with the best track record have these in common, which mostly boil down to the hiring teams doing their homework:

(1) The expectations for the position are clearly defined (2) The hiring team members coordinate on questions and expected responses, and they are consistent in interviews. (3) The hiring team members know how to spot potential issues (e.g., excessive bad-mouthing of previous employers, etc.) (4) The hiring teams effectively leverage their networks for references. Ideally, there are not-too-distant trusted relationships between the candidate and the hiring team. In the absence of this, references are followed up on carefully (this has become an art form in modern times.)

These reduce the risk of someone slipping through the cracks. Hiring teams also get better with experience, so any mistakes should be carefully analyzed and corrective actions incorporated into the hiring process.

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.

It really, really sucks, that we have to be here.

Maybe have online application pages, that can’t be submitted, unless you fizzbuzz. :(

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.

> This could take weeks or months per physician and there is usually an entire team

That seems like a better alternative to what we have now! Some companies search forever for the "perfect" candidate, or otherwise have to sift through so much SPAM resumes that they are already taking "weeks or months."