Programmer search engine

For as long as I’ve been in the industry, which is, I think, about 74 years now, the problem I’ve had with hiring programmers was not interviewing them or deciding if they’re smart—it’s been finding them in the first place.

What I’ve dreamed about is a programmer search engine.

The ideal programmer search engine would only include programmers who are actually looking for jobs. If you’ve ever emailed someone based on a resume you found through a traditional search engine, you’ve probably discovered that they’re not actually on the market.

It would only include people willing to work in your neck of the woods.

It would show you CVs right away, and, ideally, it would show you something about their programming skills besides the usual resume blahblah.

Well, OK, that day is here, and I’m like a kid in a candy store. Nom nom. Announcing the other half of the employer’s side!

Right now, there are about 928 candidates on there. That’s a start. What’s more interesting is whether there’s a candidate who meets your needs.

Let’s say you’re searching for a full time Java programmer within 40 miles of Palo Alto. Right now there are 11 candidates listed. All but one are active on StackOverflow… one even has reputation over 4000 points.

Want a bit more choice? Check the box that indicates that you’re willing to relocate. Now there are 80 matches, all of whom have the legal right to work in the states. Candidates have a lot of flexibility indicating where they’re willing to work. Even if you need a Ruby on Rails programmer in Oklahoma City, as long as you’re willing to pay for relocation, you’ve got 7 choices. You’ve got 14 choices in London (with the legal right to work.) If you think that a Python programmer could learn Ruby, you’ve got 51 choices. There are plenty of choices whether you’re hiring in Tel Aviv, Sydney, Silicon Valley, or New York. There are four programmers in Copenhagen right now. No relocation required. All of them highly qualified, actually; any one of them would qualify to interview at Fog Creek.

Stack Overflow Careers is something of a chicken-and-egg business. We have to get a big audience of programmers and a big audience of employers all at the same time, and then it’s like a junior high school dance, with the boys on one side of the gym and the girls on the other side, and for a while you just sit there holding your breath to see if anyone will dance. We invited a few hundred employers as beta testers… these were the companies that have been listing jobs on StackOverflow over the last six months, and so far, they’ve found a few dozen candidates that they liked. Once it gets to that point, we’re out of the loop, so we don’t really know how many people are actually finding jobs, but please email me your success stories and failure stories so we can keep working to make it better.

In the meantime, Jeff and the StackOverflow crew have done something brilliant: they’ve made it possible to do searches and see how many candidates match even before you have to pay. So if you want to try it out but are afraid that there aren’t students looking for OCaml internships in Houston, you can try it, and find that there is, indeed, one. So, try it out right now. There’s no obligation, and we’re happy to give you your money back if you don’t think you got good value.

The Guerrilla Guide to Interviewing (version 3.0)

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 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’s surprising how few things the free-love people can find to agree on with the banana-rights people.)

As chief programmer of the Festival Cruise programming staff, you’ve got to decide if you can deliver a Fortran compiler from scratch in seven days. You’ve got a staff of two programmers to help you.

Can you do it?

“Well, I suppose, it depends,” you say. One of the benefits of writing this article is that I get to put words into your mouth and you can’t do a darn thing about it.

On what?

“Um, will my team be able to use UML-generating tools?”

Does that really matter? Three programmers, seven days, Waterloo Fortran IV. Are UML tools going to make or break it?

“I guess not.”

OK, so, what does it depend on?

“Will we have 19 inch monitors? And will we have access to all the Jolt we can drink?”

Again, does this matter? Is caffeine going to determine whether you can do it?

“I guess not. Oh, wait. You said I have a staff of two programmers?”


“Who are they?”

Does that matter?

“Sure! If the team doesn’t get along, we’ll never be able to work together. And I know a few superstar programmers who could crank out a Fortran compiler by themselves in one week, and lots of programmers who couldn’t write the code to print the startup banner if they had six months.”

Now we’re on to something!

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.

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

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’t have very good people working there. It’s too 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. That means you can technically end the “day” 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’t like 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. I can tell you from extensive experience that if you spend less than one hour on an interview you’re not going to be able to make a decision.

You’re 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’ve 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 “maybes” 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’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. Never say, “Hire, but not for my team.” This is rude and implies that the candidate is not smart enough to work with you, but maybe he’s smart enough for those losers over in that other team. If you find yourself tempted to say “Hire, but not in my team,” simply translate that mechanically to “No Hire” and you’ll be OK. 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. 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. You’ll solve some short term pain in exchange for a lot of long term pain.

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! If you are on the fence, that means No Hire. Never say, “Well, Hire, I guess, but I’m a little bit concerned about…” That’s a No Hire as well. Mechanically translate all the waffling to “no” and you’ll be all right.

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. A bad candidate will cost a lot of money and effort and waste other people’s 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 or maybe they really need this job, so you can’t bear to fire them, or you can’t fire them without pissing everybody off, or whatever. It’s just a bad scene.

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

OK, I didn’t tell you the most important part—how do you know whether to hire someone?

In principle, it’s simple. You’re looking for people who are

  1. Smart, and
  2. Get things done.

That’s it. That’s all you’re looking for. Memorize that. Recite it to yourself before you go to bed every night. You don’t have enough time to figure out much more in a short interview, so don’t 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’re just faking it.

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.

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 worst kind of interviewer is the blowhard. That’s the kind who blabs the whole time and barely leaves the candidate time to say, “yes, that’s so true, I couldn’t agree with you more.” Blowhards hire everyone; they think that the candidate must be smart because “he thinks so much like me!”

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.

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.

So, what do you ask?

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 decision. Here are some techniques that I have used that have been successful.

Before the interview, I read over the candidates resume and jot down an interview plan on a scrap of paper. That’s just a list of questions that I want to ask. Here’s a typical plan for interviewing a programmer:

  1. Introduction
  2. Question about recent project candidate worked on
  3. Easy Programming Question
  4. Pointer/Recursion Question
  5. Are you satisfied?
  6. 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.

The introduction 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 they go about solving problems, not the actual answer.

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, “what class did you take last semester that you liked the most? It doesn’t have to be computer-related.” When interviewing experienced candidates, you can talk about their most recent assignment from their previous job.

Again, ask open-ended questions and sit back and listen, with only the occasional “tell me more about that” if they seem to stall.

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. Sometimes a candidate comes in who is very nervous about being in an interview situation—this 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—wait for them to say something that’s probably true and say “that couldn’t be true”) 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.

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.” At this point many people will still continue to use jargon and will completely fail to make themselves understood. Gong! You don’t want to hire them, basically, because they are not smart enough to comprehend what it takes to make other people understand their ideas.

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. I 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:

  1. Write a function that determines if a string starts with an upper-case letter A-Z
  2. Write a function that determines the area of a circle given the radius
  3. 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.

That reminded me of why I couldn’t trade bonds for a living.

Jared is a bond trader. He is always telling me about interesting deals that he did. There’s this thing called an option, and there are puts, and calls, and the market steepens, so you put on steepeners, and it’s all very confusing, but the weird thing is that I know what all the words mean, 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 three minutes to figure it out, and when he’s 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’m lost in thought (“let’s see, market goes up, that mean interest rates go down, and now, a put is the right to sell something…”) until he gets out the graph paper and starts walking me through it, and my eyes glazeth over and it’s very sad. Even though I understand all the little bits, I can’t understand them fast enough to get the big picture.

And the same thing happens in programming. 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.

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 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’t. 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.

You see, if you can’t whiz through the easy stuff at 100 m.p.h., you’re never gonna get the advanced stuff.

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’re really good, so I bring out the big guns: recursion and pointers.

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).

I’ve come to realize that understanding pointers in C is not a skill, it’s 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’ time learning C or Pascal in college, until one day the professor introduces pointers, and suddenly, they don’t get it. They just don’t understand anything any more. 90% of the class goes off and becomes Political Science majors, then they tell their friends that there weren’t enough good looking members of the appropriate sex in their CompSci classes, that’s why they switched. 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-indirected thinking that some people just can’t do, and it’s pretty crucial to good programming. A lot of the “script jocks” 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.

That’s the source of all these famous interview questions you hear about, like “reversing a linked list” or “detect loops in a tree structure.”

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’s possible in many otherwise reputable schools to coast by on Java alone.

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. “When was the last time you had to write a sorting algorithm?” they snicker.

Still, I don’t 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 read your mind and build a complete Web 2.0 social collaborative networking site for you with three clicks of the mouse.

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. “Why did you do it that way?” “What are the performance characteristics of your algorithm?” “What did you forget?” “Where’s your bug?”

That means 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. I might ask someone, say, to project a triangle onto a plane, a typical graphics problem, and I don’t 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’m happy to provide are really just answers to trivia questions—the kinds of things that you find on Google.

Inevitably, you will see a bug in their function. So we come to question five from my interview plan: “Are you satisfied with that code?” You may want to ask, “OK, so where’s the bug?” The quintessential Open Ended Question From Hell. All programmers make mistakes, there’s 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’t work correctly on 0 length strings, or it will GPF if malloc fails… 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.

As the last step in an interview, ask the candidate if they have any questions. 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.

Some interviewees try to judge if the candidate asks “intelligent” questions. Personally, I don’t care what questions they ask; by this point I’ve already made my decision. The trouble is, candidates have to see about five or six people in one day, and it’s hard for them to ask five or six people different, brilliant questions, so if they don’t have any questions, fine.

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. If you’ve 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.

Ah, I just remembered that I should give you some more examples of really bad questions.

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’t ask them, even to make pleasant conversation, if they were in Iraq. It’s against the law to discriminate based on veteran status. If their resume says that they attended the Technion in Haifa, don’t ask them, even conversationally, if they are Israeli, even if you’re just making conversation because your wife is Israeli, or you love Felafel. It’s against the law to discriminate based on national origin.

Next, avoid any questions which might make it seem like you care about, or are discriminating based on, things which you don’t 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’t 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.

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 “Aha!” questions—the kind of question where either you know the answer or you don’t. With these questions knowing the answer just means you heard that brain teaser before. So as an interviewer, you don’t get any information about “smart/get things done” by figuring out if they happen to make a particular mental leap.

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?”

“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.

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’ll remember.

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. This is a little nerve wracking the first few times—what if we never find someone good? That’s OK. If your resume and phone-screening process is working, you’ll probably have about 20% hires in the live interview. And when you find the smart, gets-things-done candidate, you’ll know it. If you’re not thrilled with someone, move on.

The Phone Screen

It happens all the time: we get a resume that everyone thinks is really exciting. Terrific grades. All kinds of powerful-sounding jobs. Lots of experience. Speaks seventeen languages. And saved over 10,000 kittens!

Look! kittens!

And then I call them up, and I can’t stand talking to them. Within ten minutes, I realize they are not going to make it as programmers. I’ve had people with great resumes tell me a pointer should fit in one byte. Sometimes they just can’t answer the simplest questions, or you feel like you have to wrestle the answers out of them.

