How to Conduct a Fair and Meaningful Technical Interview

When I began searching for my first job as a web developer, I applied to, and received interviews with, several companies. Some of my interviews were with Fortune 500 companies; some of my interviews were with fledgling start ups. Regardless of the size of a company, the interview process was very similar: phone screening, technical challenge, and cultural screening.

The technical challenge informed me about a company’s character. If the questions being asked were fair and meaningful, then I, regardless if I passed or failed the technical interview, would leave with a favorable impression of a company. At worst, I would leave without a job but with some new and useful knowledge.

If the questions I was being asked were out of the scope for a particular position or merely a trick, then a company risked alienating me and other applicants. I can still recall an interview I had with a CTO of a start up in Manhattan, New York. This person asked me to describe the difference between prototypal inheritance and prototipal inheritance. The second inheritance pattern didn’t exist. After my interview, I talked to a few of the other applicants, and we all agreed – we would never work for that company.

So what’s considered fair and meaningful? Fair is considered asking questions that are appropriate for an applicant’s prospective position. Meaningful is considered asking questions that reveal some level of understanding of a fundamental concept. When a question is fair and meaningful, both the interviewee and interviewer benefit.

I believe that both of these objectives can be meet with these three concepts:

Callbacks
Binding
Event Emitters & Inheritance

Each of these concepts are integral to a web developer’s knowledge; these topics, however, are disconnected enough to give an interviewee who incorrectly answers a question an opportunity to correctly answer the other questions.

A rubric for grading a technical interview is located after these three concepts.

Callbacks

Interviewers should always ask an interviewee to define a concept. This initial step confirms that the interviewee understands what’s being asked. If the interviewer fails to ask this question, then the interviewee should volunteer to share their understanding of the concept. Without a mutual definition, the interviewee is unlikely to solve a given task.

After a mutual definition is reached, the interviewer should present a question involving code: I want to explore your understanding of callbacks, so please create an implementation of a well-known function called reduce. At this point, the interviewer should present an invocation of reduce with example input and output data.

// input
reduce([1,2,3], function(total, value) {
  return total + value;
}, 0);

// output 
6

Prior to an interviewee creating their implementation, an interviewer should ask the interviewee to talk aloud during this process. This step enables an interviewer to understand how an interviewee thinks and to also prevent an interviewee from going too far down an incorrect path.

The interviewee will create, based on my experience, an implementation of reduce using a for loop:

var reduce = function(array, callback, base) {
  for (var i = 0, length = array.length; i < length; i++) {
    base = callback(base, array[i]);
  }

  return base; 
};

The next step of this process is add a bit of complexity to the question. Prompt the interviewee to refactor their implementation of reduce to include another well known function called each. This request will require the interviewee to use two callbacks, each nested inside of reduce:

var each = function(array, callback) {
  for (var i = 0, length = array.length; i < length; i++) {
    callback(array[i], i, array);
  }
};

var reduce = function(array, callback, base) {
  each(array, function(current, i, array) {
    base = callback(base, current);
  });

  return base;  
};

Binding

Repeat the same steps of the previous question. Ask an interviewee to define the concept of binding, ask the interviewee to create an implementation of bind, and ask the interviewee to talk aloud.

In regards to bind, the interviewee can create an implementation with or without using a prototype. Interviewers should allow the interviewee to create the simpler implementation first – without a prototype. This approach enables the interviewee to build confidence when asked for the more advanced implementation.

Here’s an example of input and output data for bind without a prototype:

// input: 
bind({name: "Cho"}, function() { 
  return this.name; 
});

// output: 
"Cho"

Here’s an implementation of bind without a prototype:

var bind = function(context, func) {
  return func.apply(context);
};

The next step is to ask the interviewee to implement bind using prototype. Here’s an example of input and output data for bind with a prototype:

// input: 
var myFunc = function() { 
  return this.name; 
}; 
   
myFunc.bind({name: "Cho, again!"}); 
   
// output: 
"Cho, again!"

Here’s an implementation of bind with a prototype:

Function.prototype.bind = function(context) {
  var func = this;

  return func.apply(context);
};

If an interviewer wants to further increase the difficulty of bind, then ask the interviewee to refactor their implementations of bind to accept arguments.

Event Emitters and Inheritance

The concept of event emitters will be less familiar to an interviewee than callbacks and binding. Due to this reason, interviewers should clarify to the interviewee that many phrases are used to describe this concept, such as eventing system and eventing library. Once the interviewee has agreed to a mutual definition, present some restrictions for a desired implementation.

An interviewer can achieve this goal with a prepared example of input and output data:

// input:
eventEmitter.on("greet", function() {
  return "Hello, Cho.";
});

eventEmitter.trigger("greet");

// output:
"Hello, Cho."

The interviewee is now ready to write some code.

var EventEmitter = function() {
  this.events = {};
};

EventEmitter.prototype.on = function(event, callback) {
  this.events[event] = callback;
};

EventEmitter.prototype.trigger = function(event) {
  if (!this.events[event]) {
    throw new Error("Event doesn't exist");
  }

  return this.events[event]();
};

If the interviewee has made it this far into the technical challenge, then ask them to use a different inheritance pattern for their implementation of event emitter. This additional step will test the interviewee’s comfort with different implementations of code.

var makeEventEmitter = function() {
  var obj = Object.create(prototype);
  
  obj.events = {};

  return obj;
};

prototype = {};

prototype.on = function(event, callback) {
  this.events[event] = callback;
};

prototype.trigger = function(event) {
  if (!this.events[event]) {
    throw new Error("Event doesn't exist");
  }

  return this.events[event]();
};

A Rubric for a Technical Interview

There are many factors to consider when evaluating an interviewee’s performance on the technical challenge. I consider the following factors when I interview:

Consistency: Is the use of indentation or white space consistent?
Naming conventions: Are the names for variables descriptive?
Testing: Is more than one use case considered?
Questions: Has the interviewee defined the scope of a question?
Code familiarity: Is the applicant using native methods and not recreating them?

Conclusion

A technical interview can leave a lasting impression on an interviewee. If an interviewer’s goal is to make the technical interview beneficial for them and an interviewee, then the best approach is to ask questions that are both fair and meaningful. If an interviewer can achieve this goal, the worst outcome for an interviewee is that they are not offered a job but they leave with some new and useful knowledge. That’s a decent proposition for everyone involved.