Article

A Practical Guide for Founders setting up a Tech Hiring Process

I have been helping startups hire software developers for the past 3 years. Along the way, I've seen some companies get tech hiring right. I've also seen others fail miserably.

Those who fail all have one thing in common: a long and tedious hiring process.

Those who get it right all follow a process similar to the Minimum Hiring Process. I'll tell you what that process looks like so you don't have to waste time experimenting.

Hiring Matters

Most founders and engineering leaders know that hiring is one of their top responsibilities. Building a great engineering team is a necessary condition for success.

It's probably the 2nd most important thing to get right, right after product-market fit.

Unfortunately, most founders have no idea how to hire.

They’re typically strong engineers with a product-driven mindset. Which is great for building product, but irrelevant for hiring.

And unlike what happens with product, it's very hard to iterate on hiring. Once a decision has been made, it's final. It's hard to correct. Because correcting means firing.

One thing that founders always underestimate is how hard it is to recruit.

Sam Altman, Y Combinator

If you’re reading this, you’re probably interested in doing technical hiring the right way.

The goal of this article is to describe the simplest technical recruitment process that works.

Let's get started.

Minimum Hiring Process

The Minimum Hiring Process is the simplest hiring process that collects enough signal from candidates to confidently make hiring decisions.

I have been lucky to see the hiring processes of multiple companies. One thing is always true: the companies with the highest standards typically have short processes.

These companies understand that great candidates aren’t on the market for long. They need to balance collecting enough signal with moving quick to avoid losing candidates*.

*It’s worth noting that the same does not apply to well-known brands (ex: FAANG). These companies benefit from more rounds of interviews due to the volume and quality of applicants. Hiring for FAANG is fundamentally different than hiring for other companies as it's more of a filtering than a sourcing problem.

The Minimum Hiring Process consists of 4 steps:

After the 4th interview, more interviews don’t provide much additional signal despite further delaying the process.

Let's go over what should happen in each of those steps.

1. Screening Call

This step is typically conducted by HR or a Recruiter.

I usually start this call by asking candidates what they know about the company. This provides some insight into their preparation and motivation.

Once that's covered, I go through 3 main topics on the call:

• Company and role description (10 - 15 mins). I explain in as much detail as possible the company and the role they would fill.

  This includes telling candidates about the founders, the product, the team they would join, the tech stack, what they’d be working on, the impact they’ll have, the type and length of contract and the timezone.

• Candidate’s professional background and motivations (10 - 15 mins). Then we go over the candidate’s background.

  I start by going over their professional experience, what they’re looking for in a new role (this is always useful at later stages), what compensation they’re expecting and their notice period.

• Light technical screen (10 - 15 mins). I like to have a technical conversation with candidates around topics they should be comfortable with.

  I usually shy away from language specific questions and cover broader topics like git, testing strategies or architecture.

  Here's an example of a question I sometimes ask backend engineers (thanks Hussein Nasser!).

2. Hiring Manager Call

This call is typically more focused on assessing cultural fit rather than technical skills, which will be evaluated more in-depth later.

Here are the main topics of discussion for this call:

• Selling the role.The Hiring Manager is the most qualified person to inform the candidate about the environment, the challenges and the work done on a daily basis. I explain in as much detail as possible the company and the role they would fill. This includes telling candidates about the founders, the product, the team they would join, the tech stack, what they’d be working on, the impact they’ll have, the type and length of contract and the timezone. Doing a good job in this stage is vital to ensure the candidate will be motivated and make a solid effort on the technical challenge, when he’s asked to spend a few hours on a test project.

• Deep dive in specific candidate experiences.It's typically more geared towards assessing cultural fit rather than technical skills, which will be evaluated more in-depth later. Rarely do candidates get rejected after this stage - only in those cases where there is a clear misfit of skills.

It's crucial that the Hiring Manager takes detailed interview notes.

3. Technical Challenge

Technical Challenges can take a number of forms. There are multiple online platforms that help companies conduct pair programming exercises from a set of predetermined challenges.

A better solution would be to set up a base project (ex: a GitHub repository) using the stack the company uses in production and asking candidates to implement a small feature.

Providing a base project is important because it saves a couple of hours of tedious setup work for candidates and lets them focus on the task that matters.

There are 2 important rules to keep in mind when designing technical challenges. They should:

1. Have a narrow scope. Candidates should be able to complete them in 2-3 hours (in the case of a take-home project). If you’re not sure how long a challenge would take, ask a member of the team to take the challenge and multiply the time spent by 1.5 to get an accurate estimation;

2. Resemble real work as much as possible. This is why I prefer to have custom technical challenges to sample exercises in online platforms - the fact that someone does well in LeetCode / HackerRank exercises doesn’t mean they will be able to work effectively on your Rails app.

You will be surprised by the amount of signal you will be able to collect from such challenges.

It always amazes me how many different solutions candidates provide for the same narrow problem. You don't need to make the challenge very hard nor very large in scope to see this.

When assessing technical challenges, it’s important to consider the whole interaction with the candidate, not just the code.

This means considering the clarification questions they ask, the architecture of their implementation, the test coverage, the git history, the PR, etc. All of it provides relevant signal of what it would be like to work with this candidate.

4. Final Interview

The Final Interview is usually more of a culture fit interview. It’s usually run by senior leaders at the company and/or the members of the team the candidate would be joining.

It can consist of one interview with 2-3 team members of multiple 1:1 interviews, one with each team member.

All candidates who reach this stage should already be vetted from a technical point of view. So the goal is to try to clarify how it would look like to work with this person on a daily basis.

This goal of this call is to minimize the risk of surprises. It should help the other members of the team weigh in on the candidates and also introduce candidates to the people they would be working with.

This is also the last chance for interviewers to sell the role to candidates. Typically, the offer rate for candidates who reach this stage is pretty high.

This is a very brief overview of what a Minimum Hiring Process could look like. I can vouch for its effectiveness because I have personally seen multiple companies apply this process and hire amazing people in a short time frame.

I’m confident this process would work for any small- to mid-sized tech company. If you go ahead and implement something similar, please let me know how it goes for you!