John Resig - Interviewing for Open Source

John Resig - Interviewing for Open Source

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.

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.

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.