Before moving on to a full-fledged in-person interview, we usually use a phone screen to make sure that we’re not wasting time and money on someone who is just seriously not smart.

A phone screen has distinct advantages over a normal in-person interview. First, it’s cheap. It takes 45 minutes to an hour and actually does eliminate about half of the people who looked really, really good on paper.

More importantly, it’s more fair.

With a phone interview, because you can’t see the person, it’s easier to focus on the quality of what they’re saying rather than other external factors not relevant to their job, like their appearance, or their nervousness. Ever since Malcolm Gladwell wrote Blink, I’ve been terrified of the prospect that we might be judging candidates too quickly based on things which are not relevant to their ability to do their job—their appearance or confidence or height or general nerdy demeanor might make us way more apt to look on everything else that happens during the interview with rose-colored glasses.

The great thing about a phone interview is that it’s much harder to form these kinds of snap judgments; you actually have to listen to what the person is saying and decide if that corresponds to what a smart person might say. This isn’t completely true, of course: you may have prejudices about certain accents or dialects. But at least you are moderately less susceptible to appearance prejudice.

My phone interviews have three parts. In the first part, I ask the candidate to describe their career history and basically tell me about themselves. This is mainly intended to get them loosened up and feeling comfortable, to eliminate any nervousness, and to let them sort of present themselves the way they want to be presented. During this stage, you should be looking for evidence that the candidate is a problem solver: the kind of person who gets things done. You’re also looking for passion. You want people who care about the stuff that they did.

During this part I’ll drill down on two kinds of things: technology and politics.

Technology. If someone tells me that they implemented such-and-such a project, I’ll ask detailed questions about the technology they used and how they used it. I’ll also ask specifically what role they played. Sole developer? Developer on a team? I’ll tend to go into these questions in great detail, because this is where you uncover the people who either didn’t know what they were doing, or have made things up, or have exaggerated their own roles. If someone’s resume implies that they spent two years coding in Python, for example, I’m going to drill down until I’m pretty confident that it sounds like they really have two years of Python experience.

Don’t hesitate to use trick questions. I might say, “I hate Python, because it’s really tedious to declare all your variables. That’s why I like C better.” Python doesn’t make you declare variables (and C does). Don’t be afraid that the candidate will feel pressured to agree with your false assertion. Smart programmers have a certain affinity for the truth, and they’ll call you on it. As Dave Winer says, “You can’t lie to a compiler.” If they’re really good, they’ll find a way to be diplomatic about it. But they’re going to be passionate enough that they’ll almost forget that they’re in an interview. That’s a good sign.

Politics. Behind the boring list of past employers on the resume, there’s always a story. What I’m looking for is the story of how the candidate handled challenges in the past. I’m looking for people that got things done, even in the face of opposition. I’m looking for people who challenged the status quo, who overcame objections, and who made things happen. So when the resume says, “drove the adoption of .NET,” I want to hear what drove means. In detail. When the resume says that they “founded a company,” I want to hear everything. Whose idea was it? Who convinced whom? Who did what? Did it work out? Why not?

The second part of the phone screen is the technical problem. I usually ask the same question for years and years before switching it, because this makes it easier to compare candidates. The question is a wide-ranging, open design question: how would you design a data structure or a block of code to do x? Where x is something kind of big and complicated. I usually have a series of questions ready to guide the candidate down a particular path in the design of this data structure or block of code, because it’s such a big question, and I can often tell how smart the candidate is by how far they get down that path in a fixed amount of time.

Here are some ideas to get you started:

  • How might you design a program that lets people play Monopoly with each other over the internet?
  • What would be a good data structure for a photo editor?
  • How would you implement code to operate the elevators in a high rise?
  • How would you implement the rendering engine of a web browser?

The ideal question takes something where the interviewee is deeply familiar with how the thing works from having used it, but is unlikely to have ever implemented it themselves. You want something that can be done over the phone, without too much writing, so “how would you write the code for quicksort” is a bad question, because we don’t expect programmers to be able to recite code over the phone. You want to have a conversation about algorithms and data structures, really, the meat and potatoes of programming, where the goal is not to find the best possible answer, necessarily, but simply to give you the opportunity to talk about code, to talk about time/space tradeoffs, to talk about performance characteristics of code, all of which will add up to giving you a pretty good idea in your mind whether the person you’re talking to is actually pretty good at programming and whether they’re smart or not. If you find yourself explaining everything three times, either you’re terrible at explaining things, or you’re talking to someone who is not that smart.

The bottom line in my interviewing technique is that smart people can generally tell if they’re talking to other smart people by having a conversation with them on a difficult or highly technical subject, and the interview question is really just a pretext to have a conversation on a difficult subject so that the interviewer’s judgment can form an opinion on whether this is a smart person or not.

The third and final part of the interview is letting the candidate interview me. Remember, the whole philosophy of recruiting is predicated on the idea that smart candidates have a choice of where to work, and if that’s true, the interview process is as much a way for the candidate to decide if they want to work for us as it is a way for us to decide if we want to hire the candidate. “Do you have any questions about Fog Creek, about working at Fog Creek, or anything else you want to ask me?”

Sometimes this part of the interview reveals a frightening lack of preparation by the candidate. “So, what exactly does Fog Creek do? And where are you located?” Failing to do even the most basic homework before the interview, by spending five minutes on our web site, does not give me a great deal of confidence in the candidate’s ability to be smart or to get things done.

By this point I’ve already decided if this person seems smart enough to score an in-person interview. So I treat the third part of the phone interview as if I were the one being interviewed, and the candidate was the one that had to be sold on Fog Creek. Which they do.

Passing a phone screen is never enough to get hired. It’s nothing more than a simple filter designed to save time and expense on in-person interviews, and to eliminate candidates who will never make it before you’ve flown them all the way across the country and put them up in a fancy hotel. Still, even with the phone screen, probably only about one in three candidates makes it all the way through the in-person interview.

Sorting Resumes

The standard job application of cover letter plus resume is a phenomenally weak way to introduce a candidate. They give you only the faintest clues as to the quality of an applicant.

Sometimes, though, a resume gives pretty strong negative clues which allow you to screen out applicants without going much further. Once I got a resume from someone who claimed to be an expert in Microsoft Window [sic] programming. Another time the only experience listed on the application was a job at Dunkin’ Donuts. That resume did a pretty good job of following all the suggestions that high school career-guidance advisors love to give out (this guy “managed trays of donuts”) but there was not a smidgen of evidence that the applicant had ever seen a computer.

Other than that, though, it can be extremely hard to tell much about a candidate from a resume. Our policy at Fog Creek, then, has three parts:

  1. We try to be selective about how we advertise our jobs, so as to limit the amount of noise in the resume pile.
  2. 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.
  3. In order to sort the remaining resumes to decide what order to interview people, we use a strictly objective system of reviewing and scoring them, so at least we are being fair and consistent in our interpretation of that very weak signal that comes from resumes.

There are several fairly objective measures that we look at, again, solely for the purpose of sorting resumes so that the first people we call are the ones that are most likely to work out.

Passion. 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. Great programmers are more likely to have spent a summer at computer camp, or building an online appointment scheduler for their uncle the dentist, rather than working at Banana Republic folding clothes.

  • 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.

  • Waxing rhapsodic in their cover letter about how they were moved to tears by The Structure and Interpretation of Computer Programs.

  • Sometimes certain programming languages or technologies on a resume indicate evidence of someone who loves programming enough to explore new technologies. At the time I’m writing this, seeing Ruby on a resume is a good sign of the kind of programmer who loves to check out the latest thing and try to improve their skills because they’re passionate about programming, because not so many employers are really demanding Ruby yet. You have to be careful here; in 1996 Java on a resume was a sign of the same passion, but today it adds almost no information.

Pickiness. 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 bulk-mailed resume can be a symptom of desperation. More importantly, a custom cover letter is a sign that if we do make this candidate an offer, they’re likely to accept it. That improves our yield. If I only have time to interview six people, all else being equal, I’d rather interview six people who really want to work for Fog Creek, not generic smart people that are also applying to a hundred other jobs. All else being equal.

English. Scoring resumes by English skills was a hard decision for us to make, because computer programming is one of those fields where an immigrant who doesn’t speak English can still be a brilliant programmer. That said, years of experience working with programmers have taught me that programmers who can communicate their ideas clearly are going to be far, far more effective than programmers who can only really communicate well with the compiler. It is crucial for documenting code, it is crucial for writing specifications and technical design documents that other people can review, and it’s crucial even for those meetings where you sit around discussing how to do something best: brilliant programmers who have trouble explaining their ideas just can’t make as much of a contribution. In this particular category, we also consider the neatness and orderliness of their resume. 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. In particular we usually completely disqualify resumes that are full of English mistakes. It’s not that hard, even for a non-native speaker, to find someone to check your resume, and failure to do that usually reflects a profound lack of concern over the quality of the things that you do. That said, we try to be considerate of non-native speakers who are nonetheless excellent communicators: leaving out articles in that charming Eastern European way, or starting every paragraph with “So” in charming Pacific Northwestian way, is not a showstopper.

Brains. In this category we’re looking for evidence that a candidate is, well, smart, or at least, the kind of nerdy brainiac that went to math camp. Signs of this include high GPAs, high standardized test scores, honors societies like Phi Beta Kappa, people who participate in Top Coder competitions, play competitive chess, or go to ACM Programming contests.

Selectivity. Another thing we look for on resumes is evidence that someone has gone through some highly selective process in the past. Not everyone at Ivy League schools is worth hiring, and not everyone at community college is worth avoiding, but getting into a very selective school does at least mean that someone, somewhere judged you using some kind of selection process and decided that you were pretty smart. Our company criterion for selectivity is usually getting into a school or program that accepts less than 30% of its applicants (there are about 60 schools in the US that meet this standard), or working for a company which is known to have a difficult application process, like a whole day of interviews. Highly selective branches of the military like officer’s training or pilot’s courses, or even just getting into the Marines indicates someone that has made it through some kind of difficult application/selection procedure and all in all this is a positive sign.

Hard-core. 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. Again, this is a pretty weak indicator, but all else being equal, I’m more impressed by someone who has done work in OCaml than someone who has worked in Java. Assembler or device-driver or kernel work is somewhat more impressive than Visual Basic or PHP. C++ with ATL is harder than Perl. People who have worked on operating systems or compilers are more hard core than people who have worked on simple database front-ends.

I’m sure that this will be seen as incendiary; after all, most of my personal programming experience in the past five years is with VBScript, which is sort of like a version of Visual Basic dumbed down for people with severe brain trauma. Remember again that I said that resumes are a very weak way of judging programmers and you only get the faintest signals from them; that said, some technologies are just harder than other technologies and if you happened to have worked with them successfully, there’s a smidgen more evidence that you might be the right person to hire, so for the purpose of sorting resumes, difficult technologies tend to float you to the top, while claiming competence in, say, Microsoft Word tends to float you toward the bottom.

