Recruiting programmers to your startup
cdixon.org
Recruiting programmers to your startup
1–10 of 42 posts
Re: Recruiting programmers to your startup
#2This 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.
Re: Recruiting programmers to your startup
#3This 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.
Re: Recruiting programmers to your startup
#4If 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.
Re: Recruiting programmers to your startup
#5If 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…
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".
Re: Recruiting programmers to your startup
#6This 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.
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.
Re: Recruiting programmers to your startup
#7If 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…
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 p…
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.
Re: Recruiting programmers to your startup
#8Earlier quoted context omitted.
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 p…
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…
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.
Re: Recruiting programmers to your startup
#9"[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.
Re: Recruiting programmers to your startup
#10If 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 didn't code that. I just reported on it".