[Links] Hire and interview programmer

This time I'm sharing my best links about hiring and interviewing programmers. There are a lot of articles on that topic, here is a fine selection of the most interesting ones.

1. Finding Great Developers


This is an article from Joel Spolsky. I'm sharing 3 links to his site today, because it is to me the best reference on that topic.

This one is about where to find great developers and where to advertise.

The great software developers, indeed, the best people in every field, are quite simply never on the market. The average great software developer will apply for, total, maybe, four jobs in their entire career.

But for the most part, great developers (and this is almost a tautology) are, uh, great, (ok, it is a tautology), and, usually, prospective employers recognize their greatness quickly, which means, basically, they get to work wherever they want, so they honestly don’t send out a lot of resumes or apply for a lot of jobs.

The corollary of that rule—the rule that the great people are never on the market—is that the bad people—the seriously unqualified—are on the market quite a lot. They get fired all the time, because they can’t do their job

Numerically, great people are pretty rare, and they’re never on the job market, while incompetent people, even though they are just as rare, apply to thousands of jobs throughout their career. So now, Sparky, back to that big pile of resumes you got off of Craigslist. Is it any surprise that most of them are people you don’t want to hire?

Think about where the people you want to hire are hanging out. What conferences do they go to? Where do they live? What organizations do they belong to? What websites do they read?

The corollary of this rule is to avoid advertising on general-purpose, large job boards.

One good way to snag the great people who are never on the job market is to get them before they even realize there is a job market: when they’re in college.

And they might, but they also have very dear friends who are not very good developers, and there are about a million land mines in this field, so the truth is I generally consider the idea of employee referrals to be one of the weakest sources of new hires.

2. Sorting Resumes


This is another article from Joel Spolsky.
This one is about screening before the interviews.

We certainly don’t hire based on resumes; we only screen out based on resumes to reduce the number of people whom we have to interview.

We look for evidence that the applicant is passionate about computers and really loves programming. Typical evidence of this: Jobs with computers or experience programming going back to a very early age. Extra-curricular activities. People who love programming often work on their own programming projects (or contribute to an open-source project) in their spare time.

We look closely at the cover letter for evidence that the applicant really wants to work for us. We don’t want to see a generic cover letter talking about me, me, me: we want to see a coherent argument as to why they’ve thought about this seriously and concluded that Fog Creek is the place they want to work. There are two reasons for using this as a clue. First, it’s a sign that the candidate is not applying to hundreds of jobs at the same time. The fact that they took the time to learn about Fog Creek and wrote a custom cover letter just for us means that they have a lot of confidence in their abilities, so they’re applying to a select few employers, not bulk mailing a thousand.

A disorganized resume rife with grammatical errors where nothing lines up is a pretty big red flag for a disorganized thinker or just general sloppiness; for many jobs this can be fine but not for software development.

For experienced programmers, there are certain technologies that are considered somewhat more hard-core than others, simply because they are, well, harder to do well. Assembler or device-driver or kernel work is somewhat more impressive than Visual Basic or PHP.

I’m looking for people who come from enough of a different background than the existing team that they are likely to bring new ideas and new ways of thinking to the team and challenge any incipient groupthink that is likely to keep us boxed into our own echo-chamber way of thinking about things. When I say different background, I mean culturally, socially, and professionally.

I’ve frequently heard the suggestion of including a programming quiz of some sort in the application procedure. This does work, in the sense that it reduces the number of applications you get, but it doesn’t work, in the sense that it doesn’t really improve the quality. Great developers have enough choices of places to work that only require the usual cover letter/resume application to get started; by inventing artificial hoops and programming tests and whatnot simply to apply, you’re just as likely to scare away good programmers as weak programmers.

Our philosophy is that we’re hiring for the long term, and any technology you happen to know right now may well be obsolete next year.

For someone who is basically a good software developer, learning another programming language is just not going to be a big deal. In two weeks they’ll be pretty productive. In two years, you may need them to do something completely different in a programming language which hasn’t even been invented.

There is, I think, one exception to this rule. If you’re hiring an architect or head developer—that is, the chief software engineer who is going to have to lay out the initial code and figure out how things work together, you probably want to hire someone with a lot of experience in the technology that you’re using.

3. The Guerrilla Guide to Interviewing


