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.
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.
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.
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.
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.
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?
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.
Good point doing the fancy stuff is easy making it work 24/7 and do all the nasty fiddly little bits you gloss over is the hard stuff.
You want to be sure the figures add up when you do your first million pound month when the CTO (i think that Vint was his boss at the time) nudges you and says "this had better be right or we are both out of a job"
of course this was back 1983 so that is say $4,250,000 in today's money.
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 didn't code that. I just reported on it".
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.
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".
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.
I totally agree. I'm just imagining that one easy argument against that would be "well, we want to see them code, otherwise, how can we be sure?".
To this, I answer that it may be true, but coding tests are no better in that regard, because they can be gamed very easily too.
And, as you're saying, I would expect that showing and explaining what you've built would actually be much more useful and a much better proof of competence and culture 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.
You've made at least a half dozen good points in this thread. I wish you'd write a longer piece on the topic and post it. This stuff is important, and you seem to be a bit ahead of the curve (or maybe it's just that I agree with you).
I am passionate about the subject because, I used to be really bad at interviewing people. I took a lot of reflection on what I was doing wrong and to be honest some ego issues on my own part, when I was younger. When I started evaluation what I was doing wrong and what other people where doing right I started to see a common trends among those that are effective at hiring and a common trend among those that where complaining about talent. Once I started doing what the effective hiring managers where doing, I began to be able to spot true talent. I don't think I have misidentified talent since that realization, nor have I had a false positive.
I thank you for the encouragement, and I have thought about putting together an article on the subject. I think the information is valuable and could be of use to a lot of people. I will see if I can free up some time to put one together.
Thanks, I have dyslexia so that would be a great help, it is one of the reasons that I am hesitant to write articles and one of the reasons I post prolifically, writing is a challenge that I must always exercise to keep my ability to do so.
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.
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?
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.
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.
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.
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.
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.
"[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.
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.
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.
> 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...
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.
"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.
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.
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.
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.