Rock Hymas

In Drowning in a C of Interviews, Benjamin points out that he doesn’t see much value in doing interviews exclusively in C. Additionally, he believes that “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.”

I have a different take on our interviews. Though I haven’t done as many interviews here at The Creek as Benjamin, throughout the last intern hiring seasons I saw a sum total of one candidate that actually suffered in an interview from not feeling comfortable with C. While I agree with Ben that allowing the candidate to code in the language they are most comfortable with won’t really change how many candidates get the “hire” decision, I do think there are some benefits to interviewing in C that we might lose.

It will help to step back and consider what we are looking for at Fog Creek. Our listing for a software developer position has this to say about what we’re looking for:

Right now we use C#, JavaScript, XHTML, CSS and even Wasabi (an in-house .NET language) to develop FogBugz. Kiln uses C#, JavaScript and Python, Copilot uses C, C++ and Objective C, and we have some legacy code written in VBScript. Tomorrow we may be using something completely new.

Whatever technologies, languages, or development environments you’ve been using, we expect you have mastered them in depth, and we expect that you will be able to master any technology, language, or development environment that we need in the future.

So we’re really looking for two things. First, do they code enough to have mastery in the languages they are most comfortable with. And second, can they use an understanding of broader principles to quickly learn new languages and technologies.

If we always let candidates code in their language of choice, we’ll be testing more for first quality. As such, we’ll want to dive deep into the way things are implemented, different ways of using the language to tackle the problem presented, and we’ll expect that the code is both syntactically and semantically correct. We would only get indirect hints as to the second quality - if the candidate can handle the problem itself then it means they can learn quickly on a small scale, and it most likely means they have a good grasp of the principles required to quickly get up to speed on a new language. But that’s not a guarantee.

If we did all our interviews in C, then, for most candidates we’ll be testing for the second quality - their ability to get up to speed in a language they don’t use on a regular basis quickly. They may be familiar with C, or may not, but they know we interview in C, so they can prepare for it. I specifically request that candidates code in C or C++, and while it is generally easy to see who is comfortable with it, it’s also fairly easy to tell who picked it up recently and didn’t have any problems with the question. I get excited about these candidates, because I know they can pick up new technologies quickly. I get (slightly less) excited about the ones who are obviously comfortable with C and do well on the actual question.

I can think of two interesting third alternatives to the “all in C” vs “pick your language” debate. One would be to work for a good mix of interviews in a language the candidate chooses with interviews in C, the “desert island language”. That would allow candidates to show off mastery of their tools of choice as well as the ability to work well outside of those tools. And since Ben stopped doing his interviews in C, I guess I’ll have to keep doing mine in C. Especially since his blog post will probably convince a couple other guys here to give up the C requirement. And besides, it makes life easier for me.

Another option would be to use a relatively obscure language, or one we make up (Wasabi, anyone?), in place of C for part of our interviews. We could test for mastery of the tools they use by having them code up the solution to a problem their own language of choice. Then we give them a different language, possibly with a fundamentally different paradigm (OO vs functional vs procedural, etc.), and have them code it up again. At this point, they understand the problem and solution fairly well, so they’ll be more fully demonstrating their ability to learn a new language and write code in it.

I’m not totally happy with either of these options, but they can certainly add to the discussion we’re having at Fog Creek about how to find and interview developers who want to help all developers make better software.