How do you hire a programmer if you’re not one yourself? Some things to look for…
1. How opinionated are they?
Ask them about a juicy programming topic (e.g. Ruby or Python?). The tone and reasoning of the answer will reveal a lot. In our recent podcast on programming, Jeff said, “When people have strong opinions about things — when they can talk at length about something — it’s a good indication that they’re passionate about it.”
2. How much do they contribute to open source projects?
Look at their contributions. Though you may not be a coder, you’ll be able to tell if there’s some code there. And the fact that somebody is contributing something is a good start. “The fact that somebody is contributing at all means they’re using the tool,” said Jamis. “It means they’re scratching an itch, like they ran into something that they thought should be improved, or ran into a bug and they fixed it themselves. That level of participation is a good discriminator.”
3. How much do they enjoy programming?
They don’t have to spend every second of their free time hacking, but you do want to see some level of passion. Jamis said, “It’s not so much that coding in your free time is the important thing so much as it is that you’re showing you’re passionate about it and that you have opinions.”
4. Do they actually ship?
Find out how they manage their work. Software often slips — find out how they avoid this. Find out when they shipped something on time and ask why that project was successful. Or find out lessons learned from a delayed project. “The ability to ship software is critical,” according to Jeremy. “How they manage the very task oriented part of actually needing to get something done and finished by a certain time.”
5. What have they mastered?
Randy Nelson of Pixar argues that mastery in anything is a really good predictor of mastering something else. So look for someone who’s mastered something. Is the candidate a great chef? Or mountain biker? Or something else? That’s a sign they can be a master on your project too. “That sense of I’m going to get to the top of that mountain separates them from all of the other candidates almost instantly,” says Nelson. “There’s very little chance that someone’s going to achieve mastery on the job if they didn’t get there before coming to your workplace.”
6. How well do they communicate?
The less you understand about programming, the more you’re going to rely on this person to translate what’s going on to you. That’s why hiring great writers, regardless of the position, is a good idea. For example, here’s Jeff explaining a Basecamp API update to the rest of the team inside the project site:
I just pushed an update to Basecamp’s People and Companies APIs.
We now allow client and firm employees to see people and companies that they have access to through projects. Prior to this update, firm and client employees could only see people using a specific project ID. There was no way for them to see all people (i.e., colleagues) that they are involved with across projects.
For example, if the API user making the request is on one project with Bob and another with Jill, /people.xml will return Bob and Jill. If the requesting user is an administrator, all people in the account will be returned.
The same is true for companies.
When programmers can both code and speak a language that non-programmers understand, things are a lot less likely to go wrong.
If you can, get out of all-or-nothing decision mode. Bringing on a full-time employee is a big, hairy decision. Hiring someone for a mini-project they can do in their spare time is a lot easier for both sides to swallow. “Kick the Tires” in Getting Real talks about this:
Before we hire anyone we give them a small project to chew on first. We see how they handle the project, how they communicate, how they work, etc. Working with someone as they design or code a few screens will give you a ton of insight. You’ll learn pretty quickly whether or not the right vibe is there.
Scheduling can be tough for this sort of thing but even if it’s for just 20 or 40 hours, it’s better than nothing. If it’s a good or bad fit, it will be obvious. And if not, both sides save themselves a lot of trouble and risk by testing out the situation first.
It’s also a good idea to think hard about what you’re offering and how you can make your situation as attractive as possible. The sweeter the pot, the more bees will fly into it. (Hmm, pretty sure that’s not a thing right there. Anyway…) In “Great Hackers,” Paul Graham offers a list of what attracts the best programmers: good tools, open source software, rooms with doors, an interesting problem to solve, and wise coworkers. If you’ve got any/all of those, make sure to let potential hires know.
Do it yourself?
All this stuff can help, but the absolute best way to hire a programmer is to know at least a little bit about programming. Hiring for a job you’ve never done before is really hard. So is managing that person after they’re hired. Graham discusses this in his “Great Hackers” piece:
I’ve seen occasional articles about how to manage programmers. Really there should be two articles: one about what to do if you are yourself a programmer, and one about what to do if you’re not. And the second could probably be condensed into two words: give up.
The problem is not so much the day to day management. Really good hackers are practically self-managing. The problem is, if you’re not a hacker, you can’t tell who the good hackers are.
So see if you can pick up some programming skills before hiring. (As we say in REWORK: “Never hire anyone to do a job until you’ve tried to do it yourself first.”) Jason actually began learning PHP before he partnered up with DHH. Similarly, 37signals didn’t hire a sys admin until one of us had already spent time learning how to set up servers. Go this route and you get a deeper understanding of what you’re looking for in a candidate and the problem(s) you hope to solve.
As for the mistakes you’ll make along the way, keep in mind that’s how “real” programmers work too. “Running our iterations feels like a neverending series of error recoveries,” explains Jeremy. “That sounds demoralizing, but it becomes empowering. Hell, even test-driven development is a series of error recoveries. So some advice is to work this way yourself at first.”
Related: How to hire a programmer to make your ideas happen [Derek Sivers]