The Guerrilla Guide to Interviewing (version 3.0) - Joel on Software

22 Oct 09

Vincent Chan

It’s because it is much, much better to reject a good candidate than to accept a bad candidate.
- Smart, and
- Get things done.
13 more annotations...
- They would rather mull over something academic about a problem rather than ship on time.
- 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
- 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.
- So an important part of the interview is creating a situation where someone can show you how smart they are.
- Remember, smart does not mean “knows the answer to trivia questions.”
- 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.
- Introduction
  Question about recent project candidate worked on
  Easy Programming Question
  Pointer/Recursion Question
  Are you satisfied?
  Do you have any questions?
- Boy did this make me mad. What I should have said was, “Well, if you’re so sure I’m going to love him, why don’t you just hire him instead of wasting my time going through this interview.”
- 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. That’s the scientific method.
- I spend about 30 seconds telling the person who I am and how the interview will work. I always reassure candidates that we are interested in how they go about solving problems, not the actual answer.
- tell me more about that
- A really good sign that a candidate is passionate about something is that when they are talking about it, they will forget for a moment that they are in an interview.
- . Good. I like passionate people who really care.

07 Jul 09

Jason Venema

Interviewing

11 May 09

Qasim Rasheed

@today

28 Apr 09

Melvin Xie

Programming

23 Mar 09

Frank Sanders

Work PM To Read

14 Feb 09

maddie highsmith

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.
10 more annotations...
- 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 flows. Often, the candidate says something that shows real insight, or brains, or mental acuity. So an important part of the interview is creating a situation where someone can show you how smart they are.
- The second worst kind of interviewer is the Quiz Show Interviewer. This is the kind of person who thinks that smart means “knows a lot of facts.” They just ask a bunch of trivia questions about programming and give points for correct answers. Just for fun, here is the worst interview question on Earth: “What’s the difference between varchar and varchar2 in Oracle 8i?” This is a terrible question. There is no possible, imaginable correlation between people that know that particular piece of trivia and people that you want to hire. Who cares what the difference is? You can find out online in about fifteen seconds! Remember, smart does not mean “knows the answer to trivia questions.” Anyway, 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.
- 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. If you think that someone is smart before they even walk into the room, just because they have a Ph.D. from MIT, then nothing they can say in one hour is going to overcome that initial prejudice. If you think they are a bozo because they went to community college, nothing they can say will overcome that initial impression. An interview is like a very, very delicate scale—it’s very hard to judge someone based on a one hour interview and it may seem like a very close call. But if you know a little bit about the candidate beforehand, it’s like a big weight on one side of the scale, and the interview is useless. Once, right before an interview, a recruiter came into my office. “You’re going to love this guy,” she said. Boy did this make me mad. What I should have said was, “Well, if you’re so sure I’m going to love him, why don’t you just hire him instead of wasting my time going through this interview.” But I was young and naïve, so I interviewed him. When he said not-so-smart things, I thought to myself, “gee, must be the exception that proves the rule.” I looked at everything he said through rose-colored glasses. I wound up saying Hire even though he was a crappy candidate. You know what? Everybody else who interviewed him said No Hire. So: 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. That’s the scientific method.
- What should you look for during the open ended questions?
  
  One: Look for passion. Smart people are passionate about the projects they work on. They get very excited talking about the subject. They talk quickly, and get animated. Being passionately negative can be just as good a sign. “My last boss wanted to do everything on VAX computers because it was all he understood. What a dope!” There are far too many people around that can work on something and not really care one way or the other. It’s hard to get people like this motivated about anything.
  
  Bad candidates just don’t care and will not get enthusiastic at all during the interview. A really good sign that a candidate is passionate about something is that when they are talking about it, they will forget for a moment that they are in an interview.
- Two: Good candidates are careful to explain things well, at whatever level. I have rejected candidates because when they talked about their previous project, they couldn’t explain it in terms that a normal person could understand. Often CS majors will just assume that everyone knows what Bates Theorem is or what O(log n) means. If they start doing this, stop them for a minute and say, “could you do me a favor, just for the sake of the exercise, could you please explain this in terms my grandmother could understand.”
- Three: If the project was a team project, look for signs that they took a leadership role. A candidate might say, “We were working on X, but the boss said Y and the client said Z.” I’ll ask, “So what did you do?” A good answer to this might be “I got together with the other members of the team and wrote a proposal…” A bad answer might be, “Well, there was nothing I could do. It was an impossible situation.” Remember, Smart and Gets Things Done. 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 even ask them directly to give you an example from their recent past when they took a leadership role and got something done—overcoming some institutional inertia, for example.
  
  Most of the time in the interview, though, should be spent letting the candidate prove that they can write code.
  
  Reassure candidates that you understand that it’s hard to write code without an editor, and you will forgive them if the whiteboard gets really messy. Also you understand that it’s hard to write bug-free code without a compiler, and you will take that into account.
  
  For the first interview of the day, I’ve started including a really, really easy programming problem
