When I interview someone, I usually let them use the language of their choice
with between C, C++, C# and Java. There are several reasons for that:

  • I want them to be comfortable.  It’s already hard enough to be in
    an interview, much less being forced to use a syntax or an API they are not
    familiar with.  Of course, I don’t pay too much attention to syntactic
    details or making sure they use the right method name as long as the logic
    of what they write is sound.
     
  • It’s not that I have something against Ruby or other fourth generation
    languages, but I found that these languages work at a level of abstraction
    that is a little too high to give me a meaningful insight on the candidate
    for a forty-five minute interview.  There are plenty of very
    interesting problems that are hard to solve even in Ruby or Python (and
    actually, it’s quite likely this is the kind of problem that the
    candidate will be struggling with if she gets hired), but formulating the
    question and writing the solution would take several hours.

The real challenge is therefore to find a problem that is very easy to
express and which solution in one of the languages mentioned above will give me
enough information on this candidate to formulate a verdict.

Interestingly, the choice that the candidate makes already reveals a few
things on their abilities.  I found that typically, C/C++ people tend to be
very comfortable with low-level algorithmic questions ("pointers and recursion",

to quote Joel) but fare very poorly as soon as we "move up the stack"
(object-oriented design, design patterns, enterprise frameworks, etc…). 
Conversely, Java/C# people are more comfortable with these concepts but get
easily stumped on "tight memory" types of questions.

Of course, great candidates excel at both, which brings me to my next point.

Good developers are born good.  Their brain is wired a certain way and
they can chew on any CS concept thrown in their direction and spit it out with a
bow tie.  Most of these developers then go to school and move from the "gem
in the rough" state to that of a "pure diamond".  School accelerates and
expands their knowledge.  Of course, there is hardly anything they learned
in school that they couldn’t have learned by themselves, but the formal process
of learning, reading book and listening to teachers saves them years and years
of work.  It also expands their minds to concepts they would probably never
have encountered in their professional career.

With that in mind, I find Joel’s obsession on pointers and recursion quite
baffling.

There are two important facts to keep in mind about pointers and recursion:

  1. They are important concepts and any serious developer should probably be
    comfortable with them.
  2. You will hardly ever use any of these concepts for today’s typical
    programming jobs.

How’s that for a paradox?  How do you interview for this?

Well, it’s actually very easy to do a quick check on pointers and recursion,
even in Java, but it’s equally important to spend most of your interviewing time
on other areas that are more relevant to the job the person will be asked to do. 

One of my friends pointed out that what we are seeing today is a more
distinct separation between "system programmers" (kernel, device drivers, etc… 
which require C/C++ and pointer juggling) and "application programmers" (for
which pretty much any programming language will do, including Visual Basic). 
What’s really puzzling is that Joel’s company produces a bug-tracking software,
and it’s hard to imagine why you would need an army of superstar programmers .  A few selected senior tech leads and designers?  Sure.  But
an entire team of them…  doubtful.

As for Joel’s reference to Paul Graham’s vastly over-hyped essay
"Beating the Averages", I am
still trying to decide which of the following two quotes is the most ridiculous:

  • His start-up had an edge over its competitors because of the
    implementation language they chose.
  • Because of this choice, they were able to implement features that their
    competitors couldn’t.

Actually, I’ll call that a tie:  both claims are equally preposterous.

Paul Graham has been a dinosaur for a long time and his disturbing elitist
stance ("if you don’t know Lisp, you’re an idiot") oozes from every paragraph of
every single programming essay he has ever authored.  So far, Joel had
managed to remain reasonably objective and interesting in his posts, but his
extremely narrow background (Microsoft technologies in C/C++ and bug-tracking
software) is beginning to take a toll on his objectivity and I find that most of
his writings are more and more missing the big picture.  I hope he’ll turn
around soon and open up to modern programming topics, because frankly, I am
having as much fun using Ruby on Rails or Eclipse and EJB3 today as I did
writing
Copper list based demos on my Amiga fifteen years ago or coding floppy disk
drivers in 6502
on my beloved Apple ][ twenty years ago (gasp).