A third article from Joel Spolsky.
It is a MANDATORY reading. It is by far the BEST article on the subject. I wish I read it earlier.

Everybody gives lip service to the idea that people are the most important part of a software project, but nobody is quite sure what you can do about it. The very first thing you have to do right if you want to have good programmers is to hire the right programmers, and that means you have to be able to figure out who the right programmers are, and this is usually done in the interview process.

At the end of the interview, you must be prepared to make a sharp decision about the candidate. There are only two possible outcomes to this decision: Hire or No Hire. There is no other possible answer.

Never say “Maybe, I can’t tell.” If you can’t tell, that means No Hire. It’s really easier than you’d think. Can’t tell? Just say no!

Why am I so hardnosed about this? It’s because it is much, much better to reject a good candidate than to accept a bad candidate.

Don’t lower your standards no matter how hard it seems to find those great candidates.

You’re looking for people who are Smart, and Get Things Done.

People who are Smart but don’t Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem rather than ship on time. These kind of people can be identified because they love to point out the theoretical similarity between two widely divergent concepts. For example, they will say, “Spreadsheets are really just a special case of programming language,” and then go off for a week and write a thrilling, brilliant whitepaper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful. The other way to identify these people is that they have a tendency to show up at your office, coffee mug in hand, and try to start a long conversation about the relative merits of Java introspection vs. COM type libraries, on the day you are trying to ship a beta.

People who Get Things Done but are not Smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later. This makes them net liabilities to the company because not only do they fail to contribute, but they soak up good people’s time. They are the kind of people who decide to refactor your core algorithms to use the Visitor Pattern, which they just read about the night before, and completely misunderstood, and instead of simple loops adding up items in an array you’ve got an AdderVistior class (yes, it’s spelled wrong) and a VisitationArrangingOfficer singleton and none of your code works any more.

4. Technical Interviewing - You're Doing it Wrong!


This is a video of a public lecture of Jonathan Wanagel and Mitch Lacey.
They give the list of the common bad practice while interviewing programmers, what they call "antipatterns".

Here is the list of the antipattern, you can easily guess what they mean:

  1. The Riddler

  2. The Disorienter

  3. The Stone Tablet

  4. The Knuth Fanatic

  5. The Cram Session

  6. Groundhog Day

  7. The Gladiator

  8. Hear No Evil

5. How to Hire a Programmer


Jeff Atwood recommends to make a lot of online/phone screening and only meet a candidate if you're sure he or she can fit:

you should be 95% certain that a candidate would be a great hire before they ever set foot in an interview room.

He even recommends to give an "audition project" to the candidate:

This should be a regular consulting gig with an hourly rate, and a clearly defined project mission statement. Select a small project that can ideally be done in a few days, maybe at most a week or two. Either the candidate can come in to the office, or they can work remotely.

That's tough !
I'm not sure it's a good idea, I think it's "just as likely to scare away good programmers as weak programmers", as Joel Spolsky wrote (see above)

6. The Anatomy of the Perfect Technical Interview from a Former Amazon VP


An interview of Neil Roseman, as the ex Vice President of Amazon.
There is a lot of good things in this text, especially a lot of what is called "Behavioral Interviewing"

When it comes to soft skills and culture fit, Roseman is a big fan of one question — he asks everyone, no matter the position: Do you consider yourself lucky?

“If you look at what you’ve done, would you put yourself in the camp of people who say they’ve been lucky in their career?” Roseman explains. “I find a lot of people who will say I would have gotten that promotion but my manager cancelled my product, or they find other reasons for failure. Those are the ones who say they don’t think of themselves as lucky. I’m looking for the people who embody the phrase ‘fortune favors the prepared.’ It’s the willingness to be ready and take advantage of every opportunity that presents itself. At a startup, this is particularly valuable.”

Roseman often follows this up by asking what he calls his “three adjectives” question. Many interviewers ask candidates for their strengths and weaknesses, but Roseman puts a different spin on it. “I will ask a candidate to think of people who they worked with, professors, fellow students, managers, etc. and imagine that I am going to go to all these people and ask them for their top three adjectives to describe the candidate. Often, it causes people to think a little bit differently about themselves. They won’t just say their worst feature is working too hard.” Once a candidate shares their three adjectives, Roseman follows up and asks for examples — so if someone says, “creative,” his standard follow up will be “what are some examples of when you were creative.”