Live data from Hacker News

Recruiting programmers to your startup

cdixon.org

11–20 of 42 posts

Re: Recruiting programmers to your startup

#11
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.

Re: Recruiting programmers to your startup

#12
post #4

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 t…

An afternoon pairing is a much richer test than bringing pre-made work to the table, as it more accurately simulates the fit.

Re: Recruiting programmers to your startup

#13
post #3

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.

Most businesses won't/can't effectively use remote developers.

Re: Recruiting programmers to your startup

#14
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.

Re: Recruiting programmers to your startup

#15
post #3

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.

Most businesses won't/can't effectively use remote developers.

Explain? I've worked remotely for 20 years, and its working great. For startups, established companies, as a consulatant.

Re: Recruiting programmers to your startup

#16
post #4

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 t…

This is actually a really good interviewing technique. If you ask someone to talk about projects they have worked on and they don't talk your ear off then the person is probably not someone you would want to hire. Having to force a person to answer questions on projects they've worked on before is a hint that something is wrong. Many times, when this happens, their final answer is something like "Well, actually, I di…

Right you get to their passion immediately and can figure out if they are just slinging code or if they really love what they are doing. If I have to choose between passion and skill, I will chose passion every time, due to the fact that unless they are completely incompetent they can pick up skills.

Re: Recruiting programmers to your startup

#17
post #4

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 t…

An afternoon pairing is a much richer test than bringing pre-made work to the table, as it more accurately simulates the fit.

While I think paring has some value, someone is not going to be productive in an environment that they just came into, tribal knowledge such as business intelligence has not set in and there are acronyms, business realities and other common knowledge elements that this person will be just exposed to and have to deal with. Some of that information is garnered over the course of months so depending on the problem domain, a single afternoon could tell you very little about the candidate. I contend that with today's reality (2.7% tech unemployment) that it is more expensive to accidentally pass on a good developer due to bad interviewing techniques than it is to hire a bad developer. A bad developer is spotted within a week on the job, a good developer can easily be passed over in an interview, it may be a long time before another good developer comes through the door. Especially considering that good developers usually have groups of peers, that probably will not interview with a company if they pass on one a peer that they respect.

Re: Recruiting programmers to your startup

#18
I will also reference PG's essay on Great Hackers. He explains pretty clearly what great developers want: 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.

Re: Recruiting programmers to your startup

#19
I think the tuple 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.

Re: Recruiting programmers to your startup

#20
post #4

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 t…

I'm confident you're a solid coder, which is the same benefit of the doubt I give any interviewee I meet with. However, if you dismiss any opportunity that asks you to perform a test to exhibits your skills, then your process is fraught with false positives. Has it occurred to you that perhaps you might like the company/opportunity even though you're given an exam? You took the time to research the company and show up. It's too narrow at that point to give up simply b/c the interviewer wants to make sure that you truly are capable of performing the way you represent yourself on paper.

Further, figuring out if a developers is good is actually not that simple. Again, perhaps finding out that YOU'RE a good coder is pretty simple b/c hey - you're a good coder and you can articulate your work well. But what if you weren't a good coder, and only a good talker? What about those who simply don't communicate as well due to language barriers? Coding tests are important from both perspectives.

All I'm saying is that you have the right to decline any coding test you want, but you're painting too broad a stroke to determine that they're so terrible, and further you may be limiting your own opportunities.

Post reply on HN