Hiring programmers for dummies

This tutorial is for entrepreneurs who aren't programmers but are faced with the need to hire one. I'm a programmer and my boss is a guy who started his business in a 3-room office rental, building it up to a $50-million business in ten years. I've been self-employed twice before I joined his firm, and think I know enough about business that it sails or sinks on the people it hires.

This is not a tutorial about how Google should hire programmers, or how programmers should hire other programmers. They will both do it differently with a stronger focus on specific skills and abilities, and they'll even be more efficient at it. But a non-programmer isn't going to be able to look at a candidate's code and know if they solved a problem correctly, so the key to this tutorial is to measure consistency and use that as your way to judge skill without having that skill yourself.

I've now hired 12 programmers and interviewed dozens more, many of whom were better than me. Sometimes I got blinded by the resume and turned them down because I felt the work I had to offer was beneath them, but when the economy changed in 2008 I learned that the novelty and celebrity of the assignment didn't matter one bit. I've had one young programmer quit after 6 weeks because he felt the company's benefits package was "Kmart-esque", but his elder replacement not only had more chops, he also had an attitude that shone on his own parade.

If you don't know how to program, then this is how you hire somebody who does.

1. Don't hire on certifications

If the resume is bordered by an iconography of certifications then you've got a candidate who knows how to pass tests but not necessarily how to program. Industry certifications are diploma mills: don't trust them. The higher the candidate lauds them, the less confidence they have in their skill. We once hired a guy with certifications in everything who claimed to be a "Guru" in .Net, but didn't understand why he couldn't invoke methods in an uninstantiated class; it was as if an auto mechanic didn't know why the engine didn't start when there was no gas in the tank or battery connected, but had certifications from Ford saying he knew everything about the new F150.

In other tech fields there are certifications that do matter, but there is nothing in computer programming that holds weight. Someone who holds a vendor's highest certification might know how to use a soon-to-be-obsolete technology, but it doesn't mean he knows how to help you.

A young programmer trying to get his break may turn to certifications to make his resume look better, so if a kid shows up with an MSCE and sweat on his brow then forgive his transgression into the world of industry whoring; he just hasn't got laid, yet.

2. It's not age, it's attitude

Our niche is sadly for the young, because while the tools are evolving rapidly the training isn't keeping up with them. Going to work as a programmer can be like stepping into a time capsule, and after five or ten years at one firm the programmer can reenter the job-market and find himself dangerously behind the curve, possessing no skill that the market values anymore. I sometimes think programmers have more in common with strippers and boxers than other engineers.

I've conducted interviews with middle-aged guys who begged me for the chance to work on a web application--for no pay--just because they understood this was the future of their career but had no experience in it. Ten years ago there would have been middle-aged programmers begging for the chance to work on a Java application. It's pathetic and scary, but it's reality, and it's why programmers start jockeying for management positions shortly after they turn 30; everyone is expecting them to be out of programming and into management by the time they're 40, and if they aren't then they're screwed.

You already know the law against age discrimination in hiring, but you also know that law is hard to enforce. This topic is sensitive and rarely discussed, so let's get the elephant out of the living room now. Here's how you should be judging any programmer, no matter how old they are:

Are they familiar with modern toolchains? Spend a few minutes looking at the front page of Stackoverflow.com and jot down some of the programming languages and frameworks discussed there, then ask your candidate if they've heard of any and can describe what they are. It doesn't matter if they haven't programmed in any of them (though that's a plus anyway), but that they have been keeping up and reading about them

Are they intelligent? One half of programming is problem solving, so you should try some classic logic puzzles plus some open-ended posers. An example of a logic puzzle is the one about the guy with a canoe, a fox, a chicken, and a bag of grain, and he can only transport one at a time in the canoe and has to get them all across without anything getting eaten. An example of an open-ended poser would be "how many gas stations are there in Los Angeles?" or "How would you swap the Golden Gate and Brooklyn Bridges?" It doesn't matter if their answers are incorrect as long as they describe their thought process out loud. If they say "how would I know how many gas stations there are anywhere?" then they fail. If they say "It's impossible to swap those bridges, it doesn't make sense" then they fail. Intelligent candidates will rise to the challenge and take a shot anyway

Can they learn? The other half of programming is constant learning, and you can get an idea of how well they could learn a new programming language or technology by testing their ability to learn your business. Describe what you do, show them around, point out what your processes are, then quiz them. Test them the way you'd test a new foreman or call-center supervisor, because if you're hiring them to write programs to help your business then they ought to be able to learn how your business works first

3. A note about gender

It's also a truism that most programmers are male, but there are also laws against gender discrimination, too. On this subject I'll make only two observations.

The second is a personal observation from conducting interviews, where one of the most intimidating resumes came from a woman who worked on fire control systems. During the interview she described the time she had to debug a device driver on live munitions in the field, where the serial interface was sending data from the bomb's altimeter and other sensors faster than the driver could process them. This was one of the cases when I thought the mundane work we had to offer would be beneath her experience, but in retrospect I wish I'd made the offer anyway--most programming is quite mundane no matter what the application.

I picked her as an example because there just isn't much that's more male-oriented than guns and bombs and programming, so it helps to make an important point: there isn't really any mythos that men are better than women at programming like there is for young vs. old programmers. Women are simply rare in programming ,and that's it.

4. Make sure they can actually write code

Never hire a juggler until you've seen him juggle, and never hire a programmer if you've never seen them write code. It is amazing how many candidates there are who literally can't program at all, and reckon themselves to be programmers because they can tweak parameters in an existing program or cut-n-paste code from the Internet and poke-poke-poke at it until it runs.

Even if you can't judge the results yourself, you need to give the candidate a written code test. Say you'll be showing it to some programmers you know and asking for their opinion later. Here are two code tests that weed out the programming illiterate:

FizzBuzz: Write a program that prints the numbers from 1 to 100. But for multiples of three print “Fizz” instead of the number and for the multiples of five print “Buzz”. For numbers which are multiples of both three and five print “FizzBuzz”

Recursion is a key concept in computer programming, which is why I always test for it. A large number of candidates flame-out badly on #2, and it's quite ridiculous because even high-school computer-science classes teach it.

If Google or Microsoft were hiring, they'd probably also ask the programmer to implement a linked list or binary tree to make sure they understood the concept of pointers, which--like recursion--filter out a huge number of wannabes early. Computer Science courses in college are famous for beginning with dozens of students, but falling to a mere handful the day after pointers are discussed. It's just something that you either have the "gene" for, or don't.

The only reason I don't suggest testing for pointers knowledge is because most modern programming environments have abstracted them away and turned them into the easier concept of "references". And if you're an entrepreneur looking for a programmer today, then the odds are that they won't be working with raw, unmanaged pointers in any of the projects you give them.