[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
http://www.joelonsoftware.com/articles/FindingGreatDevelopers.html
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
http://www.joelonsoftware.com/articles/SortingResumes.html
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
http://www.joelonsoftware.com/articles/GuerrillaInterviewing3.html
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!
http://channel9.msdn.com/Events/ALM-Summit/ALM-Summit-3/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:
- The Riddler
- The Disorienter
- The Stone Tablet
- The Knuth Fanatic
- The Cram Session
- Groundhog Day
- The Gladiator
- Hear No Evil
5. How to Hire a Programmer
http://www.codinghorror.com/blog/2012/03/how-to-hire-a-programmer.html
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
http://firstround.com/article/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.ÔÇØ