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.
Steve Reads 
That gives me the idea that an interesting interview problem might be to use a language that nobody knows (i.e., because you just made it up) and to see what they can tell you about the language based on a few examples, and see if they can write a simple (e.g., FizzBuzz) program in it.
LikeLike
At my company, we do basically that. We ask candidates if they’ve ever programmed in a particular, quite real but widely unused language; if they’ve not, we ask them to write the first pass at a simple well-known Unix utility. It’s a great test.
There’s a second version of this test in which the candidate is asked to debug a pathologically buggy program written in that language. I don’t know if anyone’s actually been subjected to this question yet; it’s devilish.
LikeLike
0 Pingbacks