- had to start doing this during the dotcom boom when a lot of people who thought HTML was “programming” started showing up for interviews, and I needed a way to avoid wasting too much time with them. It’s the kind of problem that any programmer working today should be able to solve in about one minute. Some examples:
  
  Write a function that determines if a string starts with an upper-case letter A-Z
  Write a function that determines the area of a circle given the radius
  Add up all the values in an array
  
  These softball questions seem too easy, so when I first started asking them, I had to admit that I really expected everyone to sail right through them. What I discovered was that everybody solved the problem, but there was a lot of variation in how long it took them to solve.
- I always leave about five minutes at the end of the interview to sell the candidate on the company and the job.
- n the past, I’ve used “impossible questions,” also known as “back of the envelope questions.” Classic examples of this are “How many piano tuners are there in Seattle?” The candidate won’t know the answer, but smart candidates won’t give up and they’ll be happy to try and estimate a reasonable number for you. Let’s see, there are probably… what, a million people in Seattle? And maybe 1% of them have pianos? And a piano needs to be tuned every couple of years? And it takes 35 minutes to tune one? All wrong, of course, but at least they’re attacking the problem. The only reason to ask a question like this is that it lets you have a conversation with the candidate. “OK, 35 minutes, but what about travel time between pianos?”
  
  “Good point. If the piano tuner could take reservations well in advance they could probably set up their schedule to minimize travel time. You know, do all the pianos in Redmond on Monday rather than going back and forth across 520 three times a day.”
  
  A good back-of-the-envelope question allows you to have a conversation with the candidate that helps you form an opinion about whether they are smart. A bad “Aha!” pirate question usually results in the candidate just sort of staring at you for a while and then saying they’re stuck.
  
  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.

04 Feb 09

Vladislav Pervushin

interview hiring recruiting development career howto programming

02 Jan 09

Howard Keziah

interview hiring recruiting interviewing

28 Aug 08

jaykaysee

JOB

01 Aug 08

Grant C

hiring

27 Jun 08

emelar

interviewing

19 Jun 08

hg ye

Smart, and get things done.

joel interviewing recruiting interview hiring career jobs

07 May 08

Joe Murphy

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. So this chapter is all about interviewing.

28 Mar 08

mindfulness

Interview

Remember, smart does not mean â€œknows the answer to trivia questions.â€ Anyway, 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.

24 Mar 08

business career development hiring import interview jobs recruiting

11 Mar 08

davide g.

Remember, smart does not mean “knows the answer to trivia questions.” Anyway, 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
The speed with which they solved a simple algebra problem was as good a predictor of the final grade in Calculus as a whole semester of homework, tests, midterms, and a final.

10 Mar 08

Francisco Javier Alcala-Soler

27 Feb 08

pablo88

del.icio.us imported interview jobs toread

26 Feb 08

Jerry Wong

关于面试的文章

interview

02 Oct 07

Ryan Done

how interview. to

24 Sep 07

terry_ebdon

del.icio.us hiring imported interview

02 Sep 07

Marcello Morsello

interview hiring programming

03 Mar 07

Craig Preston

Joel interview howto startup

09 Feb 07

W.W. Webster

Joel on Software; Joel Spolsky

work techbiz bestpractices

31 Jan 07

Jean-Michel G

article interview jobs

14 Dec 06

Jab

interviewing work:

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.
Smart, but not useful.
8 more annotations...
- This is the kind of person who thinks that smart means “knows a lot of facts.”
- 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.
- Two: Good candidates are careful to explain things well, at whatever level.
- In the past, I’ve used “impossible questions,” also known as “back of the envelope questions.” Classic examples of this are “How many piano tuners are there in Seattle?” The candidate won’t know the answer, but smart candidates won’t give up and they’ll be happy to try and estimate a reasonable number for you. Let’s see, there are probably… what, a million people in Seattle? And maybe 1% of them have pianos? And a piano needs to be tuned every couple of years? And it takes 35 minutes to tune one? All wrong, of course, but at least they’re attacking the problem. The only reason to ask a question like this is that it lets you have a conversation with the candidate. “OK, 35 minutes, but what about travel time between pianos?”
- Very, very rarely, you will find a candidate that doesn’t have any bugs the first time. In this case, this question is even more fun. When you say, “There’s a bug in that code,” they will review their code carefully, and then you get to see if they can be diplomatic yet firm in asserting that the code is perfect.
- Smart and Gets Things Done.
- they are not smart enough to comprehend what it takes to make other people understand their ideas.
- One: Look for passion.

30 Nov 06

Michael Guy

business career culture development hiring imported:del.icio.us interesting interview jobs programming recruiting reference social tips

27 Nov 06

Santhosh

imported:del.icio.us interview tips

24 Nov 06

Todd Sayre

development imported:del.icio.us interview job

03 Nov 06

Karim A. Nassar

interviewing

31 Oct 06

Jochen Lillich

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.

interview business career @toread

28 Oct 06