9 ms·

Recruiting programmers to your startup

• juddlyon 15y ago
  This reference is golden: "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." Another point he addresses that rings true to me: programmer's motivation. I've made the mistake of throwing money at people when all they wanted was some more leeway to hack.
  • Timothee 15y ago
    Regarding the equity, it's interesting to see how prevalent "ideas are worthless, execution is everything" is, while, when a company hires their first engineers, they're typically not far off from being just an idea. Still, the typical equity compensation is far from reflecting that.
    • andrewflnr 15y ago
      Isn't equity just payment in advance for execution, though? It makes perfect sense to me.
• hkarthik 15y ago
  This is a great post and I agree with everything he's said. However, I know plenty of folks that are doing all these things but are still struggling to hire for the following reasons: 1) Not enough experienced local talent to attempt recruiting. 2) Not willing to train the available talent on their stack. 3) Not willing to hire remote developers to solve problems 1 and 2.
  • aaronblohowiak 15y ago
    Most businesses won't/can't effectively use remote developers.
    • JoeAltmaier 15y ago
      Explain? I've worked remotely for 20 years, and its working great. For startups, established companies, as a consulatant.
      • mjwalshe 15y ago
        true but <b>not</b>for a start up or a proper RAD/DSDM project - co located teams in the same building /room is the way to go
      • aaronblohowiak 15y ago
        That's fantastic! It is great to work remotely, but it takes a certain kind of attitude and culture to effectively leverage remote workers. My anecdotes suggest that there is a nearness bias -- "out of sight, out of mind" -- which often leads to the colocated team members to lapse in keeping remote team members abreast of decisions and changes. Purely virtual teams don't have this problem and can be extremely successful. I've also seen it work where the remote team members are given an isolated component to own.
        • JoeAltmaier 15y ago
          We currently use a collaboration tool that lets us talk spontaneously, share docs, and call out to legacy conf lines. Solves most of the nearness bias.
• kls 15y ago
  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)). I have come to the point where I respectfully decline to take tests and will generally end the interview at that point, because it tells me that the interviewer and the company has no way of knowing what constitutes a good developer. Figuring out if a developers is good is actually pretty simple, have them show you something they built and then ask them to show you the routine they are most proud of, this way you can start an organic conversation about something they know, testing only devolves into trick questions, unrealistic pressure, and testing candidates for what you think they should know, as such I start looking for the exit as soon as I see them. Not to be a jerk but, it tells me that either the company does not know how to spot talent or that they think they are elite, which tells me they will have a scalability problem in recruiting should they take off.
  • Timothee 15y ago
    You make a good point about the way a code test can change the "atmosphere" of an interview. Showing what you've built and explaining how you did it is also probably much closer to how you would collaborate if you were hired. Some might say that it would be too easy for someone to discuss code they haven't actually written, but it's also easy (as demonstrated recently on HN) to just practice common coding tests and pass. I haven't done many interviews for development jobs, so I don't know how common (if at all) it is to get "please bring with you something you've built to discuss it".
    • kls 15y ago
      I always bring my laptop with me and try to steer the interview in that direction. The first thing I do is ask them if they would like to see something that I have built and offer to walk them through the code and the architecture. If someone does this on an interview, they would be hard pressed to BS their way through an entire application. There is just a level of detail that they will go into that, someone that is faking it cannot, generally you will get storied about the code, stuff like oh yeah, this routine was a pain because in IE when you add and remove an element from the DOM it destroys it in memory. That kind of battlefield cometary shows that they lived through the code and it comes out organically when you talk to someone about something that they have been part of.
• peteretep 15y ago
  > 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. And yet a good 30-50% of all employed programmers I've met aggressively waste time, and given the opportunity to be lazy will be super super lazy. I don't think this is a trait you can pick up in an interview. So how do you deal with that if you give your programmers ultimate freedom? I guess in the US you can just fire them...
  • jbjohns 15y ago
    People tend to expand out the work to match the time. If you have people working 10 hour days expect them to move really, really slowly. I've only seen 7 hour days once or twice but I didn't see any people "taking it easy" there.
• moocow01 15y ago
  "[convince them] your company is doing something important and impactful" I would also add "not be a clone of the hot new thing run by some naive fast-talking 'business person'". There are unfortunately a lot of these being funded and working at one is usually an uninspired rat race to nowhere. Just my personal experience.
• tommyvyo 15y ago
  As someone who has worked for a startup and now working on my own, recruiting good programmers isn't hard for me, it's quite simple actually, by surrounding yourself with smart people it makes it that much easier to bring on and make relationships with smart people. The problem for me is the business/financial side of things. I have been looking for an equally passionate co-founder that can handle accounting and finance with ease, considering our MVP will have to divy up income between different accounts and what not. I wish I could find that person.