Diversity. Before I start a massive flame war of international scope by using the loaded term “diversity,” let me carefully define what I mean by this. Specifically, 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. Someone who has a lot of experience with enterprise software may bring useful diversity to a team of internet programmers. Someone who grew up poor is going to bring useful diversity to a startup full of Andover preppies. A stay-at-home mom rejoining the workplace may bring useful diversity to a team of recent graduates. An electrical engineer with Assembler experience may bring useful diversity to a team of Lisp hackers. A recent college graduate from Estonia may bring useful diversity to a team of experienced management consultants from the midwest. The only theory here is that the more diverse your team is, the more likely that someone on the team will have some experience in their background that allows them to come up with a different solution.

It is really really important to remember that these categories—Passion, Pickiness, English, Brains, Selectivity, Hard-Core, and Diversity—are not hiring criteria. They are just too weak for that. There are way too many excellent people who would score low on this test or poor programmers who would score high. Before you go off ranting about how Joel only thinks you should hire from the Ivy League, or that I have some kind of GPA fetish, or whatnot, it’s important to understand that this list is just not a list of reasons to hire someone or reject someone. All it is is an objective and fair way to sort a big pile of resumes to find the candidates who are most likely to work out so that you can interview them first, and then decide if they’re worth hiring.

If resumes are so weak, can’t we add some other hoops?

This is certainly not, by any stretch of the imagination, the ideal set of rules for sorting resumes. I’d much rather be able to sort resumes by the candidate’s ability to implement a recursive algorithm, how long it takes them to find a bug in code, or whether or not they can keep nine items in short term memory, all of which are better indicators of success as programmers than things like whether you got past an elite college’s admissions committee. Unfortunately, those things aren’t on resumes.

One temptation of recruiters is to try and add a few extra hoops to the application process. 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. Indeed, you may be more likely to scare away the best programmers, who have the most alternatives, and get left with a pool of fairly desperate candidates who are willing to do extra work to apply simply because they don’t have any alternatives.

Don’t look for experience with particular technologies

Once I was on a panel at NYU giving students advice on careers in I.T. My advice, excerpted from this article, was that before graduating you should make sure to learn how to write well, maybe by taking a creative writing course, and take a class in Econ so that the business side of the business isn’t a mystery. I also recommended at least one low-level programming course in C or Assembler just to help you understand how computers work at a lower level.

On the panel with me was a nice chap from a local headhunter, in fact, one of the better tech recruiters in the city. His speech consisted of 15 minutes of tedious alphabet soup. “We’re seeing a lot of XML, some C++, SOAP and WSDL are getting hot but you’re not seeing as much COM or even ATL.” And on, and on, until my eyes were spinning. This was a fellow who entirely thought of the world in terms of keywords on resumes.

To top programmers, the most maddening thing about recruiters is their almost morbid fascination with keywords and buzzwords. The entire industry of professional headhunters and recruiters is bizarrely fixated on the simple algorithm of matching candidates to positions by looking for candidates that have the complete list of technology acronyms that the employer happens to be looking for. It becomes especially infuriating to realize that most of these recruiters have no idea what any of these technologies are. “Oh, you don’t have MSMQ experience? Never mind.” At least when real estate agents prattle on about Subzero refrigerators and Viking stoves, they at least know what these things are (although any stainless steel refrigerator counts as “Subzero” these days). The easiest way to catch-out a technical recruiter is when they inevitably insist on 5 years of experience with Ruby on Rails, or refuse to consider someone for a “Windows API” job when they only have “Win32” on their resume.

The reason recruiters do this is because it’s easy, it can be computerized, and it’s the only way they know how to judge developers.

For almost all software development positions, though, it is the worst possible way to hire.

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. Furthermore, some of these technologies are very easy to learn. If I needed to hire someone to do Ruby development, someone with extensive Smalltalk and Python experience who had never even heard of Ruby would be a lot more likely to be successful than someone who read a book about Ruby once. 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.

The keywords section of a resume can’t be trusted much, anyway: every working programmer knows about these computer programs that filter resumes based on keywords, so they usually have a section of their resume containing every technology they have ever touched, solely to get through the filters.

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. A team developing GUIs for Windows using C++ and MFC is going to need at least one Windows/MFC guru somewhere on the team who can make sure that the code is organized correctly in the first place and who has enough experience to know how to solve the really hard problems that might come up.

Don’t start a new project without at least one architect with several years of solid experience in the language, classes, APIs, and platforms you’re building on. If you have a choice of platforms, use the one your team has the most skills with, even if it’s not the trendiest or nominally the most productive. Occasionally, this may mean you interview to find a candidate with really extensive experience in a particular set of technologies (not keywords, mind you: the whole stack, such as LAMP or .NET or J2EE). But most of your software developers should not be hired by keyword matching.

Sorting resumes is only one aspect of the hiring process, which includes making an environment that is attractive to programmers, attracting good resumes in the first place, and using a rigorous interview process that helps you hire the programmers who can hit the high notes.

A Field Guide to Developers

Unfortunately, you can advertise in all the right places, have a fantastic internship program, and interview all you want, but if the great programmers don’t want to work for you, they ain’t gonna come work for you. So this section will serve as a kind of field guide to developers: what they’re looking for, what they like and dislike in a workplace, and what it’s going to take to be a top choice for top developers.

Private offices

Last year I went to a Computer Science conference at Yale. One of the speakers, a Silicon Valley veteran who had founded or led quite an honor roll of venture-capital funded startups, held up the book Peopleware.

“You have to read this book,” he said. “This is the bible of how to run a software company. This is the most important book out there for how to run software companies.”

I had to agree with him: Peopleware is a great book. One of the most important, and most controversial, topics in that book is that you have to give programmers lots of quiet space, probably private offices, if you want them to be productive. The authors, DeMarco and Lister, go on and on about that subject.

After the speech I went up to the speaker. “I agree with you about Peopleware,” I said. “Tell me: did you have private offices for your developers at all your startups?”

“Of course not,” he said. “The VCs would never go for that.”


“But that might be the number one most important thing in that book,” I said.

“Yeah, but you gotta pick your battles. To VCs, private offices look like you’re wasting their money.”

There’s a strong culture in Silicon Valley that requires you to jam a lot of programmers into a big open space, despite a preponderance of evidence that private offices are far more productive, something which I’ve covered repeatedly on this site. I’m not really getting through to people, I don’t think, because programmers kind of like being social, even if it means they are unproductive, so it’s an uphill battle.

I’ve even heard programmers say things like, “Yeah, we all work in cubicles, but everyone works in a cubicle—up to and including the CEO!”

“The CEO? Does the CEO really work in a cubicle?”

“Well, he has a cubicle, but actually now that you mention it there’s this one conference room that he goes to for all his important meetings…”

Mmmm hmmm. A fairly common Silicon Valley phenomenon is the CEO who makes a big show of working from a cubicle just like the hoi polloi, although somehow there’s this one conference room that he tends to make his own (“Only when there’s something private to be discussed,” he’ll claim, but half the time when you walk by that conference room there’s your CEO, all by himself, talking on the phone to his golf buddy, with his Cole Haans up on the conference table).

Anyway, I don’t want to revisit the discussion of why private offices are more productive for software developers, or why just putting on headphones to drown out the ambient noise has been shown to reduce the quality of work that programmers produce, and why it doesn’t really cost that much more in the scheme of things to have private offices for developers. I’ve talked about that already. Today I’m talking about recruiting, and private offices in recruiting.

No matter what you think about productivity, and no matter what you think about egalitarian workspaces, two things are incontrovertible:

  1. Private offices have higher status
  2. Cubicles and other shared space can be socially awkward.

Given these two facts, the bottom line is that programmers are more likely to take the job that offers them a private office. Especially if there’s a door that shuts, and a window, and a nice view.

Now, it’s an unfortunate fact that some of these things that make recruiting easier are not really within your power. Even CEOs and founders can be prevented from establishing private offices if they’re dependent on VCs. Most companies only move or rearrange their office space every five to ten years. Smaller startups may not be able to afford private offices. So my experience has been that a number of excuses all pile up until it’s virtually impossible to get private offices for developers in any but the most enlightened of companies, and even in those companies, the decision of where to move and where people should work is often taken once every ten years by a committee consisting of the office manager’s secretary and a junior associate from a big architecture firm, who is apt to believe architecture-school fairy tales about how open spaces mean open companies, or whatever, with close to zero input from the developers or the development team.

This is something of a scandal, and I’ll keep fighting the good fight, but in the meantime, private offices are not impossible; we’ve managed to do it for all of our full-time programmers, most of the time, even in New York City where the rents are some of the highest in the world, and there’s no question that it makes people much happier about working at Fog Creek, so if you all want to keep resisting, so be it, I’ll just let this remain a competitive advantage.

The physical workspace

There’s more to the physical workspace than private offices. When a candidate comes to your company for the day of interviews, they’re going to look around at where people are working, and try to imagine themselves working there. If the office space is pleasant, if it’s bright, if it’s in a nice neighborhood, if everything is new and clean: they’ll have happy thoughts. If the office space is crowded, if the carpets are ratty and the walls haven’t been painted and there are posters up with pictures of rowing teams and the word TEAMWORK in large print, they’re going to have Dilbert thoughts.

A lot of tech people are remarkably unaware of the general condition of their office. In fact, even people who are otherwise attuned to the benefits of a nice office may be blinded to the particular weaknesses of their own office, since they’re so used to it.

Put yourself in your candidate’s heads, and think honestly:

  • What will they think of our location? How does Buffalo sound, compared to, say, Austin? Do people really want to move to Detroit? If you’re in Buffalo or Detroit, can you at least try to do most of your interviewing in September?
  • When they get to the office, what is the experience like? What do they see? Do they see a clean and exciting place? Is there a nice atrium lobby with live palm trees and a fountain, or does it feel like a government dental clinic in a slum, with dying corn plants and old copies of Newsweek?
  • What does the workspace look like? Is everything new and shiny? Or do you still have that gigantic, yellowing TEAM BANANA sign up, the one that was printed on fanfold paper on a dot matrix printer back when there used to be a thing called fanfold paper and a thing called dot matrix printers?
  • What do the desks look like? Do programmers have multiple large flat screens or a single CRT? Are the chairs Aerons or Staples Specials?

Let me, for a moment, talk about the famous Aeron chair, made by Herman Miller. They cost about $900. This is about $800 more than a cheap office chair from OfficeDepot or Staples.

They are much more comfortable than cheap chairs. If you get the right size and adjust it properly, most people can sit in them all day long without feeling uncomfortable. The back and seat are made out of a kind of mesh that lets air flow so you don’t get sweaty. The ergonomics, especially of the newer models with lumbar support, are excellent.

