Startup Engineering Hiring Anti-Patterns

Hiring great engineers has always been hard. It feels especially hard nowadays.

I have spent a lot of my career at Facebook, Dropbox and the hundreds of startups in our portfolio focused on hiring and recruiting. One of the most common areas where we dive in and help our companies is with early-stage hiring.

There are a lot of hiring tips/guides out there, but none really focus on hiring at the super early stage (think first 10–20 engineers).

Below are some Anti-Patterns that I have observed over the years. Stay away from them!

Hiring for a particular tool-chain or framework

A lot of startups will be looking to hire a python/JS/React/Node/(the latest framework) expert that lines up with the existing tool-chain or framework that the startup has used.

While this might allow you to refine your search criteria (and probably have strong funnel metrics), it misses the point that most frameworks are easy to learn and ramp up on. Great engineers all have the capability to learn new languages and frameworks easily.

Most engineers that Facebook hired didn’t know PHP and most Dropbox engineers didn’t have a deep background with Python. Even most of the iOS engineers at larger companies today don’t have a wealth of experience in Objective-C. Prior knowledge of a tool-chain is simply not required to be a high-functioning contributor.

Plus, you want to hire people who are comfortable learning new things, which is arguably the most important thing to filter for given that the needs and requirements for early-stage companies are fluid and constantly shifting. The last thing you want to hear is that ‘We cannot do X because Y doesn’t support it.’

Hiring Specialists

Similar to above, there is often a desire to hire for specialized roles early in a startup’s journey. I am often bewildered by how specific these roles can be: ‘Machine Learning Infrastructure Engineer who is experienced with Kafka data pipelines’.

The allure of hiring someone who knows how to do exactly what you need on Day 1 is understandable, but again, most great engineers (and particularly those who are good for startups) can ramp up pretty quickly into new domains. There are exceptions, but for the most part startups don’t need deep specialists. They need people who are quick learners and can rapidly find 80–20 solutions.

The team that built out Dropbox’s (incredibly hard and complex) custom replacement for Amazon S3 hadn’t built distributed systems for 20 years. They were strong generalists who had a passion for learning and figured it out.

Hiring deep specialists is a great problem to have once you are successful.

Comfort in the False Negative Zone

Most companies big and small are way too comfortable with False Negatives (saying no to someone who is actually a good fit). At big companies with larger funnels, this can be lived with (though still so inefficient) but I think is something that every startup needs to dramatically change.

The easiest thing in an interview is to find a reason to say no. I see this happen all the time. Someone will find a minor issue, blow it up and suddenly convince the entire interview panel that the candidate isn’t a good fit.

Instead, it is much much harder to construct a narrative that takes into account someone’s strengths and weaknesses and figures out whether:

1. The strengths are positive enough to outweigh the weaknesses
2. There is an area of outsized ability that needs to be considered
3. There is a clear path to the weaknesses getting to a stable steady state

This is pretty counter to regular Silicon Valley advice, but a startup should push itself to find real deal-breakers and not get comfortable with False Negatives.

A lack of funnel discipline

Most Startups founders have never done end-to-end engineering hiring before so it can feel very daunting and unapproachable.

One common solution is to throw a lot of energy at the problem and hope that it works out.

But hope is not a real strategy.

You need to get really detailed and all up in your Asana/Airtable/Google Sheets to manage the funnel. Break it down into Top-Of-Funnel, Initial Coffee Chat, 1st interview, Full Interview, Offer Out, Offer Close etc.

Every week, work that funnel. Make sure that people are moving through the funnel at reasonable rates. Debug where the drop-offs are.

Most importantly, don’t just focus on Hires made. That obfuscates both real progress and lack thereof. You can be doing a terrible job and get a lucky hire (happens all the time, but as I said before, that isn’t a strategy) or you can be doing a great job and the numbers aren’t there yet (which also happens often).

Slow to Hire, Slow to Fire

While not strictly related to hiring, this is too critical a part of the overall solution space to omit.

Most companies operate on the slow-to-hire and slow-to-fire model. They are comfortable with false negatives in the hope of finding true-positives, but then are way too slow to correct poor performance.

You really need to flip this on its head. As a startup, you need to be comfortable taking risks on hires but also parting ways if it isn’t working out after 2–3 months. This will feel hard, but in the medium-to-long run will feel a lot more sustainable. Some of the best companies I have ever worked with/for have operated this way and it leads a culture that doesn’t compromise on high-performance.