FAIL: Virtues of a Programmer

In the second edition of Programming Perl, Larry Wall famously outlined the Three Virtues of a Programmer:

1. Laziness — The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful, and document what you wrote so you don’t have to answer so many questions about it.

2. Impatience — The anger you feel when the computer is being lazy. This makes you write programs that don’t just react to your needs, but actually anticipate them. Or at least pretend to.

3. Hubris — Excessive pride, the sort of thing Zeus zaps you for. Also the quality that makes you write (and maintain) programs that other people won’t want to say bad things about.

Besides the humor, anyone who has seriously slung code for a living connects with the three virtues. Programmers very often do have a wonderful kind of procrastinately excitable arrogance that enables them to do remarkable things. I like to say, “A programmer is both the laziest and hardest-working person on the planet — nobody works harder to find the easiest way to do something.”

But when it comes to the job of interviewing, the three virtues are dangerous. I hate to think of all the mistakes made by companies who let untrained programmers interview candidates; if you could convert all those missed hires to ROI, it would most certainly scare the crap out of the CTO. But it’s still prevalent, and not just at the usual suspects like Google and Facebook. It’s alive and well at startups, too.

Maybe it’s getting worse. Over the last several months I’ve heard more complaints than usual from engineering friends and associates about their interview experiences. And Glass Door seems to be full of stupid code problems and bad experiences from interviewees. It’s always the same: A small team of one or more programmers show up to conduct an interview. They’re a little late, somewhat nervous and dispense with small talk as if it’s a virus. They’re not into answering questions about their company, can’t talk in detail about what they’re working on, and need to look at their phones whenever possible.

Then it comes: Ye olde academic probleme. It’s a fairly rote, perhaps even difficult, [typically] algorithmic problem that has little or nothing to do with their day-to-day software engineering. In fact it’s a safe bet that the programmers giving the problem couldn’t work it themselves if they’d hadn’t recently played with it. To top it off they want you to code it up on a whiteboard (or worse, over IM/video chat).

It would be laughable it wasn’t so bad for the job seeker — and if it wasn’t so bad, ultimately, for the company looking to hire (especially startups).

First off, it’s patently absurd to ask a programmer to code something on a whiteboard. Design? Sure. Program flow? Fine. Basic approach to solving a problem? Okay. But solving an academic problem, on-the-spot, with pseudocode? Ridiculous. Programming is as much art as science and programmers need time to think, write, run and debug problems, especially difficult ones. They need to be in the zone — comfortable, engaged, with their tools and libs (and functions they stopped re-writing years ago that they now simply copy and paste) by their side. This is the case for every programmer I’ve ever worked with, from CS majors to Phd’s to the self-taught liberal arts majors, dropouts and homegrowners with no formal education.

Second, the code problem(s). Just why are they so academic? Other than maybe someone who is fresh out of college with no substantive personal code base, who among us actually rewrites a sorting algorithm from scratch,  or revisits an LRU cache problem for fun, or proudly displays our awesome linked list skills, or spends our evenings re-hashing time complexity for that old Connect Four or Game of Life problem from school? (Note: I’m not suggesting that time complexity isn’t super-important, but you don’t have to know how to write the Wikipedia article on Big O to understand it). But even if you know the problem ahead of time, can you really code it up nice and sweet, in something resembling workable code, in 10 or 15 minutes — in an interview, on a whiteboard? (Especially if you’re already coding for a living every day anyway?)

I could go on but you get the point. I’ve interviewed lots of programmers over the years and I’ve never put them through the above rigamarole. The best code test is given to the programmer before the interview, basta. The best evaluation is looking at real code that compiles. The best person for the job is almost always the engineer who is a great general problem-solver — he or she is far more valuable than rote language skill or recent exposure to a specific problem or class of algos, for example. Sure there are exceptions and times when you need more of a code-chimp — a trained warrior — than anything else, but 99% of the time you need wizards and mentalists and thieves. Those are the guys and gals who get things done, are constantly improving, and who work with or without a paycheck. You just have to teach them how to be good interviewers.