The kung-fu of startup hiring (5 of 7): Planning your pipeline and interview stages.

Gil Belford
Don't Panic, Just Hire
6 min readJun 28, 2016
If only it was always this easy…

If you’ve been reading my previous posts then you should already have a good idea of how you can get plenty of candidates into your funnel (let’s call it a pipeline), regardless of whether you’re using an active strategy or a passive one. Congratulations, you’ve done the easiest part.

The hardest thing is actually being able to identify whether or not these candidates and you are a good fit for each other, making sure you don’t hire false positives, or even worse: miss out on a false negative (There’s a great post about this here). To achieve this you must ensure that your hiring processes are well designed and watertight, so as to ensure that you’re checking and vetting candidates appropriately and consistently.

How does one go about achieving this? By planning how many interview stages you’re going to need, who will take them, and what you’ll be checking for at each step along the way.

Another important thing to note here is that having a plan for your different roles ensure that you can be more efficient with both your time and the candidate’s time, as well as provide the candidate with a clear idea of how your hiring process is going to look like. And all of this leads to happier candidates. Those are good.

The main issue here is that there really isn’t a one-size-fits-all approach to this. It really depends on the candidate, the role, the company and how much bandwidth you have available. However, I’ll try to guide you along with some best practices for designing an optimal flow. So here’s what you need to figure out:

  1. How many interview stages do we need for this role?
  2. Who should take each interview stage?
  3. What do we need to check for at each stage?

How many interview stages do we need for this role?

This really depends on which role you’re hiring for. Intern? More than two is probably overkill. CTO? 5–6 rounds might not be an exaggeration.

Again, this is something that you need to figure out for your specific case, but keep this in mind: more rounds will decrease the likelihood of something important going unchecked, but it will also increase the amount of time involvement from your people. It will also make your process more complicated, which will likely make the candidate experience a bit worse.

The more senior the candidate is - the more influence (good or bad) they’re likely to have on your company - so the more thorough you should be.

The trick here is striking a balance. This is also something that you can fine-tune with time.

Who should take each interview stage?

Again, this depends on the role that you’re hiring for. But a good rule of thumb is to at least involve the people that they will be working closely with. That’s also why the more senior the person is, the more people they’ll need to interact with, and thus the more people they should talk to before you make a decision.

Another thing that needs to be said is that the people who are taking these interviews should have domain expertise. If the only person that’s interviewing your potential developers is your HR person, you’re probably in for a bad time.

For very senior hires, you can even ask outside people that are really experienced and who’s opinions you trust to interview them. At Hole19 we’re lucky enough to have some very experienced investors who help us with this.

Another thing you should keep in mind is people’s time. Believe me when I say that hiring can be a huge time investment, and if you have your CEO doing first rounds, they’re not going to be able to do much more. So determine who will take each round accordingly.

What do we need to check for at each stage?

If you want to ensure that your hiring process is watertight, then it is essential that you clearly define what needs to be checked at each stage of interviews. If you followed my previous post about preparing before you start hiring, then you should already have a list of characteristics that a candidate for this role should or should not have.

The next step becomes detailing clearly what needs to be checked, and ensuring that each person along the way knows that it is their responsibility to check it. You don’t want to discover on the 4th round of interviews that a candidate’s salary expectations are completely out of your budget, or that a candidate that you really like actually lacks the technical abilities to perform at his role. That’s wasting both your time and the candidate’s, simply because you weren’t organised enough.

My recommendation is for you to create a clear checklist of what needs to be checked at each stage, and that list is then passed from round to round as the candidate progresses through your funnel.

Having a checklist also ensures that you’re using the same criteria for different people, so as to have comparable data to help you discern one candidate from another, with no room for any (un)conscious biases to influence the process. (Here’s an amazing read on how Google revolutionised their hiring practices by using structured interviews).

To give you a practical idea of how this might look when applied to a real life scenario, I’m detailing how we like to structure our hiring here at Hole19.

When we hire senior tech profiles we divide it in the following way:

  1. When the candidate contacts us or we first contact them, we start with a small introduction to the company and the role, as well as an idea of how our hiring process looks like, and we gauge if there’s interest from both parties to continue. We respect our candidates’ time, and hope they respect ours as well.
  2. We then present our candidates with a technical challenge to complete at home over the course of a week. That tells us a lot about their technical competence, coding style and level of attention to detail. We feel that there’s a lot more to a developer than just his CV, and to make an informed decision, we prefer to have him work on something that is similar to what they’ll be doing with us when they join.
  3. After reviewing the challenge, we move the candidate to a technical interview with 1–3 senior members of our development team, where we discuss the contents of the technical challenge that they completed and try to understand the logic behind their decisions. This helps us understand his programming style a lot better, and also how it would be to work with this person.
  4. If we liked the candidate, we then do another round with our senior management team (usually myself and the CEO) where we discuss expectations, talk about the role and the company in greater depth and do an overall culture check (is this someone that the team would enjoy working with?). This is as much about us “selling” to the candidate as it is about us “buying”, meaning that we’re probing to find if the candidate is as excited as we are about what we’re building and whether or not they’ll be happy if they join. Ensuring that the candidate’s expectations are adjusted to the reality of your company (for better or worse) is essential.
  5. We definitely don’t know it all, and we feel that getting an outside perspective really helps, especially for senior hires. So we involve some of our investors over at e42 Ventures who’ve been doing this for a long time. Usually this is an in-depth technical interview.
  6. If all has gone well thus far, all that’s needed is for us to present and discuss the final offer and shake hands. Voila! A new colleague. :-)

Hopefully, with the above described steps, you should already be able to get a good idea of how you might go about structuring your own interview stages and pipeline. Having an organised pipeline will also allow you to be a lot more analytical about where your hiring efforts might be failing, which is something I’ll be talking about in my next post.

As always, if you have any questions or suggestions, you can reach me on LinkedIn or through email.

--

--

Gil Belford
Don't Panic, Just Hire

BD & Corp Dev, part-time investor and board member. Obsessed with food, wine and all things startup related.