They last longer than cheap chairs. We’ve been in business for six years and every Aeron is literally in mint condition: I challenge anyone to see the difference between the chairs we bought in 2000 and the chairs we bought three months ago. They easily last for ten years. The cheap chairs literally start falling apart after a matter of months. You’ll need at least four $100 chairs to last as long as an Aeron.

So the bottom line is that an Aeron only really costs $500 more over ten years, or $50 a year. One dollar per week per programmer.

A nice roll of toilet paper runs about a buck. Your programmers are probably using about one roll a week, each.

So upgrading them to an Aeron chair literally costs the same amount as you’re spending on their toilet paper, and I assure you that if you tried to bring up toilet paper in the budget committee you would be sternly told not to mess around, there were important things to discuss.

The Aeron chair has, sadly, been tarnished with a reputation of being extravagant, especially for startups. It somehow came to stand for the symbol of all the VC money that was wasted in the dotcom boom, which is a shame, because it’s not very expensive when you consider how long it lasts; indeed when you think of the eight hours a day you spend sitting in it, even the top of the line model, with the lumbar support and the friggin’ tailfins is so dang cheap you practically make money by buying them.


Similar logic applies for other developer toys. There is simply no reason not to get your developers top of the line computers, at least two large (21″) LCD screens (or one 30″ screen), and give them free rein on to order any technical book they want. These are obvious productivity gains, but more importantly to our discussion here, they’re crucial recruiting tools, especially in a world where most companies treat programmers as interchangeable cogs, typists, really, why do you need such a big monitor and what’s wrong with 15″ CRTs? When I was a kid, …

The social life of developers

Software developers are not really all that different from regular people. Sure, I know, it’s popular these days to think of developers as stereotypical Asperger’s geeks, totally untuned to interpersonal things, but that’s just not true and even Asperger’s geeks care about the social aspect of a workspace, which includes these issues:

  • How are programmers treated inside the organization?

    Are they hotshots or typists? Is company management made up of engineers or former programmers? When developers go to a conference, do they fly first class? (I don’t care if that seems like a waste of money. Stars go first class. Get used to it.) When they fly in for an interview, does a limo pick them up at the airport or are they expected to find their own way to the office? All else being equal, developers are going to prefer an organization that treats them like stars. If your CEO is a grouchy ex-sales person who doesn’t understand why these prima donna developers keep demanding things like wrist pads and big monitors and comfortable chairs, who do they think they are?, your company probably needs an attitude adjustment. You’re not going to get great developers if you don’t respect them.

  • Who are their colleagues?

    One thing programmers pay close attention to in the day of interviewing is the people they meet. Are they nice? More importantly: are they smart? I did a summer internship once at Bellcore, a spinoff of Bell Labs, and everybody I met kept telling me the same thing, again and again: “The great thing about working for Bellcore is the people.”

    That said, if you have any grouchy developers that you just can’t get rid of, at least take them off the interview schedule, and if you have cheerful, social, cruise-director types, make sure they’re on it. Keep reminding yourself that when your candidate goes home and has to make a decision about where to work, if everyone they met was glum they are not going to have such a positive memory of your company.

    By the way, the original hiring rule for Fog Creek, stolen from Microsoft, was “Smart, and Gets Things Done.” Even before we started the company, we realized that we should add a third rule: “Not a jerk.” In retrospect, at Microsoft not being a jerk is not a requirement to get the job; although I’m sure they would pay lip service to how important it as for people to be nice to one another, the bottom line is that they would never disqualify someone for a job just because they were a jerk, in fact, being a jerk sometimes seems like a prerequisite for getting into upper management. This doesn’t really seem to hurt from a business perspective, although it does hurt from a recruiting perspective and who wants to work at a company where jerks are tolerated?

  • Independence and autonomy

    When I quit my job at Juno, back in 1999, before starting Fog Creek Software, HR gave me a standard exit interview, and somehow, I fell into the trap of telling the HR person everything that was wrong about the management of the company, something which I knew perfectly well could have no possible benefit to me and could only, actually, hurt, but I did it anyway, and the main thing I complained about was Juno’s style of hit-and-run management. Most of the time, you see, managers would leave people alone to quietly get their work done, but occasionally, they would get themselves involved in some microscopic detail of something which they would insist be done exactly their way, no excuses, and then they’d move on to micromanage some other task, not staying around long enough to see the farcical results. For example, I remember a particularly annoying period of two or three days where everyone from my manager to the CEO got involved in telling me exactly how dates must be entered on the Juno signup questionnaire. They weren’t trained as UI designers and didn’t spend enough time talking to me about the issues to understand why I happened to be right in that particular case, but it didn’t matter: management just would not back down on that issue and wouldn’t even take the time to listen to my arguments.

    Basically, if you’re going to hire smart people, you’re going to have to let them apply their skills to their work. Managers can advise, which they’re welcome to do, but they must be extremely careful to avoid having their “advice” interpreted as a command, since on any given technical issue it’s likely that management knows less than the workers in the trenches, especially, as I said, if you’re hiring good people.

    Developers want to be hired for their skills, and treated as experts, and allowed to make decisions within their own realm of expertise.

  • No politics

    Actually, politics happen everywhere that more than two people congregate. It’s just natural. By “no politics” I really mean “no dysfunctional politics.” Programmers have very well-honed senses of justice. Code either works, or it doesn’t. There’s no sense in arguing whether a bug exists, since you can test the code and find out. The world of programming is very just and very strictly ordered and a heck of a lot of people go into programming in the first place because they prefer to spend their time in a just, orderly place, a strict meritocracy where you can win any debate simply by being right.

    And this is the kind of environment you have to create to attract programmers. When a programmer complains about “politics,” they mean—very precisely—any situation in which personal considerations outweigh technical considerations. Nothing is more infuriating than when a developer is told to use a certain programming language, not the best one for the task at hand, because the boss likes it. Nothing is more maddening than when people are promoted because of their ability to network rather than being promoted strictly on merit. Nothing is more aggravating to a developer than being forced to do something that is technically inferior because someone higher than them in the organization, or someone better-connected, insists on it.

    Nothing is more satisfying than winning an argument on its technical merits even when you should have lost it on political merits. When I started working at Microsoft there was a major, misguided project underway called MacroMan to create a graphical macro programming language. The programming language would have been very frustrating for real programmers, because the graphical nature didn’t really give you a way to implement loops or conditionals, but would not have really helped non-programmers, who, I think, are just not used to thinking in algorithms and wouldn’t have understood MacroMan in the first place. When I complained about MacroMan, my boss told me, “Nothing’s gonna derail that train. Give up.” But I kept arguing, and arguing, and arguing—I was fresh out of college, about as unconnected as anyone could be at Microsoft—and eventually people listened to the meat of my arguments and the MacroMan project was shut down. It didn’t matter who I was, it mattered that I was right. That’s the kind of non-political organization that delights programmers.

All in all, focusing on the social dynamics of your organization is crucial to making a healthy, pleasant place to work that will retain programmers and attract programmers.

What am I working on?

To some extent, one of the best ways you can attract developers is to let them work on something interesting. This may be the hardest thing to change: doggone it, if you’re in the business of making software for the gravel and sand industry, that’s the business you’re in, and you can’t pretend to be some cool web startup just to attract developers.

Another thing developers like is working on something simple enough or popular enough that they can explain to Aunt Irma, at Thanksgiving. Aunt Irma, of course, being a nuclear physicist, doesn’t really know that much about Ruby programming in the gravel and sand industry.

Finally, many developers are going to look at the social values of the company they’re working for. Jobs at social networking companies and blog companies help bring people together and don’t really pollute, it seems, so they’re popular, while jobs in the munitions industry or in ethically-challenged accounting-fraud-ridden companies are a lot less popular.

Unfortunately I’m not really sure if I can think of any way for the average hiring manager to do anything about this. You can try to change your product lineup to make something “cool,” but that’s just not going to go very far. There are a few things, though, that I’ve seen companies do in this area:

  • Let the top recruits pick their own project

    For many years, Oracle Corporation had a program called MAP: the “Multiple Alternatives Program.” This was offered to the college graduates whom they considered the top candidates from each class. The idea was that they could come to Oracle, spend a week or two looking around, visiting all the groups with openings, and then choose any opening they wanted to work in.

    I think this was a good idea, although probably someone from Oracle knows better whether this worked out.

  • Use cool new technologies unnecessarily

    The big investment banks in New York are considered fairly tough places for programmers. The working conditions are dreadful, with long hours, noisy environments, and tyrannical bosses; programmers are very distinct third-class citizens while the testosterone-crazed apes who actually sell and trade financial instruments are corporate royalty, with $30,000,000 bonuses and all the cheeseburgers they can eat (often delivered by a programmer who happened to be nearby). That’s the stereotype, anyway, so to keep the best developers, investment banks have two strategies: paying a ton of money, and allowing programmers basically free reign to keep rewriting everything over and over again in whatever hot new programming language they feel like learning. Wanna rewrite that whole trading app in Lisp? Whatever. Just get me a goddamned cheeseburger.

    Some programmers couldn’t care less about what programming language they’re using, but most would just love to have the opportunity to work with exciting new technologies. Today that may be Python or Ruby on Rails; three years ago it was C# and before that Java.

    Now, I’m not telling you not to use the best tool for the job, and I’m not telling you to rewrite in the hot language-du-jour every two years, but if you can find ways for developers to get experience with newer languages, frameworks, and technologies, they’ll be happier. Even if you don’t dare rewrite your core application, is there any reason your internal tools, or less-critical new applications, can’t be written in an exciting new language as a learning project?

Can I identify with the company?

Most programmers aren’t just looking for a gig to pay the rent. They don’t want a “day job”: they want to feel like their work has meaning. They want to identify with their company. Young programmers, especially, are attracted to ideological companies. A lot of companies have some connection to open source or the free software movement (these are not the same thing), and that can be attractive to idealistic developers. Other companies line up with social causes, or produce a product which, in some way, can be perceived or framed as benefitting society.

As a recruiter, your job is to identify the idealistic aspects of your company, and make sure candidates are aware of them.

Some companies even strive to create their own ideological movements. Chicago-area startup 37signals has strongly aligned themselves with the idea of simplicity: simple, easy to use apps like Backpack and the simple, easy to use programming framework Ruby on Rails.

