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

23 Comments (Show Comments)

1. Alexei (February 15, 2008 at 5:49 am)

   By the way, could you clarify (just in case :)) what is your definition of “cross-browser bug”? Do you mean JavaScript or CSS when you are asking this question? Do you mean some deviation from a standard in which most of the major browsers behave similarly so we can call such behavior “cross-browser bug” or you mean a bug in some particular browser so that we need a workaround to make the code cross-browser?
   Sorry, may be it is just because I am not native speaker of English but having been asked the question in this exact phrasing I would be unable to answer it immediately though I (probably mistakenly) consider myself as having decent experience in cross-browser code.

   Thanks

2. Gilad (February 15, 2008 at 7:20 am)

   Hi John Resig

   First time I bump into jQuery and it looks very interesting. Is it possible to embed jQuery in Firefox’s extension code ? It seems to me a problem because as I understand it runs in the context of the document it is written in.

   Thank you
   Gilad Kutiel
   Quick TransLation (qtl)

3. John Levon (February 15, 2008 at 8:30 am)

   You would seriously hire people who can’t speak the language used by the development team? How the hell do you do code review?

4. Michael Bailey (February 15, 2008 at 9:38 am)

   Is a “cross-browser bug” a bug that occurs in multiple browsers? :)

5. Nathan Youngman (February 15, 2008 at 10:37 am)

   Hey John,
   Thanks for writing out your criteria for hiring. I’ve been doing web development for a decade but never got any sort of degree. Lately I’ve been considering that, mainly because I’ve been doing so much technical reading that “I might as well” be in school. But like MIT, I don’t think the curriculum at the schools I’ve investigated really taylor well to web development.
   – nathan.

6. Ben (February 15, 2008 at 10:54 am)

   I always like hearing what employers are looking for when they interview. I have a question: do you allow interviewees to look up references when you ask them these questions?

   Oh, most annoying cross-browser bug I ran into: Safari didn’t support background images in textboxes.

7. Andrew Stone (February 15, 2008 at 11:04 am)

   John,
   I agree that side projects are a valuable asset for weeding out candidates. However, I don’t think knowing a specific language or technology should have much bearing on an applicant. Most people that know languages as different as scheme and C++ would have little difficulty picking up JavaScript in a short amount of time. I think you are falling into a trap of looking for people with a specific background, which may be exactly why highly qualified candidates from MIT don’t make the cut. They all have the same background.

   I think it is equally valid to hire a candidate with no relevant experience, but who has recently started to teach themselves those technologies, or even new languages such as erlang, haskell, or python. This shows motivation and initiative. I would value that much more than someone who went knows JavaScript well because they learned that in their web-design class at school.

   -Andrew

8. Abe (February 15, 2008 at 11:53 am)

   @Andrew Stone: I agree with you that in general knowing the specific technologies shouldn’t matter much if the candidate has showed ability with different technologies. Good programmers tend to be good programmers in any language. But if the requirement is that the candidate start producing high quality code immediately, however, then you unfortunately have to have working experience with said technologies.

   Overall I also value extracurricular programming experience. It is especially useful for open source projects, but it often indicates a good candidate for a proprietary shop as well. I think it is less important for experienced programmers, though, who can show they have mastered several technologies in their work environment. But experienced programmer with programming as a hobby is all the better.

9. John Resig (February 15, 2008 at 12:02 pm)

   @Alexei and Michael Bailey: A cross-browser bug would be a bug that you encounter when trying to developer a cross-browser application. I typically prefer hearing about JavaScript ones (and then having them walk me through how they solved the problem and came to the solutions that they did) but CSS ones would be fine, as well.

   @Gilad: It shouldn’t be a problem. You can just specify the context for the document that you wish to query, like so:
   jQuery("div", someWindow.contentDocument).hide();

   @John Levon: Sure! Just because they can’t speak it doesn’t mean they can’t read or write it. Of course, being able to understand written English is pretty-much required (although, it’s a safe assumption if they’re already using jQuery).

   @Nathan Youngman: If you’ve been doing web development for a decade then there’s probably very little that a college course on web development could teach you. I’d imagine that if you wanted to learn more about Computer Science then college would be the right place for you. Otherwise, it’s probably time to do a lot more self-education (JavaScript, CSS, etc. books).

   @Ben: Nope, don’t allow them to look up answers. Usually it’s just me, them, and some paper (if they need it). If they’ve brought past code with them then I’ll typically do a code review, asking them questions as to why they chose particular techniques and made certain decisions.

   @Andrew Stone: I’d absolutely agree with “I think it is equally valid to hire a candidate with no relevant experience, but who has recently started to teach themselves those technologies, or even new languages such as erlang, haskell, or python.” I’ve chosen people to interview, based upon this, many times in the past. Of course, showing initiative by learning JavaScript, CSS, and XUL is far more interesting, but initiative through other means can be relevant, as well.

