Interviewing for Open Source

I’ve had the pleasure of interviewing a number of people to work for Mozilla and plenty of developers for the jQuery core team. There’s a lot that I’ve learned about what makes a good candidate and I’d like to point it out, as it’s generally quite different from most organizations looking to hire. Also, even between the two Open Source projects, the qualifications for a good candidate shift wildly – however there’s a lot that’s quite similar, and should be outlined.

Education, grades in school, extracurricular activities, and age have very little bearing on what makes for a good candidate. None of those have ever been a factor in any of my choices for an interviewee.

We’ve had contributors to jQuery aged all the way from 15 to 65. Stuart was hired by Netscape to work on the Mozilla project straight out of high school (which was actually detailed in the documentary Code Rush). Age is rarely relevant, as long as you can produce good code and work well with your teammates.

I don’t think education has ever been a deciding factor, for me, in an Interview. Due to my location (in Boston) I end up talking with lots of MIT students (both under-grad and graduate). It’s almost a given that their grades are good and that they’ve done well in all the required classes. This means that everyone knows Scheme, Java, and some C++ – which doesn’t help you tremendously when shooting for a position developing the Firefox frontend (which is JavaScript, CSS, XUL – maybe a pinch of C++ – and is generally what I interview candidates for). Because of this I tend to look for candidates who’ve put a lot of effort into extra research positions or side projects.

I’m always surprised by the number of irrelevant extracurricular activities that people put on their resumes – and the number of “awards” they’ve received. These mean virtually nothing to me. I’m glad that you competed in a virtual robot battle competition, but how does that effect your ability to create good JavaScript code? This ends up weighting very poorly against outright experience.

Conversely, experience and initiative have a huge amount of power over an applicant. If you’re able to demonstrate that you’ve devoted large amounts of time to building side projects (especially when they’re Ajax-y web applications – PHP, Ruby, Python, Perl – all good). Since most of the people that I talk to for Mozilla are coming from MIT they all end up being amazingly similar. The deciding factors for a candidate come down to how they’ve gone beyond the basic program and excelled. This is especially important since good web development skills aren’t seemingly taught in the MIT curriculum, which is a shame.

Location and native language can matter, depending on the project. Mozilla, for example, is a highly distributed organization, however some teams (like the platform team) tend to work mostly in Mountain View, CA. Additionally, due to frequent meetings and communication, being able to speak and understand English is incredibly helpful. On the other hand, for jQuery, location is not a factor at all. The jQuery team has only met once (and there’s some team members whom I still haven’t met). Much like Mozilla, we’re distributed across the globe – Germany, Florida, China, California, Romania, Colorado, Australia, and on, but we don’t have a central base. Being able to speak English is much less of a concern for us – we’re more open to letting your code speak for itself.

Manning the booth at a recent MIT Career Fair.

Since I end up looking at, primarily, most candidate’s JavaScript skills I tend to break down the topic into a couple areas:

JavaScript Language: Good knowledge of the language – an understanding of its functional aspects and prototypal inheritance are usually the most that I can hope for.

Cross-Browser Code: Writing effective cross-browser code is incredibly difficult and can be a good way of marking a proficient JavaScript developer. One of my favorite questions to figure this out is “What is your favorite cross-browser bug?” – either the candidate has like 20 answers or doesn’t know what I’m talking about.

Testing: Having test-backed code is pretty common in software development but still in its relative infancy in the land of JavaScript. Developing JavaScript tests, using a test suite – or even having written your own suite – score big.

For Firefox Frontend Engineers, in particular, I also tend to look at the two other core aspects: CSS and XUL.

CSS: It’s surprisingly easy to weed out people who do, or don’t, know CSS. Ask the question “What’s the syntax for making all paragraphs on a page red.” If they aren’t able to give you some combination of “p color colon red” then it’s time to move on. If they handle that then it’s good to explore CSS property manipulation in JavaScript, making sure they have a good grasp of that.

XUL: By far the most challenging skillset to find. Oftentimes when I actually interview a candidate that has XUL knowledge they’re more proficient than I am. However, most people aren’t familiar with XUL so I tend to explore topics like XML, XPath, XSLT, and SVG. Having good knowledge of any of those is a big win.

If nothing else it should be noted that I care a lot about hands-on experience, especially when it comes to JavaScript and web-related technologies. Showing that you’ve proven yourself through hard work is immensely more valuable than having gotten good grades in some un-related programming class. I tend to think that this emphasis on producing real results is sort of the cornerstone of Open Source development and is one reason why I am especially happy to be completely immersed in it.

By the way, at Mozilla, we’re always looking for awesome developers. If you’re a top-notch web developer, maybe you should consider taking the leap into Firefox development. The territory is completely familiar (JavaScript, CSS, XML) but the output is absolutely different: An application used by over 150 million people. Tell them I sent you and I’ll put in a good word for you.

Posted: February 15th, 2008

Subscribe for email updates

23 Comments (Show Comments)

Comments are closed.
Comments are automatically turned off two weeks after the original post. If you have a question concerning the content of this post, please feel free to contact me.

Secrets of the JavaScript Ninja

Secrets of the JS Ninja

Secret techniques of top JavaScript programmers. Published by Manning.

John Resig Twitter Updates

@jeresig / Mastodon

Infrequent, short, updates and links.