Here are some things I’ve learned over the years about recruiting programmers* to startups. This is a big topic: many of the points I make briefly here could warrant their own blog posts, and I’m sure I’ve omitted a lot.
- The most important thing to understand is what motivates programmers. This is where having been a programmer yourself can be very helpful. In my experience programmers care about 1) working on interesting technical problems, 2) working with other talented people, 3) working in a friendly, creative environment, 4) working on software that ends up getting used by lots of people. Like everyone, compensation matters, but for programmers it is often a “threshold variable”. They want enough to not have to spend time worrying about money, but once an offer passes their minimum compensation threshold they’ll decide based on other factors.
- Software development is a creative activity and needs to be treated as such. Sometimes a programmer can have an idea on, say, the subway that can save weeks of work or add some great new functionality. Business people who don’t understand this make the mistake of emphasizing mechanistic metrics like the number of hours in the office and the number of bugs fixed per week. This is demoralizing and counterproductive. Of course if you are running a company you need to have deadlines, but you can do so while also being very flexible about how people reach them.
It is sometimes helpful to think of recruiting as 3 phases: finding candidates, screening candidates, and convincing candidates to join you.
- Finding means making contact with good candidates. There are no shortcuts here. You need to show up to schools, hackathons, meetups – wherever great programmers hang out. If your existing employees love their jobs they will refer friends. Try to generate inbound contacts by creating buzz around your company. If you have trouble doing that (it’s hard), try simple things like blogging about topics that are interesting to programmers.
- Screening. Great programmers love to program and will have created lots of software that wasn’t for their jobs or school homework. Have candidates meet and (bidirectionally) interview everyone they’ll potentially be working with. If the candidate has enough free time try to do a trial project. There are also more procedural things that can be useful like code tests (although they need to be done in a respectful way and they are more about getting to know how each side thinks than actually testing whether the candidate knows how to program (hopefully you know that by this stage)).
- Convincing them to join you. This is the hardest part. Great programmers have tons of options, including cofounding their own company. The top thing you need to do is convince them what you hopefully already believe (and have been pitching investors, press etc): that your company is doing something important and impactful. The next thing you need to do is convince them that your company is one that values and takes care of employees. The best way to do this is to have a track record of treating people well and offer those past employees as references.
A few things not to do: you will never beat, say, Google on perks or job security so don’t even bother to pitch those. You’ll never beat Wall Street banks or rich big companies on cash salary so don’t pitch that either. You’ll never beat cofounding a company on the equity grant, but you can make a good case that, with the right equity grant, the risk/reward trade off of less equity with you is worth it.
Finally, I’ve long believed that early-stage, funded startups systematically under-grant equity to employees. Programmers shouldn’t have to choose between owning a fraction of a percent of an early-stage funded company and owning 50% of an unfunded company they’ve cofounded. Naval Ravikant recently wrote a great post about this:
Post-traction companies can use the old numbers – you can’t. Your first two engineers? They’re just late founders. Treat them as such. Expect as much.
Making those first engineers “late cofounders” will dramatically increase your chances of recruiting great people. This is a necessary (but not sufficient) condition for getting the recruiting flywheel spinning where great people beget more great people.
* As someone who personally programmed for 20 years including about 10 years professionally, I preferred to call myself a “programmer.” Some people prefer other words like “hacker” “developer”, “engineer” etc. I think the difference is just uninteresting nomenclature but others seem to disagree.