• tlogan 15y ago
  The problem is that big companies (Google, Oracle, Facebook, and others) are doing the same tricks: good engineers can work on very interesting projects, equity potential is great (10% of stock price increase will get you significant chunk of money), the best people in the field will be your co-workers, etc. On the other hand, startups will not train on job (or allow you to explore new things), will not allow working remote, etc. Plus, as per suggestion, you need to ask candidates to do 'trial projects' (which probably tells candidate that you are hiring low-level CRUD programers), you will not be able to match salary, etc. I guess the only way to recruit top-talent is present that your company is doing something important and novel - and for engineers that bar is quite high.
• akg 15y ago
  I will also reference PG's essay on Great Hackers. He explains pretty clearly what great developers want: http://www.paulgraham.com/gh.html http://www.paulgraham.com/gh.html Also, as PG mentions in the essay, it is hard to recognize great developers unless you have worked with them. Which makes Chris Dixon's point about going to meetups all the more important. Making inroads with the developer community is crucial, at the very least to get references from other talented developers.
• gruseom 15y ago
  I think the tuple <startups, programmers> may be the cutting edge of a profound social trend: the end of the employer/employee relationship. It's interesting to see posts like the OP struggle with how the traditional categories ("founder" and "employee") are no longer adequate to describe what is rapidly evolving, with neologisms like "late cofounder" popping up as attempts to address it. The catalyst is that the perceived value of good programmers is finally coming into alignment with their real value. There was a longstanding market inefficiency as people tried to apply industrial/managerial thinking to software, which doesn't work. That phase appears to be coming to an end. The collapse of the barrier to starting one's own company has helped bring this about. So has the growth of hacker culture, which holds programming in high esteem and has healthier creative values than the corporate world. Talented people no longer take for granted that their lot in life is to do boring work for employers who don't respect them. Of course, many still do - the majority, in fact - but what matters is the trend. If this is right, then we can expect many aspects of the old model (I nominate job interviews) to become anachronistic and die off. Since these are mostly painfully awkward and dumb, bring it on.
  • gruseom 15y ago
    Follow-up: my (early!) cofounder pointed out to me that "late cofounder" is an oxymoron. To "found" implies being present at the beginning, or more precisely at the bottom (as in "foundation"). The new is oxymoronic in terms of the old.
• cletus 15y ago
  One big problem I see is the disparity between the treatment of cofounders and early engineers. Late stage employees will almost certainly will almost certainly do (financially) better by working at Google or Facebook. I've seen th polls here where people talk about their exits and apart from a handful who essentially win the lottery, you'd predictably get more and work less at one of these two. But why is it the last cofounder may get 30%+ with preferential shares and the first engineer gets 1% or less shortly thereafter? It seems like an anachronism from the dot-com era when startup costs were much higher.
  • Timothee 15y ago
    It seems like an anachronism from the dot-com era when startup costs were much higher. I'm not even sure how that justified the situation then. Unless founders were to bring their own money. Do you mean that in the sense that it's now much easier for a programmer to build their own stuff, thus they might as well work for themselves rather than getting tiny equity for someone else?
    • cletus 15y ago
      Meaning the ability to raise money was a prerequisite in the dot-com era because without money you had nothing so your ability to raise money elevated you to founder. Now bootstrapping or a small amount of angel funding can go a long way so equity models (IMHO) need to evolve if startups want to attract top talent, especially considering a joB at Google could easily net you $200k+ in total comp (and far more than that for top talent) with far lower risk.
  • wisty 15y ago
    One advantage early employees get is the possibility of promotion. If the company succeeds, they have a fair chance of getting a more senior position than they would otherwise be able to get. But this is true of any fast-growing company, not just fast-growing start-ups, and there's no guarantee.
• droithomme 15y ago
  This is basically a rehash of the usual article on the topic that says the same things and is published every couple months. One twist was notable. Rather than try to compete on basic hygenic issues and market realities, the advice is to just give up: "[Y]ou 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" First, this assumes you are hiring people who are choosing between your company, Google and top Wall Street jobs. That seems unlikely. Very few people want to work on Wall Street and not that many are applying simultaneously to Google and some random company that you or I are running. Second, you absolutely can't hire top talent by not being competitive with salary, by which I mean 75th percentile or higher. The competent people are like 1% of the job pool out there and have plenty of choices. You also can't attract top talent by not offering standard benefits. You just can't. Advocating that you shouldn't bother with competitive pay or benefits is obviously poor advice. So one must ask what is going on here, why is this being advocated? We can't really know. Perhaps the author is trying to justify the low pay and poor benefits his company offers.
  • kaybe 15y ago
    The point is not that you shouldn't have them, the point is that you should not use them as the main arguments for choosing your company.
• jroseattle 15y ago
  This is great advice from Chris, and it's very much field tested. On top of this, I would add honesty -- as in direct, upfront honesty. Don't sugarcoat anything. Over-selling a company can quickly be translated as bait-and-switch once somebody joins an organization. I've used the honesty element as a recruiting tool, though. I explain where we have holes, and why persuading the candidate to join addresses those holes and moves us forward. That approach doesn't always fit with every candidate, but I view that as a positive. I save them time from considering a situation for which they're potentially not a good fit. And I save myself time in finding the right candidate that fits our profile.