So we’re making candidates nervous by using C, and we’re not gaining anything by using C.

But are we losing anything by using C?

Yes. We’re losing any ability to test for literacy.

“Smart and gets things done” is a famous mantra, and one that I agree with and believe has served us very well. But even at Fog Creek, we don’t go entirely by “smart and gets things done” when it comes to developers. If we did, we’d happily hire anthropology majors who had gotten a few papers published. After all, they’re smart and get things done, right? But we care, at a bare minimum, about one other thing, which is passion for software development. Intern candidates especially may not be the best coders we’ve ever seen, but we expect them to demonstrate at least some proficiency in basic programming tasks in addition to being smart and getting things done. The threshold may not be super-high, but it’s there.

What does this have to do with interviewing in C? Software development, like a few other fields such as mathematics, English, and art, is something you can practice as a hobby even at a very young age. The best coders have to practically fight not to code in their spare time. My girlfriend routinely asks me to get the hell off the computer, I am not kidding, why are you still coding even though work’s over, dammit why does this computer keep working even after I’ve deliberately poured a bucket of water on it, what do you mean you can waterproof things like this because you said you couldn’t when it was my camera, I am leaving you and taking the cats with me, and so on. You pretty much have to pry the machine away from our fingers.

So even young coders, coders with very little experience who make piles of “dumb” errors, have generally written at least a smattering of little hobby projects. They may not be that interesting, and they may be duplicating something that already exists, but they’re there.

As they program more, something magical happens: they start to really get a language. They start to learn the common parts of its libraries, the common idioms used when writing in it. It’s like learning to write English well: you start with the basics, but then begin building an ever-better lexicon as you need to make more nuanced distinctions between concepts. You begin making allusions to other works you’ve read that made an impression. Your writing just becomes more refined, and, eventually, good. Part of your oeuvre.

That’s what I meant by “we aren’t testing for literacy.” If you’re trying to solve problems, especially if you’re a new programmer, you almost have to pick up at least the basics of the library of the language you’re working in. Especially if you’re a college kid, because, let’s face it, college kids are lazy. Any line you don’t have to write is one you can’t have points deducted for, so you’ll lean on that standard library as heavily as you possibly can. You build up a vocabulary of functions and classes and methods that allow you to get more done with less code. You become literate in the language.

If I let you program in the language of your choice, you have an opportunity to demonstrate that literacy. And, because the better you understand the language, the more you can accomplish in a short period of time, the more interesting and complex my interview question can be, too. No longer am I restricted to abstract data-types, like I am in C or some hypothetical Minimal Language You Learn For The Interview. Suddenly, asking a student to sketch an outline of a 6502 emulator becomes a totally legitimate request for a 60-minute session.

Let me take a break here and make clear what I am not advocating: I do not think candidates should have to know their language libraries inside and out. Someone really enthusiastic about programming, but who’s only just getting started, may not understand strcmp even if they’re destined to hack on the Linux kernel for fun, and the next _why the lucky stiff may not yet understand how to make a method take a block. You have to recognize that you’ve got a diamond in the rough there, and evaluate them in other ways.

But for those few who come in and who are super-literate at a language? It’s so fun to do those interviews all of a sudden! I get a chance to be totally blown away by how well you know your craft, you have a chance to be totally creative, and we both get out of the yet-another-data-structure interview question hell (or its lovely variant, how-do-I-get-three-beings-across-a-bridge-in-a-limited-amount-of-time-when-they-all-want-to-eat-and/or-kill-one-another question). Forcing everyone into a language they’re equally (un)familiar with may be “fair,” but it also needlessly penalizes some of the best craftsmen you’ll see.

I’m not abandoning “smart and gets things done” for “smart and gets things done and writes goodish.” But I’d like to abandon it for “smart and gets things done, and is optionally simply awesome.” It’s hard to do that if you restrict your interviews to a single language that most candidates won’t even have used before.

But if you let everyone use their native tongue?

You might be surprised what you’ll find.