Joel Spolsky recently posted an excellent series of articles about hiring software engineers. I don’t always agree with Joel’s opinions (particularly on topics like Ruby on Rails or agile development), but he definitely has a strong perspective on hiring software engineers.

Click on the headings below to get to the original articles on the Joel on Software website.

Joel convincingly argues that the great developers are never on the market, whereas the bad programmers are always looking for new jobs. So job boards (like Craigslist) and recruiters are some of the least promising methods. He describes great success with internships. As a relatively small company, we have not seriously explored this option ourselves, but Joel makes a compelling case. Another good option is to seek out qualified candidates at the places they hang out, such as conferences or virtual communities.

This is another tricky topic. After reviewing more than a handful of resumes, they all start looking the same (this seems to be especially true for resumes sent in by recruiters, who ensure that no buzzword is left out…). Joel presents some strict but fair criteria for filtering and sorting resumes based on passion, brains, communication skills (and English language skills in particular), “hard-core”-ness, diversity, selectivity, and the candidate’s desire to work for the company (as expressed in a custom cover letter). He concludes that resumes provide a very weak signal for judging candidates, but the criteria described in the article sound like an objective way of filtering and ordering potential candidates.

In this article, Joel outlines a good phone screen strategy. We always go through a phone screen before inviting a candidate for an in-person interview, but I will start incorporating some of the ideas from this article to better screen for people who are both smart and passionate and whose communication skills go beyond reciting low level technical details…

Last not least, we come to the actual in-person interview. Again, Joel presents sound advice for this stage of the hiring process. The main goal is to find people who are smart and get things done, as opposed to people who are smart but don’t get things done (such as the PhDs who prefer to mull over theoretical issues), the people who get things done but are not smart (who more often than not turn out to be a liability), and of course the people who are neither. He also stresses the importance of making a “no hire” decision if there is any doubt whatsoever, as a potentially bad developer is a much bigger liability than potentially losing out on a decent developer. I like to think that we have a high bar ourselves, and while it can sometimes be frustrating to turn down candidate after candidate (although phone screens help to filter out the obvious non-matches), I agree that it does not make sense to compromise on this.

Interestingly, Joel seems to have come around with regards to puzzle questions, even though he used to be famous for only hiring people who were able to figure out a logic puzzle involving pirates and treasure.