The Guerrilla Guide to Interviewing by Joel Spolsky

The Guerrilla Guide to Interviewing

• 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.
• You should always try to have at least six people interview each candidate that gets hired, including at least five who would be peers of that candidate.
• It's to easy to fake out one interview, especially when a non-programmer interviews a programmer.
• If even two of the six interviewers thinks that a person is not worth hiring, don't hire them.
• Don't try to interview a bunch of people at the same time. It's just not fair.
• Each interview should consist of one interviewer and one interviewee, in a room with a door that closes and a whiteboard.
• The trick is telling the difference between the superstars and the maybes, because the secret is that you don't want to hire any of the maybes. Ever.
• 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.
• Even if you have a candidate that would be brilliant at doing your particular task, but wouldn't be very good in another team, that's a No Hire. In software, things change so often and so rapidly that you need people that can succeed at just about any programming task that you throw at them.
• Never say "Maybe, I can't tell". If you can't tell, that means No Hire. It's really easier than you'd think.
• It is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs.
• Bad employees demoralize the good employees.
• 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 the4y love to point out the theoretical similarity between two widely divergent concepts.
• 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 liabilities to the company because not only do they fail to contribute, but they soak up good people's time.
• How do you detect smart in an interview? The first good sign is that you don't have to explain things over and over again. The conversation just flow.
• There is no possible, imaginable correlation between people that know [...] trivia and people that you want to hire.
• Remember, smart does not mean "knows the answer to trivia questions."
• Software teams want to hire people with aptitude, not a particular skill set. Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it's better to hire people that are going to be able to learn any new technology rather than people who happen to know how to make JDBC talk to a MySQL database right this minute.
• In general, the way to learn the most about a person is to let them do the talking. Give them open-ended questions and problems.
• Here's a typical plan for interviewing a programmer:
• Introduction
• Question about recent project candidate worked on
• Easy Programming Question
• Pointer/Recursion Question
• Are you satisfied?
• Do you have any questions?
• I am very, very careful to avoid anything that might give me some preconceived notions about the candidate.
• Don't listen to recruiters; don't ask around about the person before you interview them; and never, ever talk to the other interviewers about the candidate until you've both made your decisions independently.
• I always reassure candidates that we are interested in how they go about solving problems, not the actual answer.
• For interviewing college kids, ask them about their senior thesis, if they had one, or about a course they took that involved a long project that they really enjoyed.
• When interviewing experienced candidates, you can talk about their most recent assignment from their previous job.
• Look for passion. Smart people are passionate about the projects they work on. They get very excited about the subject. They talk quickly, and get animated. Being passionately negative can be just as good a sign.
• Bad candidates just don't care and will not get enthusiastic at all during the interview.
• Good candidates are careful to explain things well, at whatever level.
• Look for signs that they took a leadership role.
• The only way you're going to be able to tell if somebody Gets Things Done is to see if historically they have tended to get things done in the past. IN fact, you can ask them directly to give you an example from their recent past when they took a leadership role and got something done.
• What I discovered was that everybody solved the problem, but there was a lot of variation in how long it took them to solve.
• If the basic concepts aren't so easy that you don't even have to think about them, you're not going to get the big concepts.
• You see, if you can't whiz through the easy stuff at 100 m.p.h, you're never gonna get the advanced stuff.
• 15 years of experience interviewing programmers has convinced me that the best programmers all have an easy aptitude for dealing with multiple levels of abstraction simultaneously. In programming, that means specifically that they have no problem with recursion or complex pointer-based algorithms.
• I've come to realize that understanding pointers in C is not a skill, it's an aptitude.
• For some reason most people seem to be born without the part of the brain that understands pointers. Pointers require a complex form of doubly-indirect thinking that some people just can't do, and it's pretty crucial to good programming.
• A lot of programmers that you might interview these days are apt to consider recursion, pointers, and even data structures to be a silly implementation detail which has been abstracted away by today's many happy programming languages.
• I don't really mind giving programming problems that are too hard, as long as the candidate has some chance of starting out, and then I'm happy to dole out little hints along the way, little toeholds, so to speak.
• All programmer's make mistakes, there's nothing wrong with that, they just have to be able to find them.
• Remember, even though you're interviewing them, the good candidates have lots of choices about where to work and they're using this day to figure out if they want to work for you.
• Stick to questions which are completely relevant to the job for which they are interviewing.
• Avoid brain teaser questions.
• A good back-of-the-envelope question allows you to have a conversation with the candidate what helps you form an opinion about whether they are smart.
• If, at the end of the interview, you've convinced yourself that this person is smart and gets things done, and four or five other interviewers agree, you probably won't go wrong in hiring them. But if you have any doubts, you're better off waiting for someone better.
• The optimal time to make a decision about the candidate is about three minutes after the end of the interview.
• I ask interviewers to write immediate feedback after the interview, either a "hire" or "no hire", followed by a one or two paragraph justification. It's due 15 minutes after the interview ends.
• If you're having trouble deciding, there's a very simple solution. NO HIRE. Just don't hire people that you aren't sure about.