Tech Hiring Is Broken

There's a huge amount of waste in the hiring process for software developers. It is a wasteful process for both the developers being interviewed and the companies doing the interviewing.
Let's take a developer named Amara.

Amara goes through a technical interview for Software R Us. It's 4 1-hour sessions with 2 interviewers each. There's some algorithm questions. There's an architecture/design question. There's a series of questions about past projects and decisions made on those projects. Doesn't sound too bad right?

Amara then goes to another technical interview for AwesomeSoft. It is another 4 1-hour sessions with 2 interviewers each. There's more algorithm questions from the same pool of questions everyone sees in those cracking the coding interview books. There's another architecture/design question, though this one is a little more unique. Then comes the questions about past projects where Amara mostly regurgitates what was said in the interview with Software R Us.

Amara then does another technical interview with another company. And another company. And another company. Rinse and repeat the same algorithm questions and regurgitate the spiel about past projects.

It is incredibly repetitive and exhausting. Instead of interviewing until a company that is the right fit comes along, Amara may end up just taking an offer that comes quickly to avoid doing more grueling interviews. This could result in either a lower salary, a worse work environment, or both.

There's also the fact that many developers choose not to start looking for a new job despite being unhappy at their current one because they don't want to go through this process.

Sounds like companies benefit in that case right? 

Wrong.

Let's take a company named Software R Us. They need to hire a single developer. They make a job posting. They get hundreds of applications of varying qualifications despite the job posting listing the qualifications clearly. Someone in engineering management goes through all those applications to try and whittle it down to the best candidates.

Out of hundreds of applications, 100 could be a decent fit. That's a lot of people. Either 50 hours gets spent on phone screens or an arbitrary measure is used to whittle down that list to a more manageable 30-50.

Now after all the phone screens are done, 10 candidates seem really strong. Time to schedule the tech interviews. Hiring a developer is a big deal so dilligence is needed. 4 1-hour sessions seems to strike a good balance of dilligence and not spending too much time with every candidate. For a variety of good reasons we won't go into, each session will have 2 interviewers.

That ends up being 80 hours of your team's time spent in interviews. That's 80 hours not building product and growing the business. Tack on some more time after for all the various debriefs.

On top of that, good developers are not necessarily good interviewers. Interviewing is a skill of limited use in software development outside of hiring. Software R Us now has a choice in either accepting they don't have great interviewers, resulting in poorer hiring decisions, or they can support their team in developing some interviewing skills. The problem now is time spent developing interviewing skills is time not spent learning to build better products.

Hiring great people is important for companies so this is an important investment to make. I'm not arguing that. I'm just pointing out how much of an investment it is.

The best situation we could ever be in is when someone our team has worked before starts looking for a job. Their qualifications are solid and no interview can substitute having worked with someone for months or years. This is an easy hiring decision and most of the technical portions of the interview process can be skipped. The rest is just a discussion on whether the company is a good fit for that person.

That's a limited resource pool though. Not only that, but this way of hiring benefits people who work at larger companies and penalizes people who work at smaller companies (network size). It also benefits people who switch jobs frequently (say 1-2 years) over people who may actually like their job and want to stay there longer.

I've spent a lot of time pointing out the issues with tech hiring and no time on the solution or alternative.

That's because I don't have one. I've spent the past decade optimizing this broken process. I've gotten pretty good at it so I never really thought about how terrible it was until now. 

It is a problem worth thinking about and worth spending time trying to find a solution too though. If you're interested in talking to me about it, feel free to reach out.