For 37signals, simplicity is an “-ism”, practically an international political movement. Simplicity is not just simplicity, oh no, it’s summertime, it’s beautiful music and peace and justice and happiness and pretty girls with flowers in their hair. David Heinemeier Hansson, the creator of Rails, says that their story is “one of beauty, happiness, and motivation. Taking pride and pleasure in your work and in your tools. That story simply isn’t a fad, it’s a trend. A story that allows for words like passion and enthusiasm to be part of the sanctioned vocabulary of developers without the need to make excuses for yourself. Or feel embarrassed about really liking what you do.” Elevating a web programming framework to a thing of “beauty, happiness, and motivation” may seem like hubris, but it’s very appealing and sure differentiates their company. In propagating the narrative of Ruby on Rails as Happiness, they’re practically guaranteeing that at least some developers out there will be looking for Ruby on Rails jobs.

But 37signals is still new at this identity management campaign thing. They don’t hold a candle to Apple Computer, which, with a single Superbowl ad in 1984, managed to cement their position to this day as the countercultural force of freedom against dictatorship, of liberty against oppression, of colors against black and white, of pretty women in bright red shorts against brainwashed men in suits. The implications of this, I’m afraid, are ironically Orwellian: giant corporations manipulating their public image in a way which doesn’t even make sense (like, uh, they’re a computer company—what the hell does that have to do with being against dictatorships?) and successfully creating a culture of identity that has computer shoppers around the world feeling like they’re not just buying a computer, they’re buying into a movement. When you buy an iPod, of course, you’re supporting Gandhi against British Colonialism. Every MacBook bought takes a stand against dictatorship and hunger!

Anyway. Deep breath… The real point of this section is to think of what your company stands for, how it’s perceived, and how it could be perceived. Managing your corporate brand is just as important for recruiting as it is for marketing.

One thing that programmers don’t care about

They don’t care about money, actually, unless you’re screwing up on the other things. If you start to hear complaints about salaries where you never heard them before, that’s usually a sign that people aren’t really loving their job. If potential new hires just won’t back down on their demands for outlandish salaries, you’re probably dealing with a case of people who are thinking, “Well, if it’s going to have to suck to go to work, at least I should be getting paid well.”

That doesn’t mean you can underpay people, because they do care about justice, and they will get infuriated if they find out that different people are getting different salaries for the same work, or that everyone in your shop is making 20% less than an otherwise identical shop down the road, and suddenly money will be a big issue. You do have to pay competitively, but all said, of all the things that programmers look at in deciding where to work, as long as the salaries are basically fair, they will be surprisingly low on their list of considerations, and offering high salaries is a surprisingly ineffective tool in overcoming problems like the fact that programmers get 15″ monitors and salespeople yell at them all the time and the job involves making nuclear weapons out of baby seals.

Sorting Resumes

This series continues with an article on how to sort resumes, so that the first people you interview are the most likely to work out well.

Finding Great Developers

Where are all those great developers?

The first time you try to fill an open position, if you’re like most people, you place some ads, maybe browse around the large online boards, and get a ton of resumes.

As you go through them, you think, “hmm, this might work,” or, “no way!” or, “I wonder if this person could be convinced to move to Buffalo.” What doesn’t happen, and I guarantee this, what never happens is that you say, “wow, this person is brilliant! We must have them!” In fact you can go through thousands of resumes, assuming you know how to read resumes, which is not easy, and I’ll get to that on Friday, but you can go through thousands of job applications and quite frankly never see a great software developer. Not a one.

Here is why this happens.

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.

The great college graduates get pulled into an internship by a professor with a connection to industry, then they get early offers from that company and never bother applying for any other jobs. If they leave that company, it’s often to go to a startup with a friend, or to follow a great boss to another company, or because they decided they really want to work on, say, Eclipse, because Eclipse is cool, so they look for an Eclipse job at BEA or IBM and then of course they get it because they’re brilliant.

If you’re lucky, if you’re really lucky, they show up on the open job market once, when, say, their spouse decides to accept a medical internship in Anchorage and they actually send their resume out to what they think are the few places they’d like to work at in Anchorage.

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.

Does this sound like the kind of person you want to hire? It should.

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. Their companies fail—sometimes because any company that would hire them would probably also hire a lot of unqualified programmers, so it all adds up to failure—but sometimes because they actually are so unqualified that they ruined the company. Yep, it happens.

These morbidly unqualified people rarely get jobs, thankfully, but they do keep applying, and when they apply, they go to and check off 300 or 1000 jobs at once trying to win the lottery.

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?

Astute readers, I expect, will point out that I’m leaving out the largest group yet, the solid, competent people. They’re on the market more than the great people, but less than the incompetent, and all in all they will show up in small numbers in your 1000 resume pile, but for the most part, almost every hiring manager in Palo Alto right now with 1000 resumes on their desk has the same exact set of 970 resumes from the same minority of 970 incompetent people that are applying for every job in Palo Alto, and probably will be for life, and only 30 resumes even worth considering, of which maybe, rarely, one is a great programmer. OK, maybe not even one. And figuring out how to find those needles in a haystack, we shall see, is possible but not easy.

Can I get them anyway?


Well, Maybe!

Or perhaps, It Depends!

Instead of thinking as recruiting as a “gather resumes, filter resumes” procedure, you’re going to have to think of it as a “track down the winners and make them talk to you” procedure.

I have three basic methods for how to go about this:

  1. Go to the mountain
  2. Internships
  3. Build your own community*

(Build your own community comes with a little asterisk that means “hard,” like the famous math problem that George Dantzig solved because he came into class too late to hear that it was supposed to be unsolvable).

You can probably come up with your own ideas, too. I’m just going to talk about three that worked for me.

To the mountain, Jeeves!

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? Instead of casting a wide net with a job search on, use the Joel on Software job board and limit your search to the smart people that read this site. Go to the really interesting tech conferences. Great Mac developers will be at Apple’s WWDC. Great Windows programmers will be at Microsoft’s PDC. There are a bunch of open source conferences, too.

Look for the hot new technology of the day. Last year it was Python; this year it’s Ruby. Go to their conferences where you’ll find early adopters who are curious about new things and always interested in improving.

Slink around in the hallways, talk to everyone you meet, go to the technical sessions and invite the speakers out for a beer, and when you find someone smart, BANG!—you launch into full-fledged flirt and flattery mode. “Ooooh, that’s so interesting!” you say. “Wow, I can’t believe you’re so smart. And handsome too. Where did you say you work? Really? There? Hmmmmmmm. Don’t you think you could do better? I think my company might be hiring…”

The corollary of this rule is to avoid advertising on general-purpose, large job boards. One summer, I inadvertently advertised our summer internships using MonsterTRAK, which offered the option to pay a little extra to make the internship visible to students at every school in the USA. This resulted in literally hundreds of resumes, not one of which made it past the first round. We ended up spending a ton of money to get a ton of resumes that stood almost no chance at finding the kind of people we wanted to hire. After a few days of this, the very fact that MonsterTRAK was the source of the resume made me think the candidate was probably not for us. Similarly, when Craigslist first started up and was really just visited by early-adopters in the Internet industry, we found great people by advertising on Craigslist, but today, virtually everyone who is moderately computer-literate uses it, resulting in too many resumes with too low of a needle-to-haystack ratio.


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.

Some hiring managers hate the idea of hiring interns. They see interns as unformed and insufficiently skilled. To some extent, that’s true. Interns are not as experienced as experienced employees (no. Really?!). You’re going to have to invest in them a little bit more and it’s going to take some time before they’re up to speed. The good news about our field is that the really great programmers often started programming when they were 10 years old. And while everyone else their age was running around playing “soccer” (this is a game that many kids who can’t program computers play that involves kicking a spherical object called a “ball” with their feet (I know, it sounds weird)), they were in their dad’s home office trying to get the Linux kernel to compile. Instead of chasing girls in the playground, they were getting into flamewars on Usenet about the utter depravity of programming languages that don’t implement Haskell-style type inference. Instead of starting a band in their garage, they were implementing a cool hack so that when their neighbor stole bandwidth over their open-access WIFI point, all the images on the web appeared upside-down. BWA HA HA HA HA!

So, unlike, say, the fields of law or medicine, over here in software development, by the time these kids are in their second or third year in college they are pretty darn good programmers.

Pretty much everyone applies for one job: their first one, and most kids think that it’s OK to wait until their last year to worry about this. And in fact most kids are not that inventive, and will really only bother applying for jobs where there is actually some kind of on-campus recruiting event. Kids at good colleges have enough choices of good jobs from the on-campus employers that they rarely bother reaching out to employers that don’t bother to come to campus.

You can either participate in this madness, by recruiting on campus, which is a good thing, don’t get me wrong, or you can subvert it, by trying to get great kids a year or two before they graduate.

I’ve had a lot of success doing it that way at Fog Creek. The process starts every September, when I start using all my resources to track down the best computer science students in the country. I send letters to a couple of hundred Computer Science departments. I track down lists of CS majors who are, at that point, two years away from graduating (usually you have to know someone in the department, a professor or student, to find these lists). Then I write a personal letter to every single CS major that I can find. Not email, a real piece of paper on Fog Creek letterhead, which I sign myself in actual ink. Apparently this is rare enough that it gets a lot of attention. I tell them we have internships and personally invite them to apply. I send email to CS professors and CS alumni, who usually have some kind of CS-majors mailing list that they forward it on to.

Eventually, we get a lot of applications for these internships, and we can have our pick of the crop. In the last couple of years I’ve gotten 200 applications for every internship. We’ll generally winnow that pile of applications down to about 10 (per opening) and then call all those people for a phone interview. Of the people getting past the phone interview, we’ll probably fly two or three out to New York for an in-person interview.

By the time of the in-person interview, there’s such a high probability that we’re going to want to hire this person that it’s time to launch into full-press recruitment. They’re met at the airport here by a uniformed limo driver who grabs their luggage and whisks them away to their hotel, probably the coolest hotel they’ve ever seen in their life, right in the middle of the fashion district with models walking in and out at all hours and complicated bathroom fixtures that are probably a part of the permanent collection of the Museum of Modern Art, but good luck trying to figure out how to brush your teeth. Waiting in the hotel room, we leave a hospitality package with a T-shirt, a suggested walking tour of New York written by Fog Creek staffers, and a DVD documentary of the 2005 summer interns. There’s a DVD player in the room so a lot of them watch how much fun was had by previous interns.

After a day of interviews, we invite the students to stay in New York at our expense for a couple of days if they want to check out the city, before the limo picks them up at their hotel and takes them back to the airport for their flight home.

Even though only about one in three applicants who make it to the in-person interview stage passes all our interviews, it’s really important that the ones that do pass have a positive experience. Even the ones that don’t make it go back to campus thinking we’re a classy employer and tell all their friends how much fun they had staying in a luxury hotel in the Big Apple, which makes their friends apply for an internship the next summer, if only for the chance at the trip.

During the summer of the internship itself, the students generally start out thinking, “ok, it’s a nice summer job and some good experience and maybe, just maybe, it’ll lead to a full-time job.” We’re a little bit ahead of them. We’re going to use the summer to decide if we want them as a full-time employee, and they’re going to use the summer to decide if they want to work for us.