10. Mike Fitzgerald (February 15, 2008 at 12:22 pm)

    Perhaps you’ll soon rescind that statement about good web development not being part of the MIT curriculum, John. :) We started up a web development class and associated competition over the January term this year; it’s looking to become a yearly event:
    http://6.470.scripts.mit.edu/

    We’re also redoing many of the problem sets in the user interface design class that I TA such that they’re executed in Javascript/CSS instead of Java/Swing. It should be an interesting experiment.

11. Nick Quaranto (February 15, 2008 at 12:34 pm)

    Makes me really want to work for Mozilla now. :) John, what’s YOUR favorite cross-browser bug?

12. Peter (February 15, 2008 at 12:56 pm)

    It’s a lot easier to learn a programming language than a foreign language.

13. Wade Harrell (February 15, 2008 at 1:04 pm)

    @Andrew: How many people have you worked with that were hired without JavaScript knowledge but fluent in at least two other languages then thrust into UI development? You comment seems to trivialize the knowledge required to be a good web UI developer.

    First you have to know how to write valid HTML, in itself not a task to be scoffed at, trust me; I have seen some really horrible tag usage. Next you need to be able to use CSS in conjunction with that code; my experience has been this usually results in many “almost got it, but why the hell did you do this bit here” moments in code review. Then, and only then, do you get into JavaScript, which is not only mastering the language but mastering the DOM for manipulating the valid HTML and working with styles (CSS) programmatically. With that knowledge in hand you have the foundation to start learning when to break the “rules” (standards) and how to get 4 different platforms (browsers) of multiple revisions each across 2-3 operating systems performing the same way.

    As I have always told the Java developers tasked by PMs to assist me with that “simple front-end stuff”; there are always 100 ways to solve a problem in JavaScript, about ten of them are good choices, and only two are really efficient and cross-browser.

    Beyond the skills listed above you are also going to want to have some ability with Photoshop for at least minimal production art duties (you really do NOT want the designers slicing images for you, unless they are good coders too). You will need to know at least one server-side scripting/templating technology: PHP, JSP, SSI, RHTML, XSLT, etc. More than likely you will be working with more than one (my current position involves all those listed).

    On paper it seems that someone should be able to cross over on at least some of these points. In practice I think the mindset is just not similar enough to compiled languages for most candidates, and the total package proves to be uninteresting or intimidating to many others. Up until the past few years there was a lot of “coding by instinct” (experience) because of browser issues that kept the candidate pool small, but this is fading away with the libraries. Perhaps this will open up the door a bit more to your line of thinking.

14. Wade Harrell (February 15, 2008 at 1:27 pm)

    John,
    Thank you very much for posting this. The first thing I reflected upon after reading it was how so much learning comes through collaboration with coworkers. Then I thought of how rare that is for web UI development. Out of the eleven JavaScript related positions I have held since ’95 only two had more than one (me) front-end developer assigned to the project. In both cases my skills (and those of the rest of the team as well) grew tremendously.

    Testing in particular I feel is adversely impacted by the one developer per project approach many employers have taken. It is a hard thing to find time to learn about, implement, and use when you are the only person looking at the code.

    So, this gives a great list of things to look in to. Testing of course, and XUL, got the XSL & SVG but no XUL at all.

    Thanks!

15. John Resig (February 15, 2008 at 1:40 pm)

    @Mike Fitzgerald: That’s fantastic news! Now that’s a programming competition that I can get behind. Definitely keep me up to date, all of these changes should make for some great advances in MIT hiring!

    @Nick Quaranto: I have so, so, many. I’ll just pick one of the most recent ones. This isn’t so much a bug as a crazy browser quirk. In Internet Explorer if you bind a setInterval with a time of -1 the interval is no longer executed every N milliseconds, but is, instead, triggered upon clicks of the mouse! You can view a simple demo here (only open in IE).

    As far as my favorite pure cross-browser bug I think it would have to be how Safari 3 handles computed css style on elements that are display: none. Effectively an empty value is returned for every element – however there is no way to determine if that empty value is actually a correct value, or if you’re just being lied to. The only way to do it (as I’ve found) is to check and see what the ‘color’ of the element is. All elements appear to have some color (even iframes, objects, etc.) associated with them so if no value is returned then I assume that we’re dealing with a broken computed style function. Fun times.

    @Wade Harrell: Very well said – I agree completely. Glad to see your interest in exploring more! I definitely think that JavaScript testing is underrated. If there was ever a situation where it was useful it would be in the crazy mad-cap world of cross-browser bugs. XUL is pretty cool, as well. You should check out XULRunner it’s a complete way to deploy XUL (and Mozilla) based applications to the desktop. It’s surprisingly easy to get started and makes for a good playground for honing your skills.

16. Vikram N (February 15, 2008 at 1:50 pm)

    John
    I have interviewed several people for interviews. I definitely agree that communication skills are a must. I am ambivalent on experience in relevant technologies. Although the having required skills gives a leverage, it is not a must. I think that people with the drive to learn and having programming skills can code on any platform or language. Here is an article of hiring case without relevant experience: The Years of Experience Myth.

    Thanks

