This is a repost of an old article i had written in 2012 on posterous.com. Posterous shut down
But when the JS expert began questioning he perplexed me. Not because his questions were too difficult. But because I couldn’t help but feel burdened by the sheer uselessness of his questions. They were in no way helpful in finding candidates useful for real world development. Here’s one. “What is the exact name of the function of the XHR object that sends the request to the server? The exact name!”. The answer would either be ‘send‘ or ‘google‘. And they both work in the real world.
The interview continued and I continued to feel depressed. These kinds of questions never test the API writing ability of a potential hiree, just their memory at that point of time. API writing skills are key to writing good reusable software (I’d argue in most commercial development domains, but I’ll restrict my argument to the domain I’m most familiar with, web).
Back home I decided to do a bit of a thought experiment. “What would be a good set of questions to ask if I was in-charge of hiring a JS guy”. This was primarily to self-test my thoughts and past interviewing experience, but with feedback from the real world (please leave a comment!). And, possibly, to guide and inspire the JS posterity (again, please leave a comment!).
So here’s the list. It’s neither scientifically precise nor prophetically visionary. And it’s short. As an interviewer (whether full time, or just taking part) you want to spend minimum time extracting maximum useful information. These questions are not overly specific to any particular API, trick, esoteric feature or even design patterns. They’re general, more like stuff you’d expect your JS guy to know already. This will help you filter out guys who are possibly good candidates, whom you want to interview face to face.
Here it is:
Candidates should instantly explain what scopes a variable can be in. Its easy, and fundamental.
- Prototype Inheritance
JS has nothing of the classic OOP style of inheritance. Make sure they can explain how it works, with examples. Ask about constructor prototyping as well.
And that’s it! Notice that I haven’t mentioned anything about the DOM, JSON, AJAX, Event Handlers or buzzword of the month. That’s because most people would have made an AJAX call, received JSON and updated the DOM.
I usually add more questions to the interview based on the candidate’s experience and my requirements. Some other useful questions are :
- Difference between a null, undefined and NaN
The difference between a null and undefined is important. NaN doesn’t belong in the same set, but they should know.
- Basic Regex You always want your candidates to know some form of regex. We usually hire candidates with a mix of PHP and JS skills, so we’ve already asked regex during the PHP part of the interview. If that’s not that case with you, be sure to add this in.
- setTimeout and setInterval
These functions are the building blocks for timing/scheduling code in JS. I almost included this in my first list, but I figured :
- it doesn’t test for programming skill and, more importantly,
- is very easily found on the internet.
- apply and callee
These are useful for some forms of dynamic programming. If they know it, very good.
- Some specific examples of browser incompatibility
I believe this area is fast fading with Internet Explorer catching up and already covered well by frameworks. But it’s a popular question and it shows a commitment from the candidate to dig down.
- Patterns and private properties
Knowledge of the Module pattern is very useful, as is the trick of creating private (or rather, invisible to the public) properties. If the candidate can explain this, great.
This list is by no means complete, but you should be able to pick off it and come up with your own questions.
Talk the talk and code the walk
Verbal questions are just a way to help filter wheat from chaff. There’s no substitute to candidates showing written code, whether from their previous work or open source contributions.That may seem subjective, but we’re craftsmen and craftsmanship is subjective.
I hope this list helps you find better candidates. If you’re a JS coder its always nice to have to look up a list and “fill in the gaps”.