gistfile1.js

// For each of the following code fragments:
//  a. what does the code do?
//  b. what did the author intend for it to do?
//  c. how would you fix it?

// 1. list of links 
var p = document.createElement('p');
for (var i=0; i<10; i++) {
    var a = document.createElement('a');
    a.innerHTML = "link " + i;
    a.onclick = function() {
        alert("you clicked link " + i);
        return false;
    };
    p.appendChild(a);
}
document.body.appendChild(p);

// 2. method callback
var bob = {
    firstname: "Bob",
    greet: function() {
        alert("Hi, I'm " + this.firstname);
    }
}
window.onload = bob.greet;

Ahh a couple of classics...

thanks xavi :)

Number 1 is pretty much exactly how I learned about closures!

yep - ahhh memories ....

Over the past couple of weeks, I've tested this problem on a couple of people -- some co-workers, some real interviewees. The general response has been positive, but there have been a couple of hiccups that IMO should be smoothed out:

Question 1 -- Interviewees immediate look for a cross browser issue. They say things like, "I don't think innerHTML is supported by IE". IMO this is distracting. It leads the interviewee down a blind alley, and it doesn't give the interviewer any useful information about the interviewee. There are two ways to address this issue: use jQuery or don't touch the DOM. Which way do you think is better?

Question 2 -- Some feel the question is a bit too tricky. IMO it's a fair question, but I'm curious what your opinions are.

General Observation -- I feel the first question is too hard. It makes people too nervous when they can't immediately answer the first question. I think a third easier question should be introduced to help make interviewees more confortable. Any ideas what it should be?

Over all I'm happy with these questions. I'll definitely continue using them in the future.

**PROTIP_: if you're doing a phone interview, use xavi.co/interview. I combined this gist with a crappy version of etherpad. Simply clear the text area at the bottom of the screen, past in the gist from above, and ask the interviewee to fix the code infront of you. You should be able to see character by character changes._

Hi Xavi,

Re Question 1: I've also had people start thinking cross-browser when presented with the problem, and I think there's a third option. Maybe there should be a note in the instructions that says "these code samples work exactly the same in all browsers". I would not say that it doesn't give the interviewer any useful information about the interviewee however - it tells the interviewer, "this person doesn't even understand innerHTML, so look out!"

Re jQuery vs DOM: The point of these questions were to test non-library JS chops, so jQuery would not be appropriate (IMO). It's perfectly fine to ask jQuery questions if that's a skill you're hiring for, but I'd be hesitant to accept a library based solution to questions (except as bonus). Understanding the var lookup chain is absolutely critical to writing effective JavaScript. jQuery helps by creating scopes due to its functional nature, and I expect a JS pro to be able to use these tools effectively, and also get by without.

Re Question 2: It depends on who you're trying to hire. Are you trying to hire someone who already knows JavaScript? or someone who is decent at programming and has the capacity to learn it? If you want someone who's going to be effective with JS on day 1, they must be able to read, digest and improve this simple code fragment.

Re General Observation: That's a fair point - maybe we need more questions. Maybe asking fizzbuzz would be a good way to start. Then how about this: "write a function that returns a function". That should weed out just about everybody. Or: "write code that iterates over an object's properties". These are trivial JS questions, but are bound to stump quite a few candidates.

Currently, this gist checks if the interviewee can read, debug, and fix code. With that in mind, I feel the fizzbuzz question should look something like this:

var data = [ { high: 100, low: 81 }, { high: 93, low: 73 }, { high: 60, low: 32 } ];
function getAverages(data) {
    var avgs = [];
    for(var i = 0; i < avgs.length; i++) {
        avgs.push(data[i].high + data[i].low / 2);
    }
}
getAverages(data); // returns [];

This question tests if the candidate understands object/array literals, for loops, and function calls. Though, I'm a bit concerned that it's too basic and that the bugs are too subtle (especially the missing parens on line 5). Thoughts?

Yeah, I guess it's hard to test a "pure" question. The question you just poses also tests object literal and array literal notation. I still run across people that use new Array().

I don't think the order of operations bug is too subtle - I would expect any developer that's familiar with C-style syntax to pick up on it.

I think it's a pretty good question! Maybe the right approach is to start with questions that test just one thing (if that's even possible), and then graduate to questions that test multiple concepts. The trouble you run into there (if it can even be considered trouble) is people learning from early questions language semantics that help them later on. Then again, if someone has only ever seen new Array(), and learns from question #1 that [] does the same and is then able to incorporate that into their thinking to solve problems #2 and #3, that may be enough of a positive to warrant the hire.

Again, it depends on what you're hiring for - do you want somebody who's already a rock star, or someone who has the potential to become one. If I had my druthers, I'd only hire the former - let my competitors train recent college grads, then encourage them to trade up to my company. :)

Haha, I like the idea of trading to a company.

I'm going to fork the gist and make the changes we talked about: add the browser compatibility note and add the easy first question.