Interview

The language of interviews

 

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).