
Recruiting programmers to your startup - revorad
http://cdixon.org/2011/12/29/recruiting-programmers-to-your-startup/
======
gruseom
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
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.

------
kls
_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.

~~~
greenEggsNHam
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.

~~~
kls
_then your process is fraught with false positives_

I contend that if you test me you will get a false negative. Becase you are
testing me on what you think I should know which is a reflection of your
strengths not mine.

 _Has it occurred to you that perhaps you might like the company/opportunity
even though you're given an exam?_

Yes it has, the problem is that I now belive that they don't know how to hire
and I will be working with a group of people that know trivia but may not know
how to deliver. As such it will fall on me to deliver becase their hiring
process has not shown an ephisis on selecting people that can deliver.

 _the interviewer wants to make sure that you truly are capable of performing
the way you represent yourself on paper._

I feel that, my and others capibilities are best reflected in what I have
already done. We don't ask a other professionals to take test we look at their
history and accomplishments.

 _But what if you weren't a good coder, and only a good talker?_

A good talker can BS someone with no knowledge of the field. They are not
going to be able to BS their way through an entire code base. A skilled
technical person will catch on.

I don't think companies that do test are terrible I just think their interview
process is lacking as such it can leave me holding the bag with long hours
becase they cannot identify other good talent. It's from experience that I
have come to the conclusion that hireing via test is a useless filter, because
at one point in time I was the worst offender. I used to use elite code trick
questions, abstract questions and code tests and I found not only where they
ineffective but I was actually driving the best individuals away, due to what
they perceived as arrogance on the part of my orginizarion. Developers have
little tolarance for things that seem inefficient and pointless. It took me a
while to learn that lesson.

~~~
jwegan
_They are not going to be able to BS their way through an entire code base._

The problem is that a large number of coders out there simply do not have a
project they can show an interviewer. This can be for a number of reasons such
as only programming at work or not having much free time. The fact a coder has
a project to walk someone through does not imply they are a good coder, so why
would a company tailor their interview process to the minority of interview
candidates out there who do have a sizable project they can demo?

~~~
kls
When I sign up with a company I always get the stipulation that I can use the
code for demonstration purposes, that the code will never leave my machine but
that I can use it for demonstration purposes. Short of working on some top
secret project I would not agree to anything else, not being able to show
previous work in this industry is like an artist not being able to show
commercial work as their portfolio.

 _The fact a coder has a project to walk someone through does not imply they
are a good coder_

No but it is an indication of their work, because it is sitting right there in
front of you. Just because they have a project does not mean that it is good,
but that is up to the interviewer to decide. If you can look at the code base,
then the interviewer should be able to determine if it is well built or not.
If they cannot, then I would question whether they should be the one
conducting the interview.

 _so why would a company tailor their interview process to the minority of
interview candidates out there who do have a sizable project they can demo_

I personally feel that someone looking for a senior developer role should have
something that they can demo, they have been in the business for 5 to 10
years, there should be something that they can run on their machine to
demonstrate their abilities. Now for a junior developer, I agree they may not
have something to demo, but for a junior role I assume a blank slate and look
for totally different values. Specifically I look for passion and eagerness to
learn, again a test is not going to tell me that.

------
cletus
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
_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
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.

------
droithomme
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
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.

------
tlogan
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.

------
jroseattle
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.

------
moocow01
"[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.

------
hkarthik
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
Most businesses won't/can't effectively use remote developers.

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

~~~
aaronblohowiak
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
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.

------
peteretep
> 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
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.

------
juddlyon
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
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
Isn't equity just payment in advance for execution, though? It makes perfect
sense to me.

------
akg
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.

