An incomplete list of things you want from programmers — June 7, 2010

An incomplete list of things you want from programmers

Lest I be accused of being an entirely negative person when I document the difficulty of hiring software developers, let me enumerate — in roughly increasing order of desirability — a partial list of what one wants from developers:

* understand basic syntax in at least one language
* quickly absorb the rudiments of a new language
* quickly program idiomatically in that language
* use algorithms and data structures that reach a solution to your particular problem before the heat death of the universe, using a computer smaller than the Chandrasekhar Limit
* write literate code that you and others can understand months later
* know how to test your code so that you’re not handing QA a steaming mess
* be a good mentor to other developers, which means being a clear thinker and a clear speaker
* debug often mysteriously dysfunctional code
* know when it’s okay to be sloppy in your code and when it’s not
* quickly learn the set of available solutions to the problem before you, know how to compare them, and defend your chosen approach rationally
* take an ill-formed problem and fill in the details enough to start writing
* understand customer needs and turn them into a plan for a program
* understand customer priorities and reflect those in your day-to-day work, strategically cutting corners when it doesn’t deflect you from your path

By no means can I claim that I do all of these, or even do most of them most of the time; I’m still learning, and I expect that most candidates will also be learning. (Maybe “be able to pick up any of the items on this list that you don’t already know” should be the final bullet?) My point is that it is hard to screen for these things during a standard few-hours-long interview, or even during the standard interview+phone screen+coding sample process. Though it would be valuable, and probably not very difficult, to test for more of these during the interview. As it stands, most interview questions address the first couple bullets — or test your ability to repeat the stock answers to stock questions (“My biggest challenge was when I tackled [insert puffed-up big project]; my perfectionism nearly got the best of me, but I persevered”). What’s remarkable is that so many people get the trivial/stock questions wrong. Hopefully we’ll eventually move beyond those questions and start grilling developers on what really matters.

I finally had my first exposure to programmers who can’t program —

I finally had my first exposure to programmers who can’t program

This sort of madness is apparently commonplace. I had never directly encountered it, so I was shocked when I interviewed someone today who was incapable of performing a basic programming task. This was someone with a master’s degree from a prestigious university, and he couldn’t code something that you should be able to write as a freshman in college. Fortunately it only took, by my estimate, $18.07 in salaried time to screen him out: I put him in front of the excellent See[Mike]Code after a few minutes of pleasantries and “what would you like to know about our company?”-type questions, watched him fail to code, and ended the interview. During in-person interviews, we “fail fast”: if the first interviewers raise a red flag, they relay this to the second pair of interviewers; if the second pair of interviewers is negative or only neutral, we show the candidate the door. I’m now inclined to fail phone-screen candidates fast: program first, talk about the company second.

I’ve thought for a very long time that the hiring process is largely a *negative* affair: it establishes those people whom you screen *out*, but it doesn’t do a very good job screening *in*. You filter out the obviously incompetent programmers. Then you filter out those with bad social skills. Then you filter out those who fit badly with the company’s culture. You still may end up with disasters. At my company, we give candidates three to six months to prove their mettle even after we hire them, which is (it seems to be) an admission that the hiring process is imperfect.

In large, advanced market economies centered around anonymous transactions, you avoid some of these problems with credentialing organizations like universities. The assumption is that (apart from MBAs, which I gather are high-cost multi-year networking events) a prestigious school wouldn’t just put its stamp on anyone. After today, I’m not at all convinced that that’s true. I want to call up today’s candidate’s master’s-thesis adviser and demand that he pay me $18.07. Perhaps that would start shifting the incentives the right way.