This is a repost of an old article i had written in 2012 on Posterous shut down

I was recently invited to an interview by a well respected internet company in Bangalore to interview for a web development role. I thought this would be a good opportunity to have a reality-check of my JavaScript skills.

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!).

The List

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:

  1. Scope
    Candidates should instantly explain what scopes a variable can be in. Its easy, and fundamental.
  2. Closures
    Closures are the most powerful aspect of JavaScript  They are a key enabler of much of the design patterns in, dare i say, new JavaScript. Other languages have closures, but JavaScript’s syntax is so succinct and intuitive its almost criminal not to use it. Candidates should know the key property of a closure, and hopefully demonstrate a few different use cases. If they can clearly explain the difference between anonymous functions and closures, that’s very good.
  3. Classes
    Javascript doesn’t really have classes, it mimics them using function objects and some ‘new’ magic. If candidates cannot create classes, they cannot write safe reusable code or use design patterns and thus are significantly restricted in writing APIs.
  4. 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.

More on this list

I usually add more questions to the interview based on the candidate’s experience and my requirements. Some other useful questions are :

  1. 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.
  2. Foreach
    Due to the prototypical nature of JavaScript, all of the properties of all of the objects in the chain show up in the foreach loop (even a function is a property of an object).
  3. 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.
  4. 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 :

    1. it doesn’t test for programming skill and, more importantly,
    2. is very easily found on the internet.
  5. apply and callee
    These are useful for some forms of dynamic programming. If they know it, very good.
  6. 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.
  7. 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”.

PS : If you haven’t watched Crockford on JavaScript  be sure to. Its the most relevant material you’ll learn about JS in any video.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s