I got a mail the other day from a co-worker who asked, essentially, “Do you have tips for interviewing senior developer candidates?” I accidentally a whole long thing, so here it is in its entirety, with names changed because I really like the name “Zeke” and don’t get to use it much.

Hi, Zeke. It was interesting to see the other day that Google analyzed their interview practices and found exactly zero correlation between interview performance and performance on the job. So don’t do what they do. :-) Typically, they ask some really tricky questions—it often seems like the interviewers are using the interview as an opportunity to show how clever they are.

I can’t tell you if my method works, either, but I’ve had very few regrets in hiring. In short, I interview for the basics: I don’t care if you can balance a red-black tree, because nobody ever does that in our work, and you can always look it up. I just want to know if you can rub two lines of code together (fizzbuzz, which I do during initial screens), pick some sane tests (usually I make them write tests for fizzbuzz, which makes them refactor it to use generators or whatever), and understand the rough performance characteristics of a dict. Anything else is a bonus. I guess my overarching criterion is “Would I let this person loose on my project?”

My goal during an interview is be convinced that the candidate is awesome, and I act as a facilitator to help him or her convince me. The best sort of interview is the sort I had with you. I saw an interesting project on your resume (your web-based SNES emulator) and just let you expound on it for half an hour, asking probing questions here and there. In the course of that conversation, you made clear that you understood hash tables, client/server design, and even hardware architecture. That was really ideal.

The worst sort of interview is the quiz-show sort, which, in its purest form, can feel adversarial and artificial. This sort even offends some very senior candidates. (Though I’ve had some “senior” DBA candidates be offended at simple SQL questions and then utterly fail them, so don’t take offense as a proxy for expertise.) I’m sorry to say that about two thirds of my interviews do degrade into a quiz show, and that generally indicates a lack of preparation on my part. When I have time, I Google-stalk the hell out of the candidate and try to find at least one relatively complex project of theirs to pick on, like your SNES thing. The earlier in the interview process somebody thinks to ask “What’s a piece of code that you’re proud of?”, the easier this is. Ask it in a screen, and it can inform all subsequent interviews.

Here are the areas I like to cover over a series of interviews. Pass all or most of these, and I am happy to let you loose on my project:

• Basic coding (fizzbuzz, refactoring). This focuses hard on the ability to put things into good categories: do they split up code into functions that represent compact concepts so they’re easy to understand and reusable? Do they pick good names?
• Testing sanity. Do they write the minimal number of tests to find the likely bugs, or are they just all MOAR TESTS ARE BETTER BWAAAAHHHH!?
• Ability to navigate the open-source world. Can they write so they can be understood on a mailing list, IRC, or a wiki page? Can they take feedback and give it? This is an easy “pass” if they have a history of open-source contirbutions, but not everyone has that luxury.
• Multi-machine architecture. Can they put memcache in the right place on a block diagram? Know what the plusses and minuses of DB replication are? Have some idea when and how to index something? This doesn’t require large-volume experience—I myself just had a history of crappy servers that couldn’t keep up with load.
• Have heard of the web and grok request/response
• Have some passion and opinions. I don’t want a pushover who won’t add anything to decisionmaking. I sometimes try to start a fight about editors or languages or something to uncover this.

Then I like a candidate to have one or more areas of deep knowledge:

• Fancy-pants algorithms. I’m into string algorithms right now. Somebody else might be into distributed data structures.
• Intimate knowledge of some data store, like an RDBMS or HBase
• Mad JS, DOM, or browser chops
• In-depth knowledge of Django or some other framework we use

If they pass that first list and have one or more from the second, they’re a great addition to Mozilla IMHO: they can start making stuff almost immediately, and, even before they get to know their project, they can act as an advisor in their areas of expertise from the second list.

Hopefully this comes off as useful to somebody, even if it’s just the people I’ll interview in the future. At the very least, it made me get my thoughts about interviewing in order.