Tuesday, June 25, 2024

My spiciest take on tech hiring

My spiciest take on tech hiring

… is that you only need to administer one technical interview and one non-technical interview (each no more than an hour long).

In my opinion, any interview process longer than that is not only unnecessary but counterproductive.

Obviously, this streamlined interview process is easier and less time-consuming to administer, but there are other benefits that might not be obvious.

More effective interviews

“When everyone is responsible, no one is responsible.”

Interviewers are much more careful to ask the right questions when they understand that nobody else will be administering a similar interview. They have to make their questions count because they can’t fall back on someone else to fill the gap if they fail to gather enough information to make a decision on the candidate.

Adding more technical or non-technical interviews makes you less likely to gather the information you need because nobody bears ultimate responsibility for gathering decisive information.

Better senior applicants

When hiring for very senior roles the best applicants have a lower tolerance for long and drawn-out interview processes. A heavyweight interview process is a turnoff for the most sought-after candidates (that can be more selective about where they apply).

A lot of companies think that dragging out the interview process helps improve candidate quality, but what they’re actually doing is inadvertently selecting for more desperate candidates that have a higher tolerance for bullshit and process. Is that the kind of engineer that you want to attract as you grow your organization?

Priors and bias

In my experience, people tend to make up their minds on candidates fairly early on in the interview process (or even before the interview process begins). The shorter interview process formalizes the existence of that informal phenomenon.

Especially at larger tech companies, the hiring manager already has a strong prior on a few applicants (either the applicant is someone they or a team member referred or has a strong portfolio) and they have a strong bias to hire those applicants they already knew about before the interviewing process began. Drawing out the interview process is a thinly veiled attempt to launder this bias with a “neutral” process that they will likely disregard/overrule if it contradicts their personal preference.

That doesn’t mean that I think this sort of interviewing bias is good or acceptable, but I also don’t think drawing out the interviewing process corrects for this bias either. If anything, extending the interview process makes it more biased because you are selecting for candidates that can take significant time off from their normal schedule to participate in an extended interview panel (which are typically candidates from privileged backgrounds).


The inspiration for this take is my experience as a hiring manager at my former job. We started out with a longer interview process for full-time applicants and a much shorter interview process for interns (one technical interview and one non-technical interview). The original rationale behind this was that interns were considered lower stakes “hires” so the interview process for them didn’t need to be as “rigorous”.

However, we found that the interview process for interns was actually selecting for exceptional candidates despite what seemed to be “lower standards”, so we thought: why not try this out for all hires and not just interns?

We didn’t make the transition all at once. We gradually eased into it by slowly shaving off one interview from our interview panel with each new opening until we got it down to one technical and one non-technical interview (just like for interns). In the process of doing so we realized with each simplification that we didn’t actually need these extra interviews after all.


  1. I've been saying this for years! Especially for 99% of the developer jobs where an average dev is perfectly capable of handling all the tasks being thrown at them. Anecdotally, the best places I worked at followed a simple process, like you described. One of them was literally an hour long phone call where they said they saw my GitHub profile, and they said they're happy with my technical knowledge, when can I start? The other one I got a jupyter notebook with some questions that were highly relevant to what I would be doing, and we went through them together with the interviewer.

    Whenever I had to conduct interviews, I gave a poorly written authentication module I wrote for the purpose of the interview, and asked candidates to review them. Magically - and contrary to what I often see commented on posts about tech hiring - I was able to decide whether someone is capable or not, there were no pretenders slipping through the net. My belief is if you can't roughly gauge a person's skill level from a 30 min conversation, you probably shouldn't be conducting those interviews in the first place - there are exceptions of course, but for most companies, especially most SaaS companies I don't think there are many of them.

  2. :) Fair. I have a simple 3 step interview process I've used for a few years and for different positions - dev, QA, PO..

    short ~ 20 minutes get to know each other and understand what both parties are looking for.
    This can be done by almost anyone in the company/team and I find it important because:
    - we can always explain clearly what the role is, what the team is and were the company is going. Not easy to put all this information in a job posting.
    - the candidate has the chance to explain what he/she/they are looking for.
    - team and mission fit is easy to find out and
    - people sometimes have very short/cryptic or a bit exaggerated CVs and this is a good chance to find out more.

    This step is important since we had candidates which stopped the process here as they were looking for something else as well as candidates for whom we stopped the process here.

    Then a simple challenge either sent via Mail, or live with a colleague or pb nicest - in our offices.

    In any case the last step is to talk about the challenge /solution with 2 or 3 people, either straight after in the office or remote if the challenge was done remotely.

    I like to involve people from other teams in the process (relevant colleagues which will work with the role) most likely in the last step.

    Then I also make it a rule to talk about the candidate with the team and allow everyone to voice out any findings or concerns they have. Surely there is a probation time and you can let people go, but sometimes people behave differently with different people (race, sex, age, whatever) and I (as just one person and also a white not even middle aged man) will definitely not catch or see everything.

    I guess overall there are 2 interviews in my process but it can have 3 steps if the challenge is done remotely, :)