Drowning in a C of Interviews

The Guerrilla Guide. It is the be-all, end-all of how to look for candidates.

Except for one paragraph.

And I’ve come to realize that I agree with that paragraph; just not Fog Creek’s implementation of it.

In The Paragraph In Question, Joel writes:

I’ve come to realize that understanding pointers in C is not a skill, it’s an aptitude.

The paragraph goes on. But for Fog Creek, it stops right there. In fact, it stops even earlier. The version that Fog Creek has implemented, in practice, reads:

I’ve come to realize that understanding C is not a skill, it’s an aptitude.

Since literally before I’ve joined, Fog Creek has conducted all coding interviews in C. Period. If you want to work at Fog Creek writing nothing but pure JavaScript apps using Node.js, you will do your interview in C, and you will like it. In this one little sense, I became a heretic a few months ago. I quit giving my interviews in C.

And you know what?

Nothing changed.

Well, that’s not true. Candidates were a lot more relaxed, and asked a lot fewer nervous questions about how strict I was going to be about syntax. But my confidence that I could tell whether they would be good programmers, and more importantly, my acceptance rate, didn’t change whatsoever. I certainly didn’t feel like I was losing any data by not conducting my interview in C.

How is that possible? Let’s read through what Joel actually wrote after that introductory sentence:

In first year computer science classes, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their PCs when they were 4 years old. They are having a good ol’ time learning C or Pascal in college, until one day the professor introduces pointers, and suddenly, they don’t get it. They just don’t understand anything any more. 90% of the class goes off and becomes Political Science majors, then they tell their friends that there weren’t enough good looking members of the appropriate sex in their CompSci classes, that’s why they switched. For some reason most people seem to be born without the part of the brain that understands pointers. Pointers require a complex form of doubly-indirected thinking that some people just can’t do, and it’s pretty crucial to good programming. A lot of the “script jocks” who started programming by copying JavaScript snippets into their web pages and went on to learn Perl never learned about pointers, and they can never quite produce code of the quality you need.

If you read the whole thing, you realize that Joel’s not advocating the idea that a candidate must know C; rather, he’s advocating the idea that C forces you to understand concepts that you may not otherwise understand.

Inventing questions that force candidates to understand pointers without using C isn’t too hard. Nearly any question that forces candidates to invent a data structure (e.g., a hashtable, an AVL tree, or the like) will test how they handle indirection, the idea that having a thing is different from having a pointer to that thing. So I’ve picked a question that forces candidates to design a data structure. And, sure enough, I see candidates who have a lot of programming experience, but who don’t “get it”, completely bomb out in my interview.

I think there’s a tremendous amount of value in Joel’s original point. Understanding indirection, and pointers in particular, seems to be innate. But doing interviews in C doesn’t really test for that; it tests for the candidates’ understanding of C. And I think, in our dogged pursuit of that, we’ve probably erred. We’re making candidates nervous about how well they know C, and focusing too much on how well they understand C’s semantics, but not really getting any meaningful indicators back in return.

For the moment, I’ll continue conducting my interviews in the language of the candidate’s choice as an experiment, but I think it’s inevitable that the Wall of C will fall.