So we give them real work. Hard work. Our interns always work on production code. Sometimes they’re working on the coolest new stuff in the company, which can make the permanent employees a little jealous, but that’s life. One summer we had a team of four interns build a whole new product from the ground up. That internship paid for itself in a matter of months. Even when they’re not building a new product, they’re working on real, shipping code, with some major area of functionality that they are totally, personally responsible for (with experienced mentors to help out, of course).

And then we make sure they have a great time. We host parties and open houses. We get them free housing in a rather nice local dorm where they can make friends from other companies and schools. We have some kind of extra-curricular activity or field trip every week: Broadway musicals (this year they went crazy about Avenue Q), movie openings, museum tours, a boat ride around Manhattan, a Yankees game, and believe it or not one of this year’s favorite things was a trip to Top of the Rock. I mean, it’s just a tall building where you go out on the roof in the middle of Manhattan. You wouldn’t think it would be such an awe-inspiring experience. But it was. A few Fog Creek employees go along on each activity, too.

At the end of the summer, there are always a few interns who convinced us that they are the truly great kinds of programmers that we just have to hire. Not all of them, mind you—some are merely great programmers that we are willing to pass on, and others would be great somewhere else, but not at Fog Creek. For example we’re a fairly autonomous company without a lot of middle management, where people are expected to be completely self-driven. Historically it has happened a couple of times where a summer intern would be great in a situation where they had someone to guide them, but at Fog Creek they wouldn’t get enough direction and would flounder.

Anyway, for the ones we really want to hire, there’s no use in waiting. We make an early offer for a full time job, conditional on their graduating. And it’s a great offer. We want them to be able to go back to school, compare notes with their friends, and realize that they’re getting a higher starting salary than anyone else.

Does this mean we’re overpaying? Not at all. You see, the average first year salary has to take into account a certain amount of risk that the person won’t work out. But we’ve already auditioned these kids, and there’s no risk that they won’t be great. We know what they can do. So when we hire them, we have more information about them than any other employer who has only interviewed them. That means we can pay them more money. We have better information, so we’re willing to pay more than employers without that information.

If we’ve done our job right, and we usually have, by this point the intern completely gives up and accepts our offer. Sometimes it takes a little more persuading. Sometimes they want to leave their options open, but the outstanding offer from Fog Creek ensures that the first time they have to wake up at 8:00am and put on a suit for an interview with Oracle, when the alarm goes off, there’s a good chance that they’ll say “why the heck am I getting up at 8:00am and putting on a suit for an interview with Oracle when I already have an excellent job waiting for me at Fog Creek?” And, my hope is, they won’t even bother going to that interview.

By the way, before I move on, I need to clarify something about internships in computer science and software development. In this day and age, in this country, it is totally expected that these are paid internships, and the salaries are usually pretty competitive. Although unpaid internships are common in other fields from publishing to music, we pay $750 a week, plus free housing, plus free lunch, plus free subway passes, not to mention relocation expenses and all the benefits. The dollar amount is a little bit lower than average but it includes the free housing so it works out being a little bit better than average. I thought I’d mention that because every time I’ve talked about internships on my website somebody inevitably gets confused and thinks I’m taking advantage of slave labor or something. You there—young whippersnapper! Get me a frosty cold orange juice, hand-squeezed, and make it snappy!

An internship program creates a pipeline for great employees, but it’s a pretty long pipeline, and a lot of people get lost along the way. We basically calculate we’re going to have to hire two interns for every full-time employee that we get out of it, and if you hire interns with one year left in school, there’s still a two year pipeline between when you start hiring and when they show up for their first day of full time work. That means we hire just about as many interns as we can physically fit in our offices each summer. The first three summers, we tried to limit our internship program to students with one year left in school, but this summer we finally realized that we were missing out on some great younger students so we opened the program to students in any year in college. Believe it or not, I’m even trying to figure out how to get high school kids in here, maybe setting up computers after school for college money, just to start to build a connection with the next generation of great programmers, even if it becomes a six year pipeline. I have a long horizon.

Build the community (*hard)

The idea here is to create a large community of like-minded smart developers who cluster around your company, somehow, so you have an automatic audience to reach out to every time you have an opening.

This is, to tell the truth, how we found so many of our great Fog Creek people: through my personal website, the one you’re reading right now. Major articles on this site can be read by as many as a million people, most of them software developers in some capacity. With a large, self-selecting audience, whenever I mention that I’m looking for someone on the home page, I’ll usually get a pretty big pile of very good resumes.

This is that category with the asterisk that means “hard,” since I feel like I’m giving you advice that says, “to win a beauty pageant, (a) get beautiful, and (b) enter the pageant.” That’s because I’m really not sure why or how this site became so popular or why the people who read it are the best software developers.