17. Johan Sundström (February 15, 2008 at 2:08 pm)

    While I’m not sure I’d be able to pick a favourite at the drop of a hat like that (my memory is associative, so unless there is some cues, like having chatted about an area where I know bugs lurk, I would probably come up pretty blank, or state that my favourite is the kind libraries can abstract away completely from the application level programmer :-).

    The partial application article refreshed my recollection of one thing, however, from a time when I set out to craft the ultimate curry method, and noted that the native DOM 0 functions like window.prompt, had very different prompt.length properties across browsers; Mozilla and Opera 0, in some odd browser (it might have been the Internet Explorer of the time; 5.5 or 6) I think it was 1, in Safari it’s 2, and I just checked IE7 and noted that it was undefined. :-)

    Not hard to work around or anything, just annoying, as it made another argument for other languages with curry support worked into them from scratch look better than javascript by comparison, yet again, and sort of ruined the fun of writing an article about it for me. ;-)

18. Wade Harrell (February 15, 2008 at 4:37 pm)

    @Vikram: I would put out there that client-side web development is unlike other programming in there is only about 50% translation from other skill sets. What else is like CSS? What else is like HTML? What else is like DOM? There are answers here, but finding someone who has all of those skills combined is going to be rare.

    Also, in my experience, most developers familiar with other languages complain about JavaScript for, at least it’s perception of, being so unlike other languages. Just the point of browser compatibility concerns sets it apart from most programming experience.

    For me what years of experience means on a resume is focus. I have sat across the hiring table from many failed designers or application programmers that think client-side work is the “easy” way in so they can later get promoted out to their real interest. If I see someone that says they have 5+ years of HTML, DOM, JavaScript, CSS, some templating/scripting languange they are saying to me they are dedicated, that client-side development is their passion.

    In summary, my point is, hiring a PHP/Ruby/Java/C++ developer to code the front end of your ajax application is probably not going to be a good idea because they will not have the experience in a compatible mental toolkit. Maybe a Swing and most likely a Flash developer would fit, but they are not going to apply anyway ;)

    As a caveat, I have worked with Perl developers that did amazing things with business logic in JavaScript, but left all the DOM work to other people on the team. Mileage may vary if you have the resources for that sort of team.

19. Wade Harrell (February 15, 2008 at 4:39 pm)

    favorite cross-browser bug: trailing commas
    favorite cross-browser annoyance: XSLT (client-side)

20. S. (February 15, 2008 at 8:25 pm)

    At the risk of sounding combative, the answer to “I’m glad that you competed in a virtual robot battle competition, but how does that effect your ability to create good JavaScript code?” is almost a tautology. Doing well in a coding competition seems to imply an ability to create good code; presumably that’s why software/finance companies sponsor the competition and hire the winners. Not to say that the indicators you use are bad, or even necessarily worse.

21. Andrew Stone (February 15, 2008 at 10:33 pm)

    @Wade
    I was not intending to trivialize the challenge involved in creating quality UI software. It is obvious, especially after dealing with all the crap out there, that this is no easy task.

    “On paper it seems that someone should be able to cross over on at least some of these points. In practice I think the mindset is just not similar enough to compiled languages for most candidates, and the total package proves to be uninteresting or intimidating to many others.”

    Yes the mindset may be different. But these people chose to apply for the job coding JavaScript. I also stated that motivation and initiative were key. If a person is truly excited about working on a UI project and is a talented programmer, he will pickup the tools of the trade quickly.

    Of course there may be hickups like the ““almost got it, but why the hell did you do this bit here” moments in code review.” But overall you are hiring into a position where the technologies likely will change over the next few years. And typically people want to hire for the long term, and someone who is dedicated.

    Also, scheme is an interpreted, dynamic language.

22. Adnan Siddiqi (February 18, 2008 at 12:51 pm)

    Thanks John for sharing this valuable piece. I agree with you that working on side projects and showing them off to world definitely help by several means. First it’s helpful to learn new things and sometime helpful in making some innovative product. Second website visitors specially employers figure out easily the strength of the person in particular language or skill set. Third there are chances that some company acquire the product and make the person overnight billionaire.

    One thing which might be common that most of people think that working on opensource projects is wastage of time since they are already free and one can’t earn a penny out of it hence better to work on technology which is helpful to earn $$$. How true it is, i think you might be helpful to shed some light on it?

    Thanks

23. Pete Nofelt (February 19, 2008 at 11:14 pm)

    John, I think technology pursuits outside of academic or work requirements is a huge++ regardless of the focus (robotics, javascript, compilers). Most importantly it shows a will and an interest in self improvement.

    You have to acknowledge a certain intangible quality, a gut feeling about someone. Maybe you don’t think they are the model fit, but you can see them flourish in the organization. For example the one time we met at barcamp nyc 2+ years ago, you showed off Juniper Bay products and JQuery. Though I was amazed by JQuery, your work showed me more how you deconstruct a problem than anything else. Because of that, I would have give you a “hire” for most any technical occupation. Not necessarily assuming that you would succeed, but giving you the chance to.

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.