Tech hiring sucks. But before we can fix a problem, we have to understand and agree on what the problem is. Today, a capable candidate, with industry experience and the ability to solve technical problems, can fail an interview due to factors that have nothing to do with their technical ability. Maybe they never learned to solve dynamic programming problems. Or they’re simply better at working at a desk with their computer set up the way they like, instead of writing code at a whiteboard. Or they’re just nervous.
I believe the interview process should have the following property: a capable engineer should not have to study to demonstrate their competency. The interview process should allow them to demonstrate what they already know. Everything I’ll write on this topic stems from this philosophy. This has a few consequences:
The skills a candidate demonstrates in the interview must match the requirements of the job. This doesn’t mean the interview process has to exactly match the work environment, but the skills the interview tests must be meaningful to the job. In my view, this rules out most computer science theory problems and riddles.
Interviewing will always be a skill separate from software engineering, but it’s important that interviewing skills alone don’t make or break the success of the candidate.
Hiring experienced candidates is very different from hiring junior candidates. Using the same process for both leads to failures across the experience range. After all, each skill level has different strengths, which must be evaluated differently.
Over time, I’ll go into more detail about my philosophy, but I want to set up my underlying assumptions. The caveat is that hiring today doesn’t follow this philosophy, so you’ll see content geared to the state of hiring today, like practice interview problems. Hopefully, the nature of such content can convince you these practices are widely used today, but maybe, they shouldn’t be.