Today Joel Spolsky posted and article on his blog “The Perils of JavaSchools” in which he laments that people he interviews use Java to solve the coding problems he gives them in the interview rather than C or Scheme. This is a problem for him because “Java is not, generally, a hard enough programming language that it can be used to discriminate between great programmers and mediocre programmers.”
I think there are several unexamined assumptions behind this claim that won’t hold up when exposed to the light of day.
First, what does it mean to be a great programmer? Is it attention to detail and methodical testing? Is it the ability to hold complex systems in your head? Is it the ability to put yourself in the shoes of a user and really understand the problems they are trying to solve? My guess is that some great programmers have most of these gifts, but most great programmers aren’t great at everything. So if your hiring process only selects for one kind of greatness you are going to miss out on great User Interface Designers, great documentation writers, and all of those other kinds of greatness.
This leads directly to another assumption Joel makes: The problem is that we aren’t weeding out enough of the programmers who can’t handle recursion and pointers. But, he goes on to say that most programming, even most of the programming his company does, doesn’t require those skills. So, what he wants is for most programmers to be great at a kind of programming that most programmers will never get to do. Sounds like a plan a motivation disaster.
As far as I’m concerned greatness isn’t a singular quality that some people posses and others are incapible of — it’s a whole family of qualities, that most of us can participate in if we learn to find the work that lets do what we do best every day — and we focus on making our best better at every oportunity.
Chad Fowler has another take on what’s wrong with Joel’s implicit desire that more programmers would use C or Lisp to solve the problems presented in interviews:
“Why on earth would you want an interviewee to pick a difficult language? Thatâ€™s a bad sign!”
And I wholeheartedly agree. I want interviewees to choose the right tool for the job. They should choose the languages, libraries, whatever they need to make complex problems simple.
Not only that, but you should be auditioning programmers with the same kind of problems you expect them to solve on the job, and expect them to solve them in the same way. So if in an audition, somebody tries to write an RSS aggregator for internal use at a 200 person company that hand-parses XML in C, then I know something is wrong. The performance requirements aren’t there, and their time is too valuable to waste solving problems that have already been solved!