Why Are Interviews Harder Than The Job?

I’ve seen a lot of startups try to make hiring easier over the years, but they all seem to converge on becoming slightly better applicant tracking systems.

Then, a few months ago, I saw this LinkedIn post.

Here’s the post in case you don’t want to log in to see it.

It’s similar in tone to this meme.

I’m currently leading an interview process at my current job. Whenever I do this, I remember how grueling and painful hiring is. And that is as a hiring manager–I know it is even tougher as a candidate in this job market. After all I am getting paid and many candidates are unemployed. I’ve been in the latter situation and the situation is often quite urgent.

But today, I wanted to dig into why interviews for software related jobs are often harder than the job itself. This is a common gripe, where the interview digs into all kinds of technical aspects that are not really needed in the day to day job, or is much tougher than the day to day work.

The reason for this is interview time is limited. Interviewers want to get as much information as they can about the candidate.

(Interviewees should do this too. Even in this market, finding out what you can about the company where you’ll be working is a good idea.)

An interview is like running 100m and a job is like a 10k. If someone wants to see who is better at running across, but only has a certain amount of time, they are going to have everyone run 100 meters, and not a 10k. Even if the real goal is to find the best 10k runner. Hence the Leetcode tests.

This is, of course, not great. But it is the least bad option.

Some alternatives include:

* contract to hire: This is great if the candidate has flexibility and risk tolerance (health care not tied to a job, willing to risk moving to another job in N months if the contract doesn’t lead to a hire). Many great possible hires will pass at contract to hire, though it does work for some people.
* homework for interviews: Asking a candidate to solve some problem which lets a candidate work in a slightly less high stakes environment. but requires candidates to do extra work, taking longer than just the interview. This also takes longer to evaluate as a hiring manager. And ff you are doing this, make sure you ask candidates to explain their solution, which helps mitigate AI assisted or copy paste solutions.
* pair programming: During the hiring process, work on an actual work related project. Companies that have OSS projects can use those, otherwise use something similar to what a new hire would be working on. Viable, but can be hard to pick up enough signal about non-technical skills. Also high-pressure for the candidate–I remember trying to use IntelliJ for the first time at an interview to write some Java code.
* leverage your network: Hire people you’ve worked with in the past. Time-tested, works well, but limits opportunities for those without experience or a network. Also means as a company you’re going to be more homogeneous, which can limit you (see this 1996 HBR article).
* historical interview: Beloved by the authors of “Who”, with this method you ask a series of questions about the candidate’s history, gleaning insight into their history. If they have done something similar to what you are looking for in the past, they’ll be able to do it in the future. I did this for the current hiring process so the jury is out for me, but am hopeful.

Hiring is hard because both parties have limited data and are trying to present in the best way, yet success is multi-dimensional and may not be visible for months. No easy answers.