Chris Dixon

Recruiting programmers to your startup

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.

  • http://www.feld.com bfeld

    Fantastic post Chris. I just forwarded to the Foundry Group CEO list.

    • http://www.cdixon.org chris dixon

      Thanks Brad! Would love to hear their feedback.

      • http://www.feld.com bfeld

        Putting up a post on http://www.feld.com tomorrow morning with some additional thoughts this stimulated.

  • http://andybrett.com Andy Brett

    Think you mean “they want enough to *not* spend time worrying about money”

  • http://twitter.com/L1AD LIAD

    I’ve also found top rate developers hate joining a team if there is existing ‘technical debt’ and they wont be allowed to scrap it and start over.

    We were discussing it coincidentally this morning. A developer raised Paypal as an example. They adhere to your 4 points but from the state of their API’s etc, developers gauge it being a clusterfuck and are thus hesitant to have anything to do with it, let alone work there.

    • http://www.cdixon.org chris dixon

      Yeah, I guess I had put that under “interesting projects” (a necessary condition) but you are right it probably warrants its own discussion.

    • http://twitter.com/scottschulthess Scott Schulthess

      I think, a lot of the time, developers just want to write something themselves.  I’d write apps pretty differently a year ago from now, and I want to use those skills without dealing with an existing hard to move project

      • Anonymous

         There’s a balance to be struck.  “Programmers” get tarred with “meh – programmers just want to rewrite everything from scratch all the time!”.  I’ve been guilty of that myself, but not 100% of the time.  If I’m being tasked with being responsible for something, having to take over something with no tests, no/bad/wrong docs, horrible architecture, security holes, performance issues and a bug list a mile long isn’t very attractive.  To then be told “you can’t change anything, just keep adding crap to it”… well… there’s almost no amount of money that any company would be willing to pay that would make me take that role. 

        But… it’s not solely from an ego standpoint – there’s really business value at the heart of it, and if I can’t deliver good value to the business, I don’t want to work on it.  There have been times when I’ve sucked it up and just maintained old code in the interest of “best interest of the business”, but it’s not often that it really was/is in anyone’s best interest – you *usually* just end up 6-12 months later with worse code and less able to react to the needs of the business to stay competitive.

    • FAKE GRIMLOCK

      NO ONE WANT TO WORK AT COMPANY THAT IGNORE TECHNICAL DEBT.

      THAT INCLUDE PEOPLE WORKING THERE.

    • James Mitchell

      There is no such thing as a system of any complexity that does not have technical debt. The only question is how much does it have. Any developer who thinks otherwise is a very inexperienced developer.

      In the real world, it it often dangerous to just throw code away and start over, as Joel Spolsky explained at:

      http://www.joelonsoftware.com/articles/fog0000000069.html 

      So the issue is, does management understand what technical debt means? Is there a plan to reduce (not eliminate) it? While developers are refactoring and rearchitecting the current system, does management understand that for X months it will appear as if no progress has been made?

  • http://motochan.com/ James Chan

    The hardest part is the “convincing” phase. A-list players go for A-list ideas, potential, development environments, etc. The mix/priority differs from individual to individual.

    There’s probably also a correlation between co-founder geekiness and ease of talent attraction. You need to speak their language and understand their “pain” in order to gain their trust, respect and employment.

  • http://www.meeps.com Mat Ranauro

    Great post.

    One point I’d like to emphasize based on experience is pair programming post initial screening. It is so valuable. 

    You learn more about a potential team member by coding together and solving real problems than a test would ever reveal. The recruit also gets a great sense of the team, environment, code base and what they’d be getting into. 

    • http://giffconstable.com giffc

      I’ve watched this be a really effective interview technique at Pivotal Labs — as you note, it shows off personality, not just skills.

  • http://twitter.com/nimrodpriell Nimrod Priell

    Fantastic post. Runner ups I would say are: 

    * They want to have control over the technical domain just like you as a founder has control over the business and product domain. So even if you’re a great experienced programmer you have to give them leeway to experiment and introduce new tools and direct the technology. 

    * They want to know what’s going on with the business. Telling them for 6 months that everything is great and you’re about to close a round and showing up one day and saying you’re pivoting and bootstrapping is disconcerting, unless it’s completely honest and they feel that.

    • http://www.cdixon.org chris dixon

      Great points, especially the second one. I try to have as many “business meetings” in the open as possible. Unfortunately sometimes you can’t but in general I think business people can do a lot more of it and developers appreciate it.

  • Anonymous

    Great post!

  • Anonymous

    If they’re your first 2 programmers: LET THEM SELECT THE STACK once they join.

    The opportunity to choose the stack you think is best is rare, and programmers will flock to it.

    • http://www.cdixon.org chris dixon

      yes although I think there is some danger in developers wanting to pick bleeding edge stuff. I’d say pick the stack but within the constraints that they are mainstream enough that you can recruit a big team that is familiar with that stack.

      • Anonymous

        The *really* good ones will put that constraint in themselves, unprompted. 

        • http://www.cdixon.org chris dixon

          true.

  • http://twitter.com/#!/georgelbowen George Lucas Bowen

    Great post Chris.  Showing up is critical, and be nice.  Expect to start a conversation, not hire someone on the spot.

  • http://reecepacheco.com reecepacheco

    really stellar for sure, but i’m curious at what point the equity grants change from “late cofounder” status to something else?

    • http://www.cdixon.org chris dixon

      super rough rule of thumb- after you have maybe 2-3 great technical people…

      • http://reecepacheco.com reecepacheco

        sounds right. glad we’re on the right track

  • http://dancroak.com Croaky

    Great points. Agreed all around.

    A big step before qualifying and closing candidates is sourcing and attracting them. Lot of ideas on this New York City Ruby thread:

    http://www.meetup.com/NYC-rb/messages/28106962/

  • http://boumanblog.com/ Jesse Bouman

    As a non-technical person (but currently teaching myself) are there any quick points on how to identify a good programmer from a great one? 

    • http://insomanic.me.uk/ AndyY

      great programmers do it because they love it. so they do it all the time. so they have loads more experience. so they’re great.

      to find great programmers, look for enthusiasm for building things and a bulging portfolio of projects – on github etc. as chris said, great programmers will have built things outside of they jobs or study assignments.

      • http://boumanblog.com/ Jesse Bouman

        Thanks! That makes a lot of sense. 

      • http://giffconstable.com giffc

        I agree that you want to see this enthusiasm, but would just flag that a portfolio of building things does not in itself tell you whether someone can work with a team or think about CS in a sophisticated manner.

        The only two ways I think you can tell a good from great is to have a great programmer interview your candidates, and possibly to pair program for the interview (even if your team doesn’t do it on a regular basis) 

      • FAKE GRIMLOCK

        GREAT PROGRAMMER LOVE TO PROGRAM, HAS DONE LOTS OF THINGS.

        SAME TRUE FOR TERRIBLE DELUSIONAL PROGRAMMER.

        CHECK TO SEE IF ALL THEM THINGS THEY BUILD:

        1. WORK
        2. WERE SUCCESSFUL
        3. SHOW UP IN GOOGLE UNDER “AWESOME, DO LIKE THIS”, NOT “OMG, IT’S FULL OF BUGS”. 

  • http://www.rescuetime.com Anonymous

    The most powerful motivator (which you didn’t mention) is working on a product that you like/want to exist in the world.  Justin Kan had a great post on this a while back where he talked about the amazing change in candidate flow when they switched from being a general video platform for broadcasting pro-gaming ( http://techcrunch.com/2011/10/31/trouble-hiring-create-a-cult/ ).  You obviously can’t change your product/market if it’s not cool– but you can focus on seeking candidates who love your market.  Travel startup?  Find programmers who love to travel.  Photosharing startup?  Find hackers who love photography. (etc)

    • http://www.cdixon.org chris dixon

      yes, great point I should have included.

    • http://twitter.com/EdwardARandolph Eddie Randolph

      Hopefully, this is why someone started the business in the first place: “working on a product that you like/want to exist in the world” & this is where “like-minds” meet.

  • Anonymous

    Also be open about the cool projects and problems you are solving. Most great startups are using blogs to do this. http://Www.nerdblo.gs has a good directory of startups doing this.

  • http://reecepacheco.com reecepacheco

    the other element i find is helpful is the opportunity to learn. this applies to more than just programmers, but in my experience programmers especially love to learn new technology, methods etc

    • http://www.cdixon.org chris dixon

      Yes, that’s a huge area I forgot to put in the post. Career development, learning etc.

      • http://twitter.com/aortenzi Anthony Ortenzi

        I think this is where the DevOps culture comes in.  Responsibility for how your code operates encourages evolution to elegant solutions, and creating elegant solutions requires the kind of problem analysis which lead to finding the “best tool for the job”, which is always a great learning experience.

      • http://www.conorneill.com Conor

        But does career development really exist outside of the individual?  Nobody can manage your career for you.  You choose excellence and self-motivation or you choose to work for an insurance sales company.

    • http://giffconstable.com giffc

      Totally agree, and +1 to Chris’ post in general.

    • FAKE GRIMLOCK

      “US DOING AWESOME NEW THING, WANT US TO PAY YOU TO LEARN IT?” IS GOOD RECRUITMENT PITCH.

      • http://reecepacheco.com reecepacheco

        yup.. we didn’t know everything we need to when we started (and still don’t!), so we’re big on learning on the job

  • Anonymous

    I take issue with the fact that many non-technical founders only want to work on “their” ideas. And most of these posts seem to speak specific to that need i.e. helpful tips on how to *earn* a technical founder on whatever idea the non-technical person has.

    I’ll acknowledge that this post maybe isn’t necessarily geared towards non-technical folks only but it certainly does have that air about it in the writing. That said, no one ever seems to want to add a paragraph about non-technical guys joining a technical guy on their idea or going out of their way to seek a technical cofounder by joining someone else rather than always pushing your idea in everyone else’s’ face.

    It is also worth noting here that most non-technical guys (and some technical too) focus too much on pitching their idea and not enough on themselves i.e. who they are, what value prop they bring to the table, etc.. Any that do, focus on crap ego rubbing achievements that no one cares about and that do not add weight to the startup itself. 

    • http://www.cdixon.org chris dixon

      I don’t know why you assume I’m assuming the founders are non-technical. This post was triggered primarily by conversations I had with technical founders looking to hire more technical people. I consider me and my cofounders of my last 2 companies technical and we faced these challenges.

      • Anonymous

        As I wrote in my post…

        “I’ll acknowledge that this post maybe isn’t necessarily geared towards non-technical folks only but it certainly does have that air about it in the writing.”

        It isn’t very clear or obvious, at least to me, that this was targeted towards technical founders looking to recruit. It doesn’t help that often times, many of these posts are in fact written in response to non-technical founders looking to recruit a technical founder. 

        I didn’t mean to assume or judge. Merely pointing out that it wasn’t very obvious and my gripes with the reasons for recruiting. My two bullet points…

        1. That people should be open to joining others for their ideas, and
        2. That people should focus on pitching themselves and what they bring to the table beyond just the idea…

        applies to technical founders as well.

        • http://www.cdixon.org chris dixon

          I agree with both of your points.

  • http://doriandargan.com Dorian Dargan

    This is awesome… thanks Chris.

    Noah Weiss of foursquare directed me here, he adds that being “somewhat technical yourself” will also help.

    I agree… which is why I’m learning to program myself: doriandargan.wordpress.com/2011/11/24/why-i-am-learning-to-program/

  • Anonymous

    If you get your first few hires right, you can cultivate a virtuous cycle.  Top talent will only refer people of the same calibre, and their presence will validate to their peers that it is a good place to be.

    • Anonymous

      I agree with Ted – articulate a company value prop to attract the top talent, they will refer and only want to work with other top talent. 

  • http://insomanic.me.uk/ AndyY

    Great post, chris. I wrote a related post recently about finding technical cofounders for the non-technical - http://www.kernelmag.com/scene/2011/12/desperately-seeking-sysadmins/ (url not my choice..!)

    A key part of persuading programmers to join you is to have nailed – not just your vision of what you want to build – but also a sensible MVP/iterative plan backed up by customer development-style evidence.Programmers as a breed are more inclined to scepticism (I speak only for myself, naturally!) and this will help you convince them your plan is meaningful and that you won’t expect the impossible only for their efforts to be wasted.

  • http://www.facebook.com/profile.php?id=1501982 Heliodor Jalba

    What I’ve noticed from previous jobs is that creating a friendly environment for developers is hard. Start with the facts that 1) most of the developers aren’t exactly very social, 2) some developers have a strong right-vs-wrong mentality (which is why they love computers to begin with) and love expressing it, and 3) some people make negative comments about other people’s code or express their right-vs-wrong viewpoint of other people’s work.

    Here’s how the group dynamics usually play out:
    1) People express their judgement calls.
    2) It quickly becomes obvious people are judging you.
    3) You fear bringing up any nonprogramming-related conversation because you don’t want to be judged. This is compounded by everyone’s limited social skills.
    4) You shut up and just do your work.
    5) You finally end up having a boring group of people who are afraid to be social with each other. They discuss the only safe thing to discuss: the latest programming-related concept or blog post.

    • FAKE GRIMLOCK

      HIRE GREAT PROGRAMMERS. ALSO HIRE PEOPLE WITH GREAT SOCIAL SKILLS TO MAKE PROGRAMMERS TEAM.

  • Anonymous

    Funny that you mention the part about creativity. This point is particulalry interesting because a really good programmer is usually not someone who fixes a lot of bugs but who is able to create new code with minimal mistakes. In addition to that, business people can also be investors (ie VCs) who I have personally seen going down that route. I know many entrepreneurs who start to prefer investors who have been in a programming role to understand their problems and lifestyle than those coming from consulting or banking. Too bad still too many VCs still love to recruit people from these industries and then go on and advise portfolios on strategic issues.
    I find that a big problem.

  • http://www.gplus.to/arkadiuszdymalski Arkadiusz Dymalski

    That’s really nice introduction to the unexpectedly (for most people) hard topic of recruitment. Big + for Chris for emphasis on networking aspect of search. And there are already amazing comments below, which extend the topic even further. Let me add some more.

    In the screening phase it’s beneficial to assess broad spectrum of competences. And I’m not talking only about considering technical vs interpersonal vs general capacities. The other important dimension is time – how our expectations towards employee will (probably) evolve in the future. Instead of focusing on current project/tasks only, it’s valuable to take into consideration at least tactical perspective (growth, possible pivots etc.) of our company and additional requirements coming as a consequences of these changes. Sometimes such perspective can strongly change the recruitment decisions.

    During ‘convincing’ phase it’s also important that you are not only ‘selling’ your company/idea/product to the candidate but first of all … yourself: as a boss, teammate, employer etc. That requires additional set of skills which founder should develop to be effective as recruiter.

  • http://www.hypedsound.com jonathanjaeger

    It also helps if you have a product that the developer uses even before they consider working for you (this is probably true for companies like Reddit, StackOverflow, 37Signals or other companies that don’t even require a ‘pitch’ to win them over because they already are fans of the community or product).

  • Anonymous

    Awesome post!
    What do you think of recruiting freelance programmer (which is imho faster) first instead of finding permanently employed programmer?

  • http://twitter.com/deepbane Vanessa Ramos

    Awesome… thanks for this post!
    I totally agree with the motivation points, specially with one: Great developers love great technical challenges :)

  • Pingback: On Recruiting Programmers to Your Startup

  • http://www.Spidvid.com Jeremy Campbell

    Those 4 “care about” elements are key to keep in mind for business founders when recruiting tech co-founders, thanks for sharing this Chris! 

  • Pingback: More On Recruiting Programmers To Your Startup

  • http://twitter.com/rowemore Rowe Morehouse

    Great article. 

    I would add that while you are in the “showing up” and “finding” phase it’s beneficial to aggregate potential candidates in a CRM tool — like SugarCRM, Zoho, Salesforce, etc. 

    Approach your developer search as a “sales effort.”

    Even add people you’ve met who you think are good, although they may be currently employed elsewhere. Devs switch around — you never know when they may open up to take on new projects. 

    Take a look at who’s in your “pipeline,” even if just from a risk management / fallback perspective (the devs you hire may leave, or may not work out, what’s your backup?) 

    Keeping in touch with your prospects with an infrequent call or email, and keeping a record of your touchpoints in CRM will assist your staffing effort. 

  • http://twitter.com/cauloccoli Jen Fen

    Hi Chris, thanks for posting this, I love your advice. I think what you DIDN’T say is almost as important as what you did.

    You make no mention of “coding ninjas” , foosball tables, free beer, or pissing-contest tryouts … familiar characteristics of many startup hiring pitches that tend to turn away a sizable chunk of the population (women, minorities, etc.) Thank you for identifying 4 recommendations that are truly merit-based and transcend bias.

  • http://anilkappa.me/ Anil

    Great post Chris. 

    Ted awesome observation on the
    first few hires. it is easier said than done. It almost decides your fate of
    your startup. You get this wrong and losses will spiral uncontrollably. In Most successful companies you will notice most
    of the early hires scaled along with company’s growth, leave alone being
    instrumental. It is no coincidence.

    I would like to add key point to all the wonderful insights
    already posted, be very cognizant about “Hiring for Potential” versus
    “Hiring for Skill”.

    Most programmers thrive and excel in an environment that
    1) Challenges their IQ.
    2) Provide constant learning.
    3) Systems for Recognition.
    4) Can openly call someone a “A..h..” or “Jerk” if they are being
    one no matter what their status in the company and not feel threatened.
    5) Creative space and freedom.

    • http://www.conorneill.com Conor

      Political correctness is insulation for mediocrity.

  • http://forcecarrier.wordpress.com/ Ramesh Nethi

    Great post. Not a line that i donot agree with.  I wrote a similar post an year back on the importance of understanding what motivates a programmer to join startup and how a startup should be prepared to address them

    http://forcecarrier.wordpress.com/2010/12/14/hiring-talent-into-startups/ 
    “Screening” is very important part of this process.  As you rightly point out, one needs to do this in a balanced & respectful way.  One that worked out well in selecting great programmers is to actually have them write the code as part of the interview. When you are going through hundreds of profiles, it helps if you automate this process.  Having gone through the same process when I joined my first startup, I always adopted this approach in all my subsequent startups when I was hiring people. And it always worked. 

    1) Find dozen or so interesting problems.  Make sure these are not text book examples:-) Keep in mind that you are judging a candidate in couple of hours of time. So you need to pick the problems in such a way that it is challenging enough (for him to sit through and code it up) but not very difficult or needs some complex algorithms to be mugged up.

    2)Automate the process.  This is interesting. Idea is to provide an environment where the candidate can write code, compile it, execute it and verify if the program is correct or not.  All done in a way that masks out the intricate details of GUI configurations, command line switches of the environment.   Our environment even had a way to snapshot the code different points and see if he is comfortable thinking/working through the problem  in “bottom-up” or “top-down” approach.

    Not only this saves you the time of validating the program manually  but it also gives an opportunity to test his code for all boundary conditions and other space & time trade-off constraints.  You will be surprised to see how people can come up with interesting and different solutions for the same constraints – a very important characteristic that you would need to know abou the candidate.

  • Rob Yoegel

    Great information here. Thanks for posting. We just published some information on the same topic, taking the approach of what engineers should be doing. Check out our infographic on the topic: http://monetate.com/2011/12/infographic-a-programmers-guide-to-getting-hired-by-a-startup/

  • http://fadi.el-eter.com Fadi El-Eter

    HI Chris,

    I think so far the best place to find good programmers is by talking to university teachers. Top students are eager to work in a challenging environment, and won’t mind the salaries that a startup will pay them.

  • Anonymous

    Developer compensation is always tough — how do you what’s enough? I learned early on that the rule is that pay should be within + or – 10% of the local market rate because it is super tough to jump for such a small increase. Thoughts?

  • Pingback: The Founders’ Library | Startup Dispatch

  • Pingback: The Perpetually Vexing Problem of Hiring Programmers | Extranet Factoring

  • Pingback: The Perpetually Vexing Problem of Hiring Programmers

  • Pingback: The Perpetually Vexing Problem of Hiring Programmers | Sulvo

  • Pingback: Hiring Great Programmers: 3 Essential Rules to Follow | Sulvo

  • Pingback: Will You Build or Buy Your Business?

  • Pingback: Will You Build or Buy Your Business? | NSD Newsletter

  • Pingback: Will You Build or Buy Your Business? - Omnia Veritas Blog

  • Pingback: Hiring Great Programmers: 3 Essential Rules to Follow | Biz Op Radar

  • http://twitter.com/CarbonUnity CarbonUnity

    VERY good post [and comments!].  We are at a stage where we urgently need a Technical Co-Founder and it has not been easy finding someone (mainly due to limited cash resources like most start-ups…).

    This post helps a lot!  Thank you.

    If anyone is interested, please contact us : ) http://www.carbonunity.com

  • http://realityinteractive.wordpress.com/ Jetty

    You’ve made some very good points here. As a start up, that’s recruiting, this was very timely. Thanks!

  • raznick

    Good stuff here. We will use some of these tips as we recruit top engineers in Michigan at benzinga.

  • Pingback: StartupDigest | The best information about the tech startup world

  • Pingback: Will You Build or Buy Your Business? | Free Web Design Tucson

  • Pingback: Will You Build or Buy Your Business? | Start Fund NL