A Startup's Guide to Hiring

by Alex MacCaw

As a founder and CEO, your role will increasingly turn to two major areas: hiring the right people, and ensuring they stay. We're going to tackle the former area in this article and discuss a good framework for hiring engineers.

Every company's hiring process is slightly different, and yours will likely evolve as your company grows. However, it's important to set the right foundations in place since hiring the right people is crucial; it will make or break your company.

Sourcing candidates

Finding engineers and persuading them to interview is probably going to be your hardest challenge when it comes to hiring. Initially your inbound flow of candidates is going to be very small. This will grow as you company gets more of a brand, especially if you invest in developer-relations, but you should definitely *not treat this as a reliable source. Building a good engineering brand is nontrivial, and the companies that do it well are very deliberate about it (in the same way that they're deliberate about building a good internal culture).

Initially you're going to have to ruthlessly tap your own network. Old colleagues, anyone you went to university with, friends, friends of friends — you're going to have to approach as many good candidates as you can.

Whenever anyone joins your company ask them to write down a list of 10 people they've always wanted to work with. If they know the candidate, let them be the person to reach out. Warm introductions are infinitely better than cold-emails. Likewise, an email from an engineer or founder is much better than a recruiter reaching out.

For example, here are some ideas of how to source candidates:

  • Tell everyone you're hiring. Ask your friends who'd they hire.

  • Go through all the people you follow on Twitter, and figure out which ones are the best engineers. Email a hundred of them and expect to hire three (this worked for me at Stripe).

  • Go through all the contributors of a open source project you admire or use. While engineers might not have started their own projects, contributing patches and fixes to other ones is a good sign.

  • Hacker News has a post once a month where companies can post job ads. In my experience this has worked, but to limited effect.

  • Use Facebook Graph Search to find computer science graduates from your university, or comp sci graduates who are friends of friends.

If you're funded, many VCs offer recruitment services where they will forward a batch of CVs to you every so often. In my experience, these emails weren't that useful and often went ignored.

The main takeaway is that as a fledgling startup, you should focus almost all your efforts on outbound recruiting via referrals and be skeptical of inbounds.

Pitching candidates

You need to ensure there's a good deal-flow of candidates, otherwise the other parts of your hiring process aren't going to function. Unfortunately good software engineers are few and far between. It's a sellers' market, and the good engineers likely already have jobs. As a founder you're going to have to get your sales cap on and pitch your company.

Be prepared to play the long game with your early team. The first few hires are key, so make them count. Get to know them before pitching them. Get invited to the same parties, get coffee, lunch or drinks with them, invite them to house-warmings. Be polite, but be persistent.

When you're pitching candidates you should initially focus on the problem and the team, rather than perks or incentives — that comes later. First you have to pique their interest and then offer a deal that's hard to turn down. Figure out what makes them tick. Are they interested in learning more about startups? Or perhaps they prefer intense machine-learning challenges? Do they want autonomy or direction? Do they need visas or other help? You should tailor the pitch to each candidate.

Contrary to what you often read, incentives matter. Whether people like to admit it or not, salaries and stock are definitely a motivating factor. In American culture at least, salary is a taboo subject which people like to skirt around with innuendos. However, the fact of the matter is that in an expensive city like San Francisco, every grand over 100k really makes a difference. Clearly you'll need to weigh that against the fact that as a startup you probably have very little money, but if you have the choice it's worth not skimping on this.


Once you've got candidates through the door, you need to figure out if they are the right fit. This is incredibly hard to do in the course of a day's interviews, and you will get it wrong from time to time. You will also pass on excellent candidates by mistake; no interview process is perfect. It's better to make a mistake passing on candidates than hiring the wrong ones though; the latter is much more costly. Optimize for that, and keep the hiring bar high.

Give the most signal to referrals from people the candidate has worked with previously. Not everyone performs well in interviews, but if say they've worked incredibly closely with one of your engineers who can vouch for them, then consider that a very positive signal.

Give a lot of signal to open source work and GitHub. Not everyone is in a position to contribute to open-source work, but for the ones who do it's a convenient way of ascertaining their abilities. Some companies, like GitHub, use this signal exclusively when hiring software engineers.

With coding interviews, make sure that you get similar disciplines paired up. Don't get a back-end engineers to interview front-end engineers. If you do end up with a mis-match of disciplines, then make that particular interview more of a culture test than a programming one.

Make interviews as practical as possible. Ask candidates questions they will come up against on a daily basis. As Greg Brockman from Stripe says:

Our interviews try to simulate the work you'd do on a day-to-day basis. We don't ask any purely algorithmic questions — no project at Stripe has ever required writing a red-black tree from scratch. We're also perfectly okay with people Googling around or collaborating with their interviewers.

Avoid questions that require somewhat arbitrary "ah-ha!" moments —the best questions are the kind that start off simple and gradually build on themselves. I've written about front-end interview questions before, but one of my favorite things that Stripe does is the bug squash.

We hand you a popular open-source project along with a failing test case for some bug. Your task is to fix the bug (or make as much progress as you can towards doing so). We're looking mostly to see how you handle navigating an unfamiliar codebase and fixing problems in other people's code.

It's worth checking out the Quora question on Stripe's other interview techniques too. For culture tests, Stripe has a Sunday test, which is a useful thought experiment for evaluating candidates.

We apply what we call the "Sunday test" to every candidate. If this person was alone in the office on a Sunday, would that make you more likely to come in just to hang out with him? We only make a hire if the answer is a strong yes. Not only should working with your coworkers be tolerable, it should be something you actively enjoy.

It's also a good idea to have a pair-programming element to your interviews. When I interviewed at Square a few years ago, I pair-programmed with one of their engineers, added a feature and committed production code. As a candidate, it was interesting and gave me a good taste of what the job would be like. As an interviewer, this is probably the closest you're going to get to seeing what someone is actually like to work with.

Assemble a group of the interviewers at the end of the day and make a decision. Everyone should have a veto. Inform the candidate by the very next day. Whatever you do, don't make it a drawn out process; candidates will appreciate if you're up-front. Be courteous to those who you decline — you want to make sure the experience was positive and that they're future ambassadors for the company.

Listen to feedback, and make sure your process is always evolving and improving. Hiring well is an extremely tricky business, but there's a very strong correlation between the companies that get it right and the companies who succeed.

Huge thanks to Aline Lerner and Michael Schade for ideas and proofreading.