{"id":919,"date":"2006-10-25T00:15:20","date_gmt":"2006-10-25T00:15:20","guid":{"rendered":"https:\/\/www.joelonsoftware.com\/?p=919"},"modified":"2016-12-05T19:34:54","modified_gmt":"2016-12-05T19:34:54","slug":"the-guerrilla-guide-to-interviewing-version-30","status":"publish","type":"post","link":"https:\/\/www.joelonsoftware.com\/2006\/10\/25\/the-guerrilla-guide-to-interviewing-version-30\/","title":{"rendered":"The Guerrilla Guide to Interviewing (version 3.0)"},"content":{"rendered":"

A motley gang of anarchists, free-love advocates, and banana-rights agitators have hijacked The Love Boat<\/em> out of Puerto Vallarta and are threatening to sink it in 7 days with all 616 passengers and 327 crew members unless their demands are met. The demand? A million dollars in small unmarked bills, and a GPL implementation of WATFIV, that is, the esteemed Waterloo Fortran IV compiler. (It\u2019s surprising how few things the free-love people can find to agree on with the banana-rights people.)<\/p>\n

\"\"As chief programmer of the Festival Cruise programming staff, you\u2019ve got to decide if you can deliver a Fortran compiler from scratch in seven days. You\u2019ve got a staff of two programmers to help you.<\/p>\n

Can you do it?<\/p>\n

\u201cWell, I suppose, it depends,\u201d you say. One of the benefits of writing this article is that I get to put words into your mouth and you can\u2019t do a darn thing about it.<\/p>\n

On what? <\/p>\n

\u201cUm, will my team be able to use UML-generating tools?\u201d<\/p>\n

Does that really matter? Three programmers, seven days, Waterloo Fortran IV. Are UML tools going to make or break it?<\/p>\n

\u201cI guess not.\u201d<\/p>\n

OK, so, what does it depend on? <\/p>\n

\u201cWill we have 19 inch monitors? And will we have access to all the Jolt we can drink?\u201d<\/p>\n

Again, does this matter? Is caffeine going to determine whether you can do it?<\/p>\n

\u201cI guess not. Oh, wait. You said I have a staff of two programmers?\u201d<\/p>\n

Right.<\/p>\n

\u201cWho are they?\u201d<\/p>\n

Does that matter?<\/p>\n

\u201cSure! If the team doesn\u2019t get along, we\u2019ll never be able to work together. And I know a few superstar programmers who could crank out a Fortran compiler by themselves<\/em> in one week, and lots<\/em> of programmers who couldn\u2019t write the code to print the startup banner if they had six months.\u201d<\/p>\n

Now we\u2019re on to something!<\/p>\n

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<\/em> about it. The very first thing you have to do right if you want to have good programmers is to hire<\/em> the right programmers, and that means you have to be able to figure out who the right programmers are<\/em>, and this is usually done in the interview process. So this chapter is all about interviewing.<\/p>\n

(The in-person interview is just one part of the hiring process, which starts with sorting resumes<\/a> and a phone screen<\/a>. This article only covers in-person interviews.)<\/p>\n

\"\"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 (that is, other programmers, not managers). You know the kind of company that just has some salty old manager interview each candidate, and that decision is the only one that matters? These companies don\u2019t have very good people working there. It\u2019s too easy to fake out one interview, especially when a non-programmer interviews a programmer. <\/p>\n

If even two of the six interviewers thinks that a person is not worth hiring, don\u2019t hire them. That means you can technically end the \u201cday\u201d of interviews after the first two if the candidate is not going to be hired, which is not a bad idea, but to avoid cruelty you may not want to tell the candidate in advance how many people will be interviewing them. I have heard of companies that allow any interviewer to reject a candidate. This strikes me as a little bit too aggressive; I would probably allow any senior person to reject a candidate but would not reject someone just because one junior person didn\u2019t like them.<\/p>\n

Don\u2019t try to interview a bunch of people at the same time. It\u2019s just not fair. Each interview should consist of one interviewer and one interviewee, in a room with a door that closes and a whiteboard. I can tell you from extensive experience that if you spend less than one hour on an interview you\u2019re not going to be able to make a decision.<\/p>\n

You\u2019re going to see three types of people in your interviews. At one end of the scale, there are the unwashed masses, lacking even the most basic skills for this job. They are easy to ferret out and eliminate, often just by asking two or three quick questions. At the other extreme you\u2019ve got your brilliant superstars who write lisp compilers for fun, in a weekend, in Assembler for the Nintendo DS. And in the middle, you have a large number of \u201cmaybes\u201d who seem like they might just be able to contribute something. The trick is telling the difference between the superstars and the maybes, because the secret is that you don\u2019t want to hire any of the maybes. Ever.<\/p>\n

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<\/em> or No Hire<\/em>. There is no other possible answer. Never<\/em> say, \u201cHire, but not for my team.\u201d This is rude and implies that the candidate is not smart enough to work with you, but maybe he\u2019s smart enough for those losers over in that other team. If you find yourself tempted to say \u201cHire, but not in my team,\u201d simply translate that mechanically to \u201cNo Hire\u201d and you\u2019ll be OK. Even if you have a candidate that would be brilliant at doing your particular task, but wouldn\u2019t be very good in another team, that\u2019s a No Hire<\/em>. 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. If for some reason you find an idiot savant that is really, really, really good at SQL but completely incapable of ever learning any other topic, No Hire<\/em>. You\u2019ll solve some short term pain in exchange for a lot of long term pain.<\/p>\n

Never<\/em> say \u201cMaybe, I can\u2019t tell.\u201d If you can\u2019t tell, that means No Hire<\/em>. It\u2019s really easier than you\u2019d think. Can\u2019t tell? Just say no! If you are on the fence, that means No Hire.<\/em> Never say, \u201cWell, Hire, I guess, but I\u2019m a little bit concerned about\u2026\u201d That\u2019s a No Hire<\/em> as well. Mechanically translate all the waffling to \u201cno\u201d and you\u2019ll be all right.<\/p>\n

\"\"Why am I so hardnosed about this? It\u2019s because it is much, much<\/em> 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\u2019s time fixing all their bugs. Firing someone you hired by mistake can take months and be nightmarishly difficult, especially if they decide to be litigious about it. In some situations it may be completely impossible to fire anyone. Bad employees demoralize the good employees. And they might be bad programmers but really nice people<\/em> or maybe they really need this job<\/em>, so you can\u2019t bear to fire them, or you can\u2019t fire them without pissing everybody off, or whatever. It\u2019s just a bad scene.<\/p>\n

On the other hand, if you reject a good candidate, I mean, I guess<\/em> in some existential sense an injustice has been done, but, hey, if they\u2019re so smart, don\u2019t worry, they\u2019ll get lots<\/em> of good job offers. Don\u2019t be afraid that you\u2019re going to reject too many people and you won\u2019t be able to find anyone to hire. During the interview, it\u2019s not your problem. Of course, it\u2019s important to seek out good candidates. But once you\u2019re actually interviewing someone, pretend that you\u2019ve got 900 more people lined up outside the door. Don\u2019t lower your standards no matter how hard it seems to find those great candidates.<\/p>\n

OK, I didn\u2019t tell you the most important part\u2014how do you know whether to hire someone?<\/p>\n

In principle, it\u2019s simple. You\u2019re looking for people who are<\/p>\n

    \n
  1. Smart, and<\/li>\n
  2. Get things done.<\/li>\n<\/ol>\n

    That\u2019s it. That\u2019s all you\u2019re looking for. Memorize that. Recite it to yourself before you go to bed every night. You don\u2019t have enough time to figure out much more in a short interview, so don\u2019t waste time trying to figure out whether the candidate might be pleasant to be stuck in an airport with, or whether they really know ATL and COM programming or if they\u2019re just faking it.<\/p>\n

    People who are Smart<\/em> but don\u2019t Get Things Done<\/em> 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, \u201cSpreadsheets are really just a special case of programming language,\u201d 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<\/em>.<\/p>\n

    People who Get Things Done<\/em> but are not Smart<\/em> 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<\/em> to the company because not only do they fail to contribute, but they soak up good people\u2019s 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\u2019ve got an AdderVistior class (yes, it\u2019s spelled wrong) and a VisitationArrangingOfficer singleton and none of your code works any more.<\/p>\n

    \"\"How do you detect smart<\/em> in an interview? The first good sign is that you don\u2019t 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 worst kind of interviewer is the blowhard. That\u2019s the kind who blabs the whole time and barely leaves the candidate time to say, \u201cyes, that\u2019s so<\/em> true, I couldn\u2019t agree with you more<\/em>.\u201d Blowhards hire everyone; they think that the candidate must be smart because \u201che thinks so much like me!\u201d<\/p>\n

    The second worst kind of interviewer is the Quiz Show Interviewer. This is the kind of person who thinks that smart means \u201cknows a lot of facts.\u201d 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: \u201cWhat\u2019s the difference between varchar and varchar2 in Oracle 8i?\u201d 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<\/em> mean \u201cknows the answer to trivia questions.\u201d Anyway, software teams want to hire people with aptitude<\/em>, 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\u2019s 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<\/em>.<\/p>\n

    But 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.<\/p>\n

    So, what do you ask?<\/p>\n

    My personal list of interview questions originates from my first job at Microsoft. There are actually hundreds of famous Microsoft interview questions. Everybody has a set of questions that they really like. You, too, will develop a particular set of questions and a personal interviewing style which helps you make the Hire\/No Hire<\/em> decision. Here are some techniques that I have used that have been successful.<\/p>\n

    Before the interview, I read over the candidates resume and jot down an interview plan on a scrap of paper. That\u2019s just a list of questions that I want to ask. Here\u2019s a typical plan for interviewing a programmer: <\/p>\n

      \n
    1. Introduction <\/li>\n
    2. Question about recent project candidate worked on <\/li>\n
    3. Easy Programming Question <\/li>\n
    4. Pointer\/Recursion Question<\/li>\n
    5. Are you satisfied? <\/li>\n
    6. Do you have any questions? <\/li>\n<\/ol>\n

      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\u2014it\u2019s 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\u2019s 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. \u201cYou\u2019re going to love<\/em> this guy,\u201d she said. Boy<\/em> did this make me mad. What I should have said was, \u201cWell, if you\u2019re so sure I\u2019m going to love him, why don\u2019t you just hire him instead of wasting my time going through this interview.\u201d But I was young and na\u00efve, so I interviewed him. When he said not-so-smart things, I thought to myself, \u201cgee, must be the exception that proves the rule.\u201d I looked at everything he said through rose-colored glasses. I wound up saying Hire<\/em> even though he was a crappy candidate. You know what? Everybody else who interviewed him said No Hire<\/em>. So: don\u2019t listen to recruiters; don\u2019t ask around about the person before you interview them; and never, ever talk to the other interviewers about the candidate until you\u2019ve both made your decisions independently. That\u2019s the scientific method.<\/p>\n

      \"\"The introduction<\/em> phase of the interview is intended to put the candidate at ease. I ask them if they had a nice flight. 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<\/em> they go about solving problems, not the actual answer.<\/p>\n

      Part two is a question about some recent project that the candidate worked on. 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. For example, sometimes I will ask, \u201cwhat class did you take last semester that you liked the most? It doesn\u2019t have to be computer-related.\u201d When interviewing experienced candidates, you can talk about their most recent assignment from their previous job.<\/p>\n

      Again, ask open-ended questions and sit back and listen, with only the occasional \u201ctell me more about that\u201d if they seem to stall.<\/p>\n

      What should you look for during the open ended questions?<\/p>\n

      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<\/em> can be just as good a sign. \u201cMy last boss wanted to do everything on VAX computers because it was all he understood. What a dope!\u201d There are far too many people around that can work on something and not really care one way or the other. It\u2019s hard to get people like this motivated about anything.<\/p>\n

      Bad candidates just don\u2019t 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. Sometimes a candidate comes in who is very nervous about being in an interview situation\u2014this is normal, of course, and I always ignore it. But then when you get them talking about Computational Monochromatic Art they will get extremely excited and lose all signs of nervousness. Good. I like passionate people who really care. (To see an example of Computational Monochromatic Art try unplugging your monitor.) You can challenge them on something (try it\u2014wait for them to say something that\u2019s probably true and say \u201cthat couldn\u2019t be true\u201d) and they will defend themselves, even if they were sweating five minutes ago, because they care so much they forget that you are going to be making Major Decisions About Their Life soon.<\/p>\n

      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\u2019t 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<\/em>) means. If they start doing this, stop them for a minute and say, \u201ccould you do me a favor, just for the sake of the exercise, could you please explain this in terms my grandmother could understand.\u201d At this point many people will still<\/em> continue to use jargon and will completely fail to make themselves understood. Gong!<\/em> You don\u2019t want to hire them, basically, because they are not smart enough to comprehend what it takes to make other people understand their ideas.<\/p>\n

      Three: If the project was a team project, look for signs that they took a leadership role. A candidate might say, \u201cWe were working on X, but the boss said Y and the client said Z.\u201d I\u2019ll ask, \u201cSo what did you<\/em> do?\u201d A good answer to this might be \u201cI got together with the other members of the team and wrote a proposal\u2026\u201d A bad answer might be, \u201cWell, there was nothing I could<\/em> do. It was an impossible situation.\u201d Remember, Smart<\/em> and Gets Things Done<\/em>. The only way you\u2019re going to be able to tell if somebody Gets Things Done<\/em> 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\u2014overcoming some institutional inertia, for example.<\/p>\n

      \"\"Most of the time in the interview, though, should be spent letting the candidate prove that they can write code.<\/p>\n

      Reassure candidates that you understand that it\u2019s hard to write code without an editor, and you will forgive them if the whiteboard gets really messy. Also you understand that it\u2019s hard to write bug-free code without a compiler, and you will take that into account.<\/p>\n

      For the first interview of the day, I\u2019ve started including a really, really easy programming problem. I had to start doing this during the dotcom boom when a lot of people who thought HTML was \u201cprogramming\u201d started showing up for interviews, and I needed a way to avoid wasting too much time with them. It\u2019s the kind of problem that any programmer working today should be able to solve in about one minute. Some examples:<\/p>\n

        \n
      1. Write a function that determines if a string starts with an upper-case letter A-Z<\/li>\n
      2. Write a function that determines the area of a circle given the radius<\/li>\n
      3. Add up all the values in an array<\/li>\n<\/ol>\n

        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<\/em> the problem, but there was a lot of variation in how long<\/em> it took them to solve.<\/p>\n

        That reminded me of why I couldn\u2019t trade bonds for a living.<\/p>\n

        Jared is a bond trader. He is always telling me about interesting deals that he did. There\u2019s this thing called an option, and there are puts, and calls, and the market steepens, so you put on steepeners, and it\u2019s all very confusing, but the weird thing is that I know what all the words mean,<\/em> I know exactly what a put is (the right, but not the responsibility, to sell something at a certain price) and in only three minutes I can figure out what should happen if you own a put and the market goes up, but I need the full<\/em> three minutes to figure it out, and when he\u2019s telling me a more complicated story, where the puts are just the first bit, there are lots of other bits to the story, I lose track very quickly, because I\u2019m lost in thought (\u201clet\u2019s see, market goes up, that mean interest rates go down<\/em>, and now, a put is the right to sell something\u2026\u201d) until he gets out the graph paper and starts walking me through it, and my eyes glazeth over and it\u2019s very sad. Even though I understand all the little bits, I can\u2019t understand them fast enough<\/em> to get the big picture.<\/p>\n

        And the same thing happens in programming. If the basic concepts aren\u2019t so easy that you don\u2019t even have to think about them, you\u2019re not going to get the big concepts.<\/p>\n

        Serge Lang, a math professor at Yale, used to give his Calculus students a fairly simple algebra problem on the first day of classes, one which almost everyone could solve, but some of them solved it as quickly as they could write<\/em> while others took a while, and Professor Lang claimed that all of the students who solved the problem as quickly as they could write would get an A in the Calculus course, and all the others wouldn\u2019t. The speed<\/em> 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.<\/p>\n

        You see, if you can\u2019t whiz through the easy<\/em> stuff at 100 m.p.h., you\u2019re never gonna get the advanced stuff.<\/p>\n

        But like I said, the good programmers stand up, write the answer on the board, sometimes adding a clever fillip (Ooh! Unicode compliant! Nice!), and it takes thirty seconds, and now I have to decide if they\u2019re really good, so I bring out the big guns: recursion and pointers.<\/p>\n

        \"\"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 (which involves holding in your head multiple levels of the call stack at the same time) or complex pointer-based algorithms (where the address of an object is sort of like an abstract representation of the object itself).<\/p>\n

        I\u2019ve come to realize that understanding pointers in C is not a skill, it\u2019s an aptitude. In first year computer science classes, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their PCs when they were 4 years old. They are having a good ol\u2019 time learning C or Pascal in college, until one day the professor introduces pointers, and suddenly, they don\u2019t get it<\/em>. They just don\u2019t understand anything any more. 90% of the class goes off and becomes Political Science majors, then they tell their friends that there weren\u2019t enough good looking members of the appropriate sex in their CompSci classes, that\u2019s why they switched. For some reason most people seem to be born without the part of the brain that understands pointers.<\/em> Pointers require a complex form of doubly-indirected thinking that some people just can\u2019t do, and it\u2019s pretty crucial to good programming. A lot of the \u201cscript jocks\u201d who started programming by copying JavaScript snippets into their web pages and went on to learn Perl never learned about pointers, and they can never quite produce code of the quality you need.<\/p>\n

        That\u2019s the source of all these famous interview questions you hear about, like \u201creversing a linked list\u201d or \u201cdetect loops in a tree structure.\u201d<\/p>\n

        Sadly, despite the fact that I think that all good programmers should be able to handle recursion and pointers, and that this is an excellent way to tell if someone is a good programmer, the truth is that these days, programming languages have almost completely made that specific art unnecessary. Whereas ten years ago it was rare for a computer science student to get through college without learning recursion and functional programming in one class and C or Pascal with data structures in another class, today it\u2019s possible in many otherwise reputable schools to coast by on Java alone<\/a>.<\/p>\n

        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\u2019s many happy programming languages. \u201cWhen was the last time you had to write a sorting algorithm?\u201d they snicker.<\/p>\n

        Still, I don\u2019t really care. I want my ER doctor to understand anatomy, even if all she has to do is put the computerized defibrillator nodes on my chest and push the big red button, and I want programmers to know programming down to the CPU level, even if Ruby on Rails does<\/em> read your mind and build a complete Web 2.0 social collaborative networking site for you with three clicks of the mouse.<\/p>\n

        \"\"Even though the format of the interview is, superficially, just a candidate writing some code on the whiteboard, my real goal here is to have a conversation about it. \u201cWhy did you do it that way?\u201d \u201cWhat are the performance characteristics of your algorithm?\u201d \u201cWhat did you forget?\u201d \u201cWhere\u2019s your bug?\u201d<\/p>\n

        That means I don\u2019t really mind giving programming problems that are too hard, as long as the candidate has some chance of starting out, and then I\u2019m happy to dole out little hints along the way, little toeholds, so to speak. I might ask someone, say, to project a triangle onto a plane, a typical graphics problem, and I don\u2019t mind helping them with the trig (SOH-CAH-TOA, baby!), and when I ask them how to speed it up, I might drop little hints about look-up tables. Notice that the kinds of hints I\u2019m happy to provide are really just answers to trivia questions\u2014the kinds of things that you find on Google.<\/p>\n

        Inevitably, you will see a bug in their function. So we come to question five from my interview plan: \u201cAre you satisfied with that code?\u201d You may want to ask, \u201cOK, so where\u2019s the bug?\u201d The quintessential Open Ended Question From Hell. All programmers make mistakes, there\u2019s nothing wrong with that, they just have to be able to find them. With string functions in C, most college kids forget to null-terminate the new string. With almost any function, they are likely to have off-by-one errors. They will forget semicolons sometimes. Their function won\u2019t work correctly on 0 length strings, or it will GPF if malloc fails\u2026 Very, very rarely, you will find a candidate that doesn\u2019t have any bugs the first time. In this case, this question is even more fun. When you say, \u201cThere\u2019s a bug in that code,\u201d 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.<\/p>\n

        As the last step in an interview, ask the candidate if they have any questions. Remember, even though you\u2019re interviewing them, the good candidates have lots of choices about where to work and they\u2019re using this day to figure out if they want to work for you.<\/p>\n

        Some interviewees try to judge if the candidate asks \u201cintelligent\u201d questions. Personally, I don\u2019t care what questions they ask; by this point I\u2019ve already made my decision. The trouble is, candidates have to see about five or six people in one day, and it\u2019s hard for them to ask five or six people different, brilliant questions, so if they don\u2019t have any questions, fine.<\/p>\n

        I always leave about five minutes at the end of the interview to sell the candidate on the company and the job. This is actually important even if you are not going to hire them.<\/em> If you\u2019ve been lucky enough to find a really good candidate, you want to do everything you can at this point to make sure that they want to come work for you. Even if they are a bad candidate, you want them to like your company and go away with a positive impression.<\/p>\n

        Ah, I just remembered that I should give you some more examples of really bad questions.<\/p>\n

        First of all, avoid the illegal questions. Anything related to race, religion, gender, national origin, age, military service eligibility, veteran status, sexual orientation, or physical handicap is illegal here in the United States. If their resume says they were in the Marines, you can\u2019t ask them, even to make pleasant conversation, if they were in Iraq. It\u2019s against the law to discriminate based on veteran status. If their resume says that they attended the Technion in Haifa, don\u2019t ask them, even conversationally, if they are Israeli, even if you\u2019re just making conversation because your wife is Israeli, or you love Felafel. It\u2019s against the law to discriminate based on national origin.<\/p>\n

        Next, avoid any questions which might make it seem like you care about, or are discriminating based on, things which you don\u2019t actually care about or discriminate based on. The best example of this I can think of is asking someone if they have kids or if they are married. This might give the impression that you think that people with kids aren\u2019t going to devote enough time to their work or that they are going to run off and take maternity leave. Basically, stick to questions which are completely relevant to the job for which they are interviewing.<\/p>\n

        Finally, avoid brain teaser questions like the one where you have to arrange 6 equal length sticks to make exactly 4 identical perfect triangles. Or anything involving pirates, marbles, and secret codes. Most of these are \u201cAha!\u201d questions\u2014the kind of question where either you know the answer or you don\u2019t. With these questions knowing the answer just means you heard that brain teaser before. So as an interviewer, you don\u2019t get any information about \u201csmart\/get things done\u201d by figuring out if they happen to make a particular mental leap.<\/p>\n

        In the past, I\u2019ve used \u201cimpossible questions,\u201d also known as \u201cback of the envelope questions.\u201d Classic examples of this are \u201cHow many piano tuners are there in Seattle?\u201d The candidate won\u2019t know the answer, but smart candidates won\u2019t give up and they\u2019ll be happy to try and estimate a reasonable number for you. Let\u2019s see, there are probably\u2026 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\u2019re attacking the problem. The only reason to ask a question like this is that it lets you have a conversation with the candidate. \u201cOK, 35 minutes, but what about travel time between pianos?\u201d<\/p>\n

        \u201cGood 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.\u201d<\/p>\n

        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 \u201cAha!\u201d pirate question usually results in the candidate just sort of staring at you for a while and then saying they\u2019re stuck.<\/p>\n

        If, at the end of the interview, you\u2019ve convinced yourself that this person is smart<\/em> and gets things done<\/em>, and four or five other interviewers agree, you probably won\u2019t go wrong in hiring them. But if you have any doubts, you\u2019re better off waiting for someone better.<\/p>\n

        The optimal time to make a decision about the candidate is about three minutes after the end of the interview. Far too many companies allow interviewers to wait days or weeks before turning in their feedback. Unfortunately, the more time that passes, the less you\u2019ll remember.<\/p>\n

        I ask interviewers to write immediate<\/em> feedback after the interview, either a \u201chire\u201d or \u201cno hire\u201d, followed by a one or two paragraph justification. It\u2019s due 15 minutes after the interview ends.<\/p>\n

        If you\u2019re having trouble deciding, there\u2019s a very simple solution. NO HIRE. Just don\u2019t hire people that you aren\u2019t sure about. This is a little nerve wracking the first few times\u2014what if we never<\/em> find someone good? That\u2019s OK. If your resume and phone-screening process is working, you\u2019ll probably have about 20% hires in the live interview. And when you find the smart, gets-things-done candidate, you\u2019ll know it.<\/em> If you\u2019re not thrilled with someone, move on.<\/p>\n

        <\/p>\n","protected":false},"excerpt":{"rendered":"

        A motley gang of anarchists, free-love advocates, and banana-rights agitators have hijacked The Love Boat out of Puerto Vallarta and are threatening to sink it in 7… Read more “The Guerrilla Guide to Interviewing (version 3.0)”<\/span><\/a><\/span><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"advanced_seo_description":"","jetpack_seo_html_title":"","jetpack_seo_noindex":false,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":true,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"jetpack_post_was_ever_published":false},"categories":[12,2],"tags":[],"class_list":["post-919","post","type-post","status-publish","format-standard","hentry","category-recruiter","category-news"],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"jetpack_shortlink":"https:\/\/wp.me\/p83KNI-eP","_links":{"self":[{"href":"https:\/\/www.joelonsoftware.com\/wp-json\/wp\/v2\/posts\/919","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.joelonsoftware.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.joelonsoftware.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.joelonsoftware.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.joelonsoftware.com\/wp-json\/wp\/v2\/comments?post=919"}],"version-history":[{"count":1,"href":"https:\/\/www.joelonsoftware.com\/wp-json\/wp\/v2\/posts\/919\/revisions"}],"predecessor-version":[{"id":3070,"href":"https:\/\/www.joelonsoftware.com\/wp-json\/wp\/v2\/posts\/919\/revisions\/3070"}],"wp:attachment":[{"href":"https:\/\/www.joelonsoftware.com\/wp-json\/wp\/v2\/media?parent=919"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.joelonsoftware.com\/wp-json\/wp\/v2\/categories?post=919"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.joelonsoftware.com\/wp-json\/wp\/v2\/tags?post=919"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}