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. 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:
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 first is that the first two programmers in history were both women: Ada Lovelace and Grace Hopper. 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:
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. |
Home >