I really wish I could help you more here. Derek Powazek wrote a good book on the subject (Design for Community). A lot of companies tried various blogging strategies and unfortunately a lot of them failed to build up any kind of audience, so all I can say is that what worked for us may or may not work for you and I’m not sure what you can do about it. I did just open a job board on the site ( where, for $350, you can list a job that Joel on Software readers will see.

Employee referrals: may be slippery when wet

The standard bit of advice on finding great software developers is to ask your existing developers. The theory is, gosh, they’re smart developers, they must know other smart developers.

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.

One big risk, of course, is non-compete agreements. If you didn’t think these mattered, think about the case of Crossgain, which had to fire a quarter of its employees, all ex-Microsoft, when Microsoft threatened them with individual lawsuits. No programmer in their right mind should ever sign a non-compete agreement, but most of them do because they can never imagine that it would be enforced, or because they are not in the habit of reading contracts, or because they already accepted the employment offer and moved their families across the country and the first day of work is the first time they’ve seen this agreement and it’s a little bit too late to try to negotiate it. So they sign, but this is one of the slimiest practices of employers and they are often enforceable and enforced.

The point being, non-compete agreements may mean that if you rely too heavily on referrals and end up hiring a block of people from the same ex-employer, which is where your employees know the other star programmers from in the first place, you’re taking a pretty major risk.

Another problem is that if you have any kind of selective hiring process at all, when you ask your employees to find referrals, they’re not going to even consider telling you about their real friends. Nobody wants to persuade their friends to apply for a job at their company only to get rejected. It sort of puts a damper on the friendship.

Since they won’t tell you about their friends and you may not be able to hire the people they used to work with, what’s left is not very many potential referrals.

But the real problem with employee referrals is what happens when recruiting managers with a rudimentary understanding of economics decide to offer cash bonuses for these referrals. This is quite common. The rationale goes like this: it can cost $30,000 to $50,000 to hire someone good through a headhunter or outside recruiter. If we can pay our employees, say, a $5000 bonus for every hire they bring in, or maybe an expensive sports car for every 10 referrals, or whatever, think how much money that will save? And $5000 sounds like a fortune to a salaried employee, because it is. So this sounds like a win-win all-around kind of situation.

The trouble is that suddenly you can see the little gears turning, and employees start dragging in everyone they can think of for interviews, and they have a real strong incentive to get these people hired, so they coach them for the interview, and Quiet Conversations are held in conference rooms with the interviewers, and suddenly your entire workforce is trying to get you to hire someone’s useless college roommate.

And it doesn’t work. ArsDigita got a lot of publicity for buying a Ferrari and putting it in the parking lot and announcing that anyone who got 10 referrals could have it. Nobody ever got close, the quality of new hires went down, and the company fell apart, but probably not because of the Ferrari, which, it turns out, was rented, and not much more than a publicity stunt.

When a Fog Creek employee suggests someone that might be perfect to work for us, we’ll be willing to skip the initial phone screen, but that’s it. We still want them going through all the same interviews and we maintain the same high standards.

A Field Guide to Developers

What do developers look for in a job? What makes one job more appealing to them than another? How can you become the employer of choice? Read on!

Hitting the High Notes

In March, 2000, I launched this site with the shaky claim that most people are wrong in thinking you need an idea to make a successful software company:

The common belief is that when you’re building a software company, the goal is to find a neat idea that solves some problem which hasn’t been solved before, implement it, and make a fortune. We’ll call this the build-a-better-mousetrap belief. But the real goal for software companies should be converting capital into software that works.

For the last five years I’ve been testing that theory in the real world. The formula for the company I started with Michael Pryor in September, 2000 can be summarized in four steps:

Best Working Conditions Best Programmers Best Software Profit!

It’s a pretty convenient formula, especially since our real goal in starting Fog Creek was to create a software company where we would want to work. I made the claim, in those days, that good working conditions (or, awkwardly, “building the company where the best software developers in the world would want to work”) would lead to profits as naturally as chocolate leads to chubbiness or cartoon sex in video games leads to gangland-style shooting sprees.

For today, though, I want to answer just one question, because if this part isn’t true, the whole theory falls apart. That question is, does it even make sense to talk about having the “best programmers?” Is there so much variation between programmers that this even matters?

Maybe it’s obvious to us, but to many, the assertion still needs to be proven.

Several years ago a larger company was considering buying out Fog Creek, and I knew it would never work as soon as I heard the CEO of that company say that he didn’t really agree with my theory of hiring the best programmers. He used a biblical metaphor: you only need one King David, and an army of soldiers who merely had to be able to carry out orders. His company’s stock price promptly dropped from 20 to 5, so it’s a good thing we didn’t take the offer, but it’s hard to pin that on the King David fetish.

And in fact the conventional wisdom in the world of copycat business journalists and large companies who rely on overpaid management consultants to think for them, chew their food, etc., seems to be that the most important thing is reducing the cost of programmers.

In some other industries, cheap is more important than good. Wal*Mart grew to be the biggest corporation on Earth by selling cheap products, not good products. If Wal*Mart tried to sell high quality goods, their costs would go up and their whole cheap advantage would be lost. For example if they tried to sell a tube sock that can withstand the unusual rigors of, say, being washed in a washing machine, they’d have to use all kinds of expensive components, like, say, cotton, and the cost for every single sock would go up.

So, why isn’t there room in the software industry for a low cost provider, someone who uses the cheapest programmers available? (Remind me to ask Quark how that whole fire-everybody-and-hire-low-cost-replacements plan is working.)

Here’s why: duplication of software is free. That means that the cost of programmers is spread out over all the copies of the software you sell. With software, you can improve quality without adding to the incremental cost of each unit sold.

Essentially, design adds value faster than it adds cost.

Or, roughly speaking, if you try to skimp on programmers, you’ll make crappy software, and you won’t even save that much money.

The same thing applies to the entertainment industry. It’s worth hiring Brad Pitt for your latest blockbuster movie, even though he demands a high salary, because that salary can be divided by all the millions of people who see the movie solely because Brad is so damn hot.

Or, to put it another way, it’s worth hiring Angelina Jolie for your latest blockbuster movie, even though she demands a high salary, because that salary can be divided by all the millions of people who see the movie solely because Angelina is so damn hot.

But I still haven’t proven anything. What does it mean to be “the best programmer” and are there really such major variations between the quality of software produced by different programmers?

Let’s start with plain old productivity. It’s rather hard to measure programmer productivity; almost any metric you can come up with (lines of debugged code, function points, number of command-line arguments) is trivial to game, and it’s very hard to get concrete data on large projects because it’s very rare for two programmers to be told to do the same thing.

The data I rely upon comes from Professor Stanley Eisenstat at Yale. Each year he teaches a programming-intensive course, CS 323, where a large proportion of the work consists of about five programming assignments, each of which takes about two weeks. The assignments are very serious for a college class: implement a Unix command-line shell, implement a ZLW file compressor, etc.

There was so much griping among the students about how much work was required for this class that Professor Eisenstat started asking the students to report back on how much time they spent on each assignment. He has collected this data carefully for several years.

I spent some time crunching the data; it’s the only data sets I know of where we have dozens of students working on identical assignments using the same technology at the same time. It’s pretty darn controlled, as experiments go.

The first thing I did with this data was to calculate the average, minimum, maximum, and standard deviation of hours spent on each of twelve assignments. The results:

Project Avg Hrs Min Hrs Max Hrs StDev Hrs
CMDLINE99 14.84 4.67 29.25 5.82
COMPRESS00 33.83 11.58 77.00 14.51
COMPRESS01 25.78 10.00 48.00 9.96
COMPRESS99 27.47 6.67 69.50 13.62
LEXHIST01 17.39 5.50 39.25 7.39
MAKE01 22.03 8.25 51.50 8.91
MAKE99 22.12 6.77 52.75 10.72
SHELL00 22.98 10.00 38.68 7.17
SHELL01 17.95 6.00 45.00 7.66
SHELL99 20.38 4.50 41.77 7.03
TAR00 12.39 4.00 69.00 10.57
TEX00 21.22 6.00 75.00 12.11
ALL PROJECTS 21.44 4.00 77.00 11.16

The most obvious thing you notice here is the huge variations. The fastest students were finishing three or four times faster than the average students and as much as ten times faster than the slowest students. The standard deviation is outrageous. So then I thought, hmm, maybe some of these students are doing a terrible job. I didn’t want to include students who spent 4 hours on the assignment without producing a working program. So I narrowed the data down and only included the data from students who were in the top quartile of grades… the top 25% in terms of the quality of the code. I should mention that grades in Professor Eisenstat’s class are completely objective: they’re calculated formulaically based on how many automated tests the code passes and nothing else. No points are deducted for bad style or lateness.

Anyway, here are the results for the top quartile:

Project Avg Hrs Min Hrs Max Hrs StdDev Hrs
CMDLINE99 13.89 8.68 29.25 6.55
COMPRESS00 37.40 23.25 77.00 16.14
COMPRESS01 23.76 15.00 48.00 11.14
COMPRESS99 20.95 6.67 39.17 9.70
LEXHIST01 14.32 7.75 22.00 4.39
MAKE01 22.02 14.50 36.00 6.87
MAKE99 22.54 8.00 50.75 14.80
SHELL00 23.13 18.00 30.50 4.27
SHELL01 16.20 6.00 34.00 8.67
SHELL99 20.98 13.15 32.00 5.77
TAR00 11.96 6.35 18.00 4.09
TEX00 16.58 6.92 30.50 7.32
ALL PROJECTS 20.49 6.00 77.00 10.93

Not much difference! The standard deviation is almost exactly the same for the top quartile. In fact when you look closely at the data it’s pretty clear there’s no discernable correlation between the time and score. Here’s a typical scatter plot of one of the assignments… I chose the assignment COMPRESS01, an implementation of Ziv-Lempel-Welch compression assigned to students in 2001, because the standard deviation there is close to the overall standard deviation.

Scatter Plot showing hours vs. score

There’s just nothing to see here, and that’s the point. The quality of the work and the amount of time spent are simply uncorrelated.

I asked Professor Eisenstat about this, and he pointed out one more thing: because assignments are due at a fixed time (usually midnight) and the penalties for being late are significant, a lot of students stop before the project is done. In other words, the maximum time spent on these assignments is as low as it is partially because there just aren’t enough hours between the time the assignment is handed out and the time it is due. If students had unlimited time to work on the projects (which  would correspond a little better to the working world), the spread could only be higher.

This data is not completely scientific. There’s probably some cheating. Some students may overreport the time spent on assignments in hopes of gaining some sympathy and getting easier assignments the next time. (Good luck! The assignments in CS 323 are the same today as they were when I took the class in the 1980s.) Other students may underreport because they lost track of time. Still, I don’t think it’s a stretch to believe this data shows 5:1 or 10:1 productivity differences between programmers.

But wait, there’s more!

If the only difference between programmers were productivity, you might think that you could substitute five mediocre programmers for one really good programmer. That obviously doesn’t work. Brooks’ Law, “adding manpower to a late software project makes it later,” is why. A single good programmer working on a single task has no coordination or communication overhead. Five programmers working on the same task must coordinate and communicate. That takes a lot of time. There are added benefits to using the smallest team possible; the man-month really is mythical.

But wait, there’s even more!

The real trouble with using a lot of mediocre programmers instead of a couple of good ones is that no matter how long they work, they never produce something as good as what the great programmers can produce.

Five Antonio Salieris won’t produce Mozart’s Requiem. Ever. Not if they work for 100 years.

Five Jim Davis’s — creator of that unfunny cartoon cat, where 20% of the jokes are about how Monday sucks and the rest are about how much the cat likes lasagna (and those are the punchlines!) … five Jim Davis’s could spend the rest of their lives writing comedy and never, ever produce the Soup Nazi episode of Seinfeld.

The Creative Zen team could spend years refining their ugly iPod knockoffs and never produce as beautiful, satisfying, and elegant a player as the Apple iPod. And they’re not going to make a dent in Apple’s market share because the magical design talent is just not there. They don’t have it.

The mediocre talent just never hits the high notes that the top talent hits all the time. The number of divas who can hit the f6 in Mozart’s Queen of the Night is vanishingly small, and you just can’t perform The Queen of the Night without that famous f6.

Is software really about artistic high notes? “Maybe some stuff is,” you say, “but I work on accounts receivable user interfaces for the medical waste industry.” Fair enough. This is a conversation about software companies, shrinkwrap software, where the company’s success or failure is directly a result of the quality of their code.

And we’ve seen plenty of examples of great software, the really high notes, in the past few years: stuff that mediocre software developers just could not have developed.

Back in 2003, Nullsoft shipped a new version of Winamp, with the following notice on their website:

  • Snazzy new look!
  • Groovy new features!
  • Most things actually work!

It’s the last part… the “Most things actually work!” that makes everyone laugh. And then they’re happy, and so they get excited about Winamp, and they use it, and tell their friends, and they think Winamp is awesome, all because they actually wrote on their website, “Most things actually work!” How cool is that?

If you threw a bunch of extra programmers onto the Windows Media Player team, would they ever hit that high note? Never in a thousand years. Because the more people you added to that team, the more likely they would be to have one real grump who thought it was unprofessional and immature to write “Most things actually work” on your website.

Not to mention the comment, “Winamp 3: Almost as new as Winamp 2!”

That kind of stuff is what made us love Winamp.

By the time AOL Time Warner Corporate Weenieheads got their hands on that thing the funny stuff from the website was gone. You can just see them, fuming and festering and snivelling like Salieri in the movie Amadeus, trying to beat down all signs of creativity which might scare one old lady in Minnesota, at the cost of wiping out anything that might have made people like the product.

Or look at the iPod. You can’t change the battery. So when the battery dies, too bad. Get a new iPod. Actually, Apple will replace it if you send it back to the factory, but that costs $65.95. Wowza.

Why can’t you change the battery?

My theory is that it’s because Apple didn’t want to mar the otherwise perfectly smooth, seamless surface of their beautiful, sexy iPod with one of those ghastly battery covers you see on other cheapo consumer crap, with the little latches that are always breaking and the seams that fill up with pocket lint and all that general yuckiness. The iPod is the most seamless piece of consumer electronics I have ever seen. It’s beautiful. It feels beautiful, like a smooth river stone. One battery latch can blow the whole river stone effect.

Apple made a decision based on style, in fact, iPod is full of decisions that are based on style. And style is not something that 100 programmers at Microsoft or 200 industrial designers at the inaptly-named Creative are going to be able to achieve, because they don’t have Jonathan Ive, and there aren’t a heck of a lot of Jonathan Ives floating around.

I’m sorry, I can’t stop talking about the iPod. That beautiful thumbwheel with its little clicky sounds …  Apple spent extra money putting a speaker in the iPod itself so that the thumbwheel clicky sounds would come from the thumbwheel. They could have saved pennies … pennies! by playing the clicky sounds through the headphones. But the thumbwheel makes you feel like you’re in control. People like to feel in control. It makes people happy to feel in control. The fact that the thumbwheel responds smoothly, fluently, and audibly to your commands makes you happy. Not like the other 6,000 pocket-sized consumer electronics bit of junk which take so long booting up that when you hit the on/off switch you have to wait a minute to find out if anything happened. Are you in control? Who knows? When was the last time you had a cell phone that went on the instant you pressed the on button?



Emotional appeal.

These are what make the huge hits, in software products, in movies, and in consumer electronics. And if you don’t get this stuff right you may solve the problem but your product doesn’t become the #1 hit that makes everybody in the company rich so you can all drive stylish, happy, appealing, cars like the Ferrari Spider F-1 and still have enough money left over to build an ashram in your back yard.

It’s not just a matter of “10 times more productive.” It’s that the “average productive” developer never hits the high notes that make great software.

Sadly, this doesn’t really apply in non-product software development. Internal, in-house software is rarely important enough to justify hiring rock stars. Nobody hires Dolly Parton to sing at weddings. That’s why the most satisfying careers, if you’re a software developer, are at actual software companies, not doing IT for some bank.

The software marketplace, these days, is something of a winner-take-all system. Nobody else is making money on MP3 players other than Apple. Nobody else makes money on spreadsheets and word processors other than Microsoft, and, yes, I know, they did anti-competitive things to get into that position, but that doesn’t change the fact that it’s a winner-take-all system.

You can’t afford to be number two, or to have a “good enough” product. It has to be remarkably good, by which I mean, so good that people remark about it. The lagniappe that you get from the really, really, really talented software developers is your only hope for remarkableness. It’s all in the plan:

Best Working Conditions Best Programmers Best Software Profit!

Whaddaya Mean, You Can’t Find Programmers?

Ask any software CEO these days what their biggest problem is, and they’ll usually complain about how hard it is to find good programmers. “There’s just nobody out there,” they say. “I can’t hire anyone.”

Frankly, this is baloney. In microeconomic terms: the market is clearing. There are hundreds of thousands of programmers out there, and you can hire them, if you know how. This article is about the “programmer’s perspective” on how to find people and convince them to work for you.

First of all, let me motivate you a little.

If you go down to your neighborhood Starbucks (a large coffee shop chain) and ask them if they have job openings, they’ll say something, “yes, we have n openings now,” where n is a nice round integer like “0” or “4”. Once they hire n people, they don’t have any more openings and they won’t hire any more people. That’s because for a given coffee shop, customer demand is fixed. You have to have enough employees to meet that demand, or the lines will be too long and people will walk out, but after that point, hiring more people is pointless.

But with software companies, that’s not the case. Customer demand is directly related to how many problems you solve, how good your product is, and how many features it has that address potential customers’ needs. Adding another programmer means you have time to implement more features, optimize and debug code, make file format converters, and other things which get you more customers. So almost every software company or Internet startup I’ve visited has generally had a policy of “we’ll hire any good technical people we can get.” (I wrote an article about this which you can read here.)

Now, let’s review some microeconomics. In a free market, it is almost axiomatic that the market always clears. That’s a technical term that means that when somebody tries to sell something, if they are willing to accept the market price, they will be able to sell it, and when somebody wants to buy something, if they are willing to pay the market price, they will be able to buy it. It’s just a matter of both sides accepting the market price.

The trouble comes when people are not realistic about market prices. A two bedroom, two bathroom coop apartment in my neighborhood sells for about $500,000. Sellers who believe that will be able to sell their apartment. Sellers who don’t believe that and list their apartment for $800,000 are going to wait years without selling their apartment, and they won’t know why.

A top notch web programmer in New York City at a top web development firm, working on a consulting basis, is going to bill about $250 an hour. People who believe that are going to be able to hire consulting firms to build their web sites. People who don’t believe that aren’t going to understand why they can’t hire anyone.

You can hire programmers if you are willing to pay at or above the market price. This past spring, a company in Texas took out full page ads in the Yale Daily News and the Harvard Crimson saying “Attention seniors: We are going to hire the best 5 computer science graduates, and we’re going to give them a $200,000 per year salary and a BMW.” This happens to be a lot more than the going rate for recent CompSci graduates of those schools (which is more like $65,000), but I’m sure they filled those positions.

“Well, yes,” you say, “if I’m willing to vastly overpay, I can hire people. But how do I hire people without shelling out $200,000 a year?”

Aha! We’re onto something here. The trick is that money is not everyone’s number one motivator, in fact, it’s not even the number one consideration for most people. There are other things that matter more, and, luckily, most of those things are cheaper than money. So the next trick is, how do we whittle down that market price to something a little bit more affordable by substituting the kind of non-monetary benefits that excite people?

There are a lot of other things that you can “give” programmers, for example, you can give them the feeling that they’re working on something worthwhile, which has actual cash value for most people and therefore reduces the amount you have to pay them.

I love Julia Roberts. And I loved her the most when she threw a tantrum in the movie Erin Brockovich:

“That is my work! my sweat! my time away from my kids! If that’s not personal, I don’t know what is!”

And this is the key to making people want to work for you: you have to understand that people spend most of their waking hours at work, and they are going to take it personally, and they are not going to be willing to suffer throughout their career just for a little extra cash they can spend when they retire. Work needs to be rewarding and pleasant. Doing things that make work rewarding and pleasant is the most important part of attracting people.

I recommend a three-pronged approach to hiring people:

  1. Make the workplace attractive,
  2. Eliminate obstacles, and
  3. Provide benefits which are more valuable than the money they cost.

1: Make the workplace attractive

After I finished my bike trip, I applied for a couple of different jobs in New York City, one at AT&T and the other at Viacom. They were roughly equivalent. The salaries were pretty close. But I just couldn’t stop thinking about one thing: the AT&T offices were dingy and dark, in some kind of a stone age office that smelled of 1930s bureaucracy. People were starting to look like mushrooms. There were torn Dilbert cartoons all over the cubicles. (Warning sign number one.) The furniture was falling apart. It was just nasty. But Viacom was in a nice, shiny, modern, bright office building that felt like lawyers’ offices. It was clean and new and pleasant. I know I should have been thinking about something more substantial as I made my decision, but I just could not get over how unpleasant it would be to spend my days working in the AT&T dungeon.

It reminded me of a visit I made to EDS once when I was working for Microsoft. EDS had modern, clean, well lit offices, but they were just seas of cubicles. Any kind of personalization of the workspace was forbidden. Fluorescent lights everywhere. Windows were strictly for managers. If you’ve seen the movie Office Space, you know what I mean. As I left the building with my Microsoft colleagues, I remember saying, “you know, if I had to work in a place like that, I’d cry for two hours when I got to work in the morning.”

There’s a whole list of things you can do to create a pleasant and attractive workplace. People spend so much of their time at work that you can’t blame them for wanting to work in a nice place, not a dilbertesque cubicle farm. Think of a university professor’s office, or a lawyer’s. Is it quiet? Do people have enough space to get some privacy? Does your workplace feel like a Moroccan marketplace, or the English department at Princeton? Is there sun? Or is it all fluorescent lighting?

Cubicles have become such an icon of nasty workplaces that it’s shocking that the companies who manufacture them still have the chutzpah to pretend that they’re efficient, productive, and pleasant. Peopleware calls this “lying by repeated assertion.”

Put yourself in the job candidate’s shoes. Company number 1 shows you a big crowded room, with a bunch of desks shoved in tightly, lots of marketing guys shouting on the phone next to the programmers and a bunch of sales jocks shouting tasteless jokes. “You would sit here, in this cubicle with Doris from Accounts Payable.” Doris has a whiny, high-pitched voice and self-affirmation notes to herself pinned up on the dividers. The half-height cubicle they show you is completely lit by a fluorescent light which is on the fritz.

Company number 2 shows you through a quiet hallways, shows you a sunlit, plush office with a window, big plants, a door that closes, a nice Aeron chair, the smell of fresh-brewed coffee from the espresso machine in the kitchen, cool mahogany stuff and Ansel Adams prints, and says “this would be your office.” There’s a patio outside for lunch when it’s warm and a lounge where people meet for afternoon tea. Doris is nowhere to be seen. 

All else being equal, which job are you going to take?

It’s human nature for people to jump to snap judgments based on all kinds of external factors. If they come to visit you on the interview and something just doesn’t smell right, they’re not going to work for you. First impressions count for a lot. The fountain in the lobby, the fully-stocked kitchen with Snapple and Perrier as well as cheap drinks like Coke — it all seems trivial, but it’s making an impression.

2: Eliminate Obstacles

Make a list of the obstacles that are likely to keep someone from wanting to work for you, and figure out creative ways to solve them.

First of all, get your recruiting department to stop being an obstacle. I don’t know how many companies I’ve seen that have disorganized recruiters who just forget candidates and don’t call them back. It took my last employer something like 3 months from the time I first contacted them to make me an offer. There’s just no excuse for that.

Another thing I don’t understand is why people have so much trouble telling candidates “no thanks.” You would not believe how many companies I know that just don’t tell the candidate anything, hoping they “get the hint.” They do this even when there’s a devoted recruiting staff whose whole job is saying “no thanks” 93 times a day.

When a candidate applies for a job, you should be able to schedule an interview immediately. After the interview, you should be able to give the candidate a straight yes or no answer on the spot. If you have to wait for references, you should be able to take care of that in a day or two, and keep the candidate apprised daily.

Next, find out what things are worrying your job candidates. In the US, a common problem is getting work visas for people from other countries. Get a great immigration lawyer and pay all expenses.

In some markets, especially Silicon Valley and New York City, the housing situation is insane. Apartments are absurdly expensive and real estate brokers are sharks. This worries people. Solve the problem for them: offer them temporary, furnished housing for a couple of months while they look for an apartment. Retain an local real estate expert to find them housing — somebody who you trust will only show them nice apartments, not ratty dumps, and pay all the broker fees.

What other fears do they have? A new school for the kids? A job for their spouse? All these are things you can help with by being creative. You can hire relocation specialists who are experts at smoothing these things over (but make sure they’re good, or you’ll do more damage than good).

Want to hire someone who has been working in Europe? They’re probably used to 6 weeks a year of paid vacations. Match it. Giving somebody six weeks instead of three weeks vacation is like paying them about 6% more salary. Many people who like to travel or spend long weeks at the beach with their family would be happy to get more vacation in exchange for lower base salary, and they’ll be more productive to boot.

3. Provide benefits which are more valuable than the money they cost

Have you ever gotten junk mail from a phone company offering you a $50 savings bond if you switch to their service?

Most people think that a $50 savings bond is worth $50. Nope. It’s worth $25.

Have you ever gotten a free T-shirt at a trade show?

Most people think that a t-shirt is worth about $15, because that’s how much they cost at the Gap. Nope. It’s worth about 50 cents.

There are a whole bunch of things you can give employees which cost less than they seem to be worth. Almost every software company has free soft drinks. Massages seem to be popular in Silicon Valley. I’ve heard of a consulting company that is setting up beach houses and ski houses for employees to use. Microsoft has subsidized espresso carts in practically every building. Google has a gourmet chef with free lunches and dinners. Health club memberships cost a lot less than you think if you buy them for all your employees, because only a fraction of them actually take advantage of them.

Every Microsoft manager has a morale budget to use as they see fit. Whenever a new Star Trek movie comes out, Microsoft rents out an entire movie theater for the afternoon and takes the whole damn company out to the movies. Movie theatres are usually empty in the afternoon, so this costs a heck of a lot less than you think.

Think about what you can do to show people how much you appreciate them. Here’s an example. When you call someone up to say, “you’ve got the job,” if you’re organized, you probably have a little post-in note stuck on your finger you got from The Big Boss which says something like $100-$105. That’s to remind you that you’re going to offer them $100,000, but if they balk, you have the authority to go as far as $105. Now imagine that you call the candidate up and offer them $100. They accept. Great! You saved the company $5,000 a year!

Oh my. Big deal. $5,000 a year. Wait a day, call them right back, and say, “I know you accepted at $100, but we’ve decided to set your salary at $105.”

Aha. Now sit back and watch the law of reciprocity kick in. Having agreed that the “fair” price for their services is $100, you’ve thrown them a gift of an extra $5, and they’re going to feel some level of extra obligation towards you in exchange. It’s human nature. And it’s going to keep them from taking another job. (If you haven’t heard about the law of reciprocity, read Cialdini.)

And then think about the things that attract employees which do not even cost money. Give people authority. Let them work with smart people and learn from the best. Have an exciting project to work on. Make sure they keep learning and are always doing something new, not just the same old thing. Read all the other essays on my site about making a healthy work environment. Read Peopleware and make everyone else read it, too.