Good to see that we're making good efforts at meeting our "articles about hiring" quota on HN.
I have this theory that hiring people is nowhere near as hard as this particular echo-chamber likes to think it is. Everyone thinks they need "rockstars" or "A Players" and is looking for the magical recipe for finding them, but I think for most positions, someone who is smart and technically competent and fits with your company's culture is entirely sufficient.
Most of the startups we talk about depend on good execution of a simple idea, not advanced technical skills[1]. I believe that a good leader with the right vision and the ability to articulate that to his or her employees can take smart people who fit well with the company and form them into people who will execute consistently well. Not only that, but this creates a belief system around engineering and product that is compounding and self-reinforcing.
Identifying technically competent people is not that difficult. If you were to read a few of the last 200 articles where we've talked about this, there are some common threads.
First this, always this:
a) Have them write at least a little bit of code to see that they actually know how.
Then pick a few of these. If at all possible spread the interviews out amongst a group of people so you can get different viewpoints.
a) Ask them some relevant programming questions and observe their answers. Focus on things related to the kinds of work they'll be doing in their job. Maybe work on a whiteboard, or even in a text editor. Maybe even a little bit of both.
b) Ask them a broader set of questions relevant to things like algorithms and data structures. Even for simple web apps, it helps to be at least conversant in the basics of these topics.
c) Ask them to see open source work, or if they have a profile, or maybe some code they wrote that they're comfortable sharing with you.
I really think that if you put someone in a room with a competent engineer for an hour, that engineer will be able to tell if the person they've been speaking to is a good engineer or not.
Yes thank you. The OP does briefly mention the "looking for rock star" thing, but I get mad that every single job posting I see seems to be "OMG MUST HAVE ROCKSTAR". Or gawds, lately "OMG MUST HAVE DAN SHIPPER".
First, probably if you got an actual rock star programmer (Zed Shaw comes to mind), you probably wouldn't be able to handle/keep him.
Secondly, really? You want people that crank out Lisp transpilers in their spare time... But what about people that maybe are good with taking some oddball client spec and going back and forth to understand the desired behavior and distill something that is actually possible to implement? What about the guy who takes that extra 10% of time to implement a feature, but they end up giving you some new common code you can apply in your app?
Maybe these people don't dream Ruby DSLs, or have Github Infinity number of issues in their inbox, but they can still be valuable to a team. Because the best code in the world is useless if the programmer has misunderstood what the client is really saying.
What I always wonder is why they want "people that crank out Lisp transpilers in their spare time" (I'm reasonably close enough to that...) to come write CRUD apps in Rails.
My current day job is to write CRUD apps in Rails, but my long-term plan has me back in academia (for a PhD and a research career), where the ability to crank out a Lisp transpiler in one's spare time actually gets used.
Comments
Good to see that we're making good efforts at meeting our "articles about hiring" quota on HN.
I have this theory that hiring people is nowhere near as hard as this particular echo-chamber likes to think it is. Everyone thinks they need "rockstars" or "A Players" and is looking for the magical recipe for finding them, but I think for most positions, someone who is smart and technically competent and fits with your company's culture is entirely sufficient.
Most of the startups we talk about depend on good execution of a simple idea, not advanced technical skills[1]. I believe that a good leader with the right vision and the ability to articulate that to his or her employees can take smart people who fit well with the company and form them into people who will execute consistently well. Not only that, but this creates a belief system around engineering and product that is compounding and self-reinforcing.
Identifying technically competent people is not that difficult. If you were to read a few of the last 200 articles where we've talked about this, there are some common threads.
First this, always this: a) Have them write at least a little bit of code to see that they actually know how.
Then pick a few of these. If at all possible spread the interviews out amongst a group of people so you can get different viewpoints. a) Ask them some relevant programming questions and observe their answers. Focus on things related to the kinds of work they'll be doing in their job. Maybe work on a whiteboard, or even in a text editor. Maybe even a little bit of both. b) Ask them a broader set of questions relevant to things like algorithms and data structures. Even for simple web apps, it helps to be at least conversant in the basics of these topics. c) Ask them to see open source work, or if they have a profile, or maybe some code they wrote that they're comfortable sharing with you.
I really think that if you put someone in a room with a competent engineer for an hour, that engineer will be able to tell if the person they've been speaking to is a good engineer or not.
Yes thank you. The OP does briefly mention the "looking for rock star" thing, but I get mad that every single job posting I see seems to be "OMG MUST HAVE ROCKSTAR". Or gawds, lately "OMG MUST HAVE DAN SHIPPER".
First, probably if you got an actual rock star programmer (Zed Shaw comes to mind), you probably wouldn't be able to handle/keep him.
Secondly, really? You want people that crank out Lisp transpilers in their spare time... But what about people that maybe are good with taking some oddball client spec and going back and forth to understand the desired behavior and distill something that is actually possible to implement? What about the guy who takes that extra 10% of time to implement a feature, but they end up giving you some new common code you can apply in your app?
Maybe these people don't dream Ruby DSLs, or have Github Infinity number of issues in their inbox, but they can still be valuable to a team. Because the best code in the world is useless if the programmer has misunderstood what the client is really saying.
What I always wonder is why they want "people that crank out Lisp transpilers in their spare time" (I'm reasonably close enough to that...) to come write CRUD apps in Rails.
My current day job is to write CRUD apps in Rails, but my long-term plan has me back in academia (for a PhD and a research career), where the ability to crank out a Lisp transpiler in one's spare time actually gets used.