3 questions to watch out for in a JavaScript interview

Questions about the JavaScript language are almost always brought up in any sort of developer interview, whether that be full-stack, front-end, or back-end. As of 2012, ECMAScript, the standard for JavaScript, is implemented in all modern browsers, so if you are going to be developing web applications you are most certainly going to need at least some familiarity with JavaScript.

This article isn’t about the newest JavaScript libraries, common development practices, or any of the new ES6 functions. Rather, these are 3 things that usually come up in interviews when discussing JavaScript. I myself have been asked these questions, and have also heard of others being asked similar questions. Of course these aren’t the only 3 things you should study before a JavaScript interview — there are a multitude of ways you can better prepare for an upcoming interview, but below are 3 questions an interviewer may ask to judge how well you know and understand the JavaScript language and DOM.

We’re going to be using vanilla JavaScript in the examples below, since an interviewer will usually want to see how well you understand JavaScript and the DOM without the help of any libraries (e.g. jQuery).

1. Event delegation

When building an application, sometimes you will need to attach event listeners to some sort of buttons, text, image, etc. on the page in order to perform some action when the user interacts with the elements. So if we take a simple Todo list as an example, the interviewer may tell you that they want an action to occur when a user presses on one of the list items. For example, if a user presses on a list item something should popup, and they want you to implement this functionality in JavaScript assuming the following HTML code:

So you may want to simply do something like the following to attach event listeners to the elements:

While this does technically work, the problem is that you are attaching an event listener to every single item individually. This is fine for 4 elements, but what if someone adds 10,000 items (they may have a lot of things to do…) to their Todo list? Then your function will create 10,000 separate event listeners and attach them to the DOM — this isn’t very efficient.

In an interview it would be best to first ask the interviewer how many items can a Todo list hold, i.e. what is the maximum number of elements the user can enter? If it can never be more than 10 for example, then the above code would work fine, but if there is no limit on the number of items the user can enter, then a more efficient solution may be required.

If your application may end up having hundreds or thousands of event listeners, the more efficient solution is to actually attach one event listener to the whole container, and then be able to access the item that was actually clicked. This is called event delegation and it is much more efficient than attaching separate event handlers. Below is the code for event delegation:

2. Closure within a loop

Closures are sometimes brought up in an interview so that the interviewer can gauge how familiar you are with the language and if you know how and for what reason to implement a closure. A closure is basically when an inner function has access to variables outside of its scope. Closures can be used for things like implementing privacy and creating function factories. A common interview question regarding the use of closures is something like the following:

Write a function that will loop through a list of integers and print the index of each element after a 3 second delay.

A common (incorrect) implementation I’ve seen for this problem looks something like this:

If you run this you’ll see that you actually get the 4 printed out every time instead of the expected 0, 1, 2, 3 after a 3 second delay.

To correctly identify why this is happening it would be useful to have an understanding of why this happens in JavaScript, which is exactly what the interviewer is trying to test. The reason for this is because the setTimeout function creates a function (the closure) that has access to its outer scope, which is the loop that contains the index i. After 3 seconds go by, the function is executed and it prints out the value of i, which at the end of the loop is at 4 because it cycles through 0, 1, 2, 3, 4 and the loop finally stops at 4. There are actually a few ways of correctly writing the function for this problem, but I’ve provided two of them below:

3. Debouncing

There are some browser events that can fire many times within a short timespan very quickly, such as resizing a window or scrolling down a page. If you attach an event listener to the window scroll event for example, and the user continuously scrolls down the page very quickly, your event may fire thousands of times within the span of 3 seconds. This may start causing some serious performance issues!

If you are discussing building an application in an interview and events like scrolling, window resizing, or key pressing come up, make sure to mention debouncing and/or throttling as a way to improve page speed and performance. A real example taken from this guest post on css-tricks:

In 2011, an issue popped up on the Twitter website: when you were scrolling down your Twitter feed, it became slow and unresponsive. John Resig published a blog post about the problem where it was explained how bad of an idea it is to directly attach expensive functions to the scroll event.

Debouncing is one way to solve this issue by limiting the time that needs to pass by until a function is called again. A correct implementation of debouncing would therefore group several function calls into one and execute it only once after some time has elapsed. Below is an implementation in plain JavaScript that makes use of topics such as scope, closures, this, and timing events.

The function above, when wrapped around an event, will execute only after a certain amount of time has elapsed. You would use the function like so:

Throttling is another technique that is similar to debouncing except that instead of waiting for some time to pass by before calling a function, throttling just spreads out the function calls via some time interval. So if an event occurs 10 times within 100 milliseconds, with throttling you can spread out each of the function calls to be executed once every 2 seconds for example instead of all firing within 100 milliseconds.

For more information on debouncing and throttling the following articles and tutorials may be helpful: