Hiring in the early days

When you are a seed stage company, finding great engineers can feel like a daunting task. If you are like me, you may not have a wealth of developer friends and acquaintances to reach out to, and your experience of interviewing might be virtually zero. If this is you, don’t be put off, here I will try to impart a few tips that I wish I had known (or at least had drilled into me to avoid) when I first started interviewing.

I will assume that you are the CTO of a startup, and as CTO you determine the direction the software is developed. This, as I’ve understood, is not necessarily true for all CTOs, you may be Head of Engineering where this advice resonates with you more. Whatever your title is, I hope you find this of use.

Avoid people who are obnoxiously smart

Your job is to guide how the software in your startup evolves over time, you are the one who steps back and looks at the bigger picture of how the pieces of the puzzle fit together, and you need a team that supports your thoughts. If you hire someone who is vehemently against The Plan, or disappears for two weeks and comes back producing work that is completely off-the mark, this will damage your company significantly.

Engaging in debate without animosity is healthy, you want to have your ideas challenged, but within a reasonable timeframe. Remember, you have almost certainly not found product-market fit yet, so you need to move fast, try out ideas, and see what sticks. Getting into lengthy arguments where individuals are unwilling to change their mind, or just get the job done, will impact your momentum.

So how do you identify these individuals? In my experience I’ve found the telephone interview a great method of quickly weeding out these types of personalities.

One question I might say in an interview would be:

“Give me an example where you worked on a project where the requirements changed 3–4 times, how did this make you feel? What were the mistakes made to cause a change in direction, and by whom? What would you have done differently?”

I’d plant this into the latter part of the interview, where the candidate has settled in and their personality starts to emerge, throwing a question like that early on when the nerves are still there will give an awkward response. A good answer will demonstrate patience and calmness in character. A bad answer will demonstrate frustration or hints of it. Remember people are likely to be a bit more reserved in their interview, so your looking for subtleties.

If you are still undecided, get references, and find out what their former employers’ views are.

Use technical questions that are relevant to the role

This seems like an obvious one, but you’ll be surprised how often this is overlooked. Don’t try to model your interviews on the likes of Google or Amazon, they are after different types of engineers.

What you are most likely after is engineers who have a lot of experience writing CRUD (create, read, update, delete) applications, the backbone to virtually all tech startup products. You want engineers that are product people, who can get that API built quickly in clean, comprehensible code, not necessarily engineers who can write a binary search algorithm on a whiteboard.

In our on-site interview, as a coding challenge for our backend engineers we will ask the candidate to, with a sparse set of requirements, create a factory class that generates different types of promotions, where validation rules will differ for each promotion type.

This relates directly to some of the challenges we have tackled, so it simulates a real-world example, and gives the candidate an understanding of where we made tradeoffs. In the past we have tried algorithm questions, and they usually don’t flow well, and is not a test of the actual job description, so we avoid them entirely.

Don’t forget to build out a solution to the question you are asking the candidate, if they ask questions that you don’t know the answer to, the candidate won’t get a good first impression.

Don’t lose sight that the interview process is a two-way street, she/he has to impress the team just as much as the team has to impress the candidate.

Involve as much of your team as possible in the process

We reserve this one for the on-site interviews, in my opinion this is crucial.

You are a small team, and everyone in the early days will be communicating a lot with each other, so it’s incredibly important that when you introduce a new member, that everyone is comfortable with that, any negatives or concerns should always result in a “no”.

This is also useful from the candidates side, and improves your chances of hiring a great engineer if they have met everyone or most of the team during the interview process, at the end of the day, a company is a group of people, if the dynamic is good, the collective output of the team will be fantastic.

Final thoughts

Think about the culture you want in the company, in the office, your day-to-day. What do you think a high-performing team looks like. Be wary of hiring the same personalities, look for people that compliment each other. Make sure you hire people that buy into the vision.

Pour over the wealth of advice and knowledge on the internet about hiring. Advice should not be taken as absolutes, there is no perfect path, think independently.

You are better at this than you think you are.