This tutorial is based on the following book by Joel Spolsky:http://www.amazon.com/Smart-Gets-Things-Done-Technical/dp/1590598385 . Joel Spolsky is the creator of Fogbugz and Stack Overflow. He’s prolific developer, who build his career working at Microsoft on the Excel project. His book, Smart & Gets Things Done, is a small book that details the must-knows about hiring developers. Here I’ll highlight the main points.
His main point is do not settle on who you hire, and to do so you need to look through tons of developers, and send them through a rigorous interview process with technical tests and multiple interviewers. Only one interview is allowed to not like the developer. Everyone else must basically love the developer, and if there is an inkling of a doubt, as an interview you must mark the developer as a no-go.
Another key point is do not hire based on what skills the developer already has, i.e. what languages they know. They’ll be with you for a while, and will be able to learn new languages and tools quickly. Why? Because they’re smart and get things done. These two criteria points basically mean the developer can’t be someone who’s really smart but one of those developers who gets caught up in talking too much theory that he’s not proactive enough. On the other hand, he can’t be the sort of guy that gets work done, but hacks stuff in other developers later have to fix up. Joel puts it a lot more eloquently.
Joel also describes where to find these great developers. In short, guys on the job market looking for you for the most part suck and are on the job market for a reason, and the great developers must be found in their native environment, i.e. finishing school and at other jobs. This book was written 5 years ago. Now, you basically want to find guys with great blogs that talk about the technologies their adept with. Period. Don’t expect a great developer to land in your resume heap. Go grab them from where they are, and have something great to offer them. One great practical tool you can put into use is paid internships. Joel describes in depth their internship program at Fogcreek (the company that makes Fogbugz). The internship program’s main purpose--i’d say--is really to make the student love working at Fogbugz, not to suck extra work out of a younger lower paid developer. It’s an investment into the future hiring Fogbugz does. So the intern must love working at your company, which leads me to the next point.
His next main point is basically be an awesome job to have. When you’re hiring guys, fly them into your city and pay for them to stay at fancy hotels. Give them private offices with that famous $750 spinny chair. etc. Great developers have options of where to work at. Joel takes his developers seriously. He used an analogy of a story about Samurais used to protect a village. Developers are any startup’s biggest asset. So pay them well, and treat them great.
He made one final point that I thought was awesome: paying a premium for good developers is not like paying a premium for hardware parts. The reason is because once software is coded, you can sell more and more copies of it for near to nothing. Your code is your biggest asset, but itself is extremely cheap to reproduce, i.e. resell. So don’t skimp on the developers that make it. It will continue to pay for itself in ways that other harder expenditures cannot do. Basically, great developers leads to exponential gains, while the benefits provided by, say, enhanced hardware parts in a hardware startup, lead to more linear gains. A great developer can at times do the work of 10 other developers--which in sum will cost way more. Great developers also add finishing touches to the software that mediocre ones simply won’t, and these touches are what make products magical. In the day and age of beautiful interfaces and user experience, such as those seen in Apple iPhones and iPads, it’s all about those magic finishing touches that take your product over the hump to outperform your competitors.
My final piece of advice in this chapter is to keep an ongoing list of developer blogs. When you get that serious round of funding and can hire the best around, you’ll already know where to look. Categorize that list by the type of developer each developer is. Keep track of where they currently work. Keep track of their career. Learn from their blogs yourself, and post comments on their blog. Get to know them years before you hire them if you can. Build a relationship with them on Twitter. Show them that you appreciate them and value them. Bring value to their blog through comments of your own, e.g. helping its readers get the most out of their tutorials. Joel’s book was written in 2006, but if it was written now, I’m sure he’d be saying that. He’d also be saying to use Stack Overflow’s recently released tools to hire and find developers: http://careers.stackoverflow.com/employer/candidate-search . I haven’t used it yet, but my guess is it will soon be phenomenal if not already. Inevitably with that tool you’ll be able to get to know tons of developers by reading all their Stack Overflow questions and answers. You can do that already, but that tool will really help you drill down to them, rather than just find a guy here or there that’s using a technology you’re using.