How to hire programmers
Colin Steele writes about hiring programmers and asking them to show a code sample:
Since I’ve long viewed the practice of programming as a craft, I’ve tried to apply the notion of a portfolio, a gimmick I learned from my boss back at AOL. A good programmer should have a body of work, which can be shown, and in it you will find strong clues as to the type of programmer they are. So unless I’ve worked with someone before, directly, along with references and resumes, I ask them to provide:
A significant code sample which you feel is representative of your best recent work.
You might be surprised how that surprises folks. I’m not sure if they think I’m going to poach their code, or rat them out to the employers whom they were working for when they wrote it, or what. In any case, of those that get over it and send me something, a disheartening number send me what amount to toys – 100 line incomplete snippets of something-or-other. Or, just as bad, a swath of user interface callback code, or a class definition that’s 90% setters and getters. Sigh.
Once I’ve settled on the notion that a particular person might be a good hire, I try them out. That amounts to a six-month “no fault divorce” period, where the candidate is brought on board as a 1099 contractor, but in all other ways as a full fledged member of the team. Most folks need six months to settle in, get embedded in team dynamics, and learn enough of the problem domain to be useful. During that time, if anything doesn’t feel right – and I do this purely based on gut instincts – I gently end the relationship.
I can imagine for some kinds of coding this is especially important. If you’re writing an application whose main goal is data mining, then to see a code sample that shows an unusual cleverness in sorting or averaging or summing or grouping or parsing might be very important. However, that would not apply to a lot of the work I have done over the last 10 years. I might make a distinction between the engineers who design cars versus the car mechanics who fix cars. The engineers have to know a lot more than the mechanics. But for about 95% of the web sites I’ve built over the last 10 years, the work has been more like that of a car mechanic, rather than that of a car designer.
Much of the work I’ve done, and for which I’ve hired people, has been straightforward CMS work, which, in a sense, is the simplest kind of programming – designing the database is one of the few high-level, strategic decisions one has to make for that kind of work. The rest is just writing some code to either put data into the database, or take data out of the database. These projects do not necessarily demand great technical cleverness, but they do demand clear thinking. The worst thing about CMS projects is the way the code tends to sprawl over time. After 3 or 4 years working on a CMS, you find you have 50 modules, and you find the amount of redundant code building up in your system is allowing the same bugs to show up, again and again and again. The need to keep things organized eventually becomes the #1 priority. I’d be unable to figure out how well-organized someone is from a short code snippet. For me, the important test is the one Steele mentions at the end – giving someone a test of a few months.
But of course, one needs to screen out the folks who are really bad. Since 2006, I’ve had to hire programmers for 3 different projects. As I wrote in How Much Should You Lie On Your Resume:
The interviews were amazing. People would claim all kinds of things on their resume that they couldn’t defend when we met for an interview.
One woman said she knew Javascript. During the interview, I asked how well she knew Javascript. She said she’d taken a class in it during 1999 (that’s 8 years previous!). Could she write a single line of Javascript now? Um, no. But, uh, if she started working with it, she was sure it would come back quickly.
One fellow said he knew PHP and MySql. Turns out his experience consisted of a single small project he’d done for fun, at work. He was working as a tech support person at a local community college, and one of his main tasks was to help people when they forgot their passwords. So he wrote a tiny database program into which he could record usernames and passwords and email addresses. This consisted of about 6 screens. The PHP code was unbelievably primitive: he didn’t know what functions were, so when he wanted to break up his code into pieces, he put each routine into its own file, and then he would include that file when he wanted to trigger the code. And all the HTML was hard coded into the PHP. Awful. And the poor guy had no idea how much he still had to learn.
We spoke to a woman who said she knew Java, but had no Java projects that she could point us to, not even little demos on her laptop.
Many of the people we spoke to were just moving past the point of unconscious incompetence. They simply had no idea how they appeared to us.
We spoke to a lot of people who were clearly beginners, yet they claimed to know more technologies than I do. A typical list: Javascript, CSS, HTML, XHTML, RSS, Atom, Flash, ActionScript, Java, .Net, C, C++, Python, Perl, PHP, Linux, MySql, Oracle, Microsoft Server, Windows, Apache, IIS, Photoshop, FinalCut Pro, iMovies, Mac OS, and SOAP.
…What a lot of beginners seem to do is they include on their resume stuff they were briefly exposed to during some class in college. So if, for one day, they got to write some SQL queries against a dummy database set up in Oracle, they then claimed that they knew Oracle. I think what this approach communicates, more than anything, is insecurity. I realize that it is tough to get one’s career started, but still, you might want to leave off the stuff that you’ve only had a day or two exposure to.
The more extreme cases can be weeded out with an interview. For the rest, sometimes you can get a sense of who they are if they have a blog. But a lot of the times, it comes down to giving people a try, and see how they do.
There are a lot of decisions where an argument can be made for 2 radically different approaches. I had a conversation this summer, with a programmer who did very good work, about how many databases should be in use on our website. I felt that the right answer was “one”, they felt the right answer was “two”. Part of the site was being built in Symfony, and part of the site was simply a WordPress blog. He argued that putting each application in its own database was “loose coupling”. In this case, I thought it would be a huge headache. We wanted to integrate data from both applications on our home page, and the idea of drawing data from 2 different databases to create our homepage struck me as way too much work. He was aggressive in defending his opinion and he regarded my final decision with a certain amount of contempt. All the same, the programming he did was excellent, and he was very fast, so I’d hire him again for future projects (though I wouldn’t take his advice on architectural decisions).
When I think about the next time I might hire, I think about how I might give someone a try without wasting too much money. I’d like to think that its possible to figure out who is good, and who is bad, after just a week or two of working together. The big challenge is the 6 month wait that Steele describes:
Most folks need six months to settle in, get embedded in team dynamics, and learn enough of the problem domain to be useful.
I try to find tasks that only take a week and which reveal a lot about what kind of programmer I’m dealing with. This is a large-scale version of asking for a code snippet. This worked out well for us when I was at Bluewall and we were looking for a Flash programmer. After I interviewed her, I decided to give a very short, small project to Starrie Williamson. I liked how she handled her first, small assignment, so we ended up working with her for the next year.