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.