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 Monster.com 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?
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:
(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 Monster.com, 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 (jobs.joelonsoftware.com) 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!
You’re reading Joel on Software, stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.
I’m Joel Spolsky, co-founder of Fog Creek Software, a New York company that proves that you can treat programmers well and still be highly profitable. Programmers get private offices, free lunch, and work 40 hours a week. Customers only pay for software if they’re delighted. We make Trello, easy web-based collaboration software, FogBugz, an enlightened bug tracking and software development tool, and Kiln, a distributed source control system that will blow your socks off. I’m also the co-founder and CEO of Stack Exchange. More about me.