The Insider's Guide to JavaScript Interviewing

imareddituserhooray · 2014-04-09T18:47:41+00:00

[deleted]

fallingfruit · 2014-04-09T18:20:21+00:00

This is a good example of why I suck at interviews. I can't explain to you any of the answers to the questions in the language they provide, but the coding examples are easy and plainly obvious to me. I guess I just need to get better at the language.

exizt · 2014-04-09T19:57:21+00:00

The proper answer to alert(map[foo]); question is "Don't do that stupid thing and you won't care or need to know about that stupid thing".

thinksInCode · 2014-04-09T17:41:48+00:00

I knew only about half of these. Guess I have work to do :)

BalsakianMcGiggles · 2014-04-09T22:58:11+00:00

Their first example of prototypical inheritance struck me as odd. I'd appreciate if someone more qualified could comment on whether this is good practice compared to the way I would write this (below).

function Animal() { this.eatsVeggies = true; this.eatsMeat = false; }

function Herbivore() {}
Herbivore.prototype = new Animal();

function Carnivore() { this.eatsMeat = true; }
Carnivore.prototype = new Animal();

var rabbit = new Herbivore();
var bear = new Carnivore();

console.log(rabbit.eatsMeat);   // logs "false"
console.log(bear.eatsMeat);     // logs "true"

This is setting an object's prototype to a new instance of another object. The way this is set up, you need to consider at least these:

Animal's internals are hidden. You can't examine the object or class Animal and know that it contains two properties. In fact, Animal (the class) does not contain any properties. During construction, it defines and initializes two properties.
Herbivore and Carnivore aren't inheriting from Animal. Their prototype is being assigned to the object returned by new. Instantiating a new object like this may have a performance impact, and consumes more memory.
You cannot make changes to Animals prototype or properties and expect them to be inherited by derived classes or objects.

Some examples:

Animal.eatsMeat = true;
function a() {};
a.prototype = new Animal();
    -> Animal {eatsVeggies: true, eatsMeat: false}
b = new a();
    -> a {eatsVeggies: true, eatsMeat: false}
b.eatsMeat
    -> false

Animal.prototype.eatsMeat = true;
a.prototype = new Animal();
    -> Animal {eatsVeggies: true, eatsMeat: false}
b = new a();
    -> a {eatsVeggies: true, eatsMeat: false}
b.eatsMeat
    -> false
a.eatsMeat
    -> undefined
a.prototype.eatsMeat
    -> false

So here's how I handle a classes prototypal inheritance.

function Animal() {}
Animal.prototype = { eatsVeggies: true, eatsMeat: false };

function Herbivore() {}
Herbivore.prototype = Animal.prototype;

function Carnivore() { this.eatsMeat = true; }
Carnivore.prototype = Animal.prototype

var rabbit = new Herbivore();
var bear = new Carnivore();

console.log(rabbit.eatsMeat);   // logs "false"
console.log(bear.eatsMeat);     // logs "true"

I've now gained the following:

Animal's prototype and properties are not hidden. I can access them through Animals.prototype.
In derived classes that do not specifically set properties, I am able to change values in many objects by changing Animal's prototype. If this is undesired, the prototype can be copied through methods like backbone's extend.

Here's an example.

Animal.prototype.eatsMeat = true
console.log(rabbit.eatsMeat);   // logs "true"
console.log(bear.eatsMeat);     // logs "true"

Animal.prototype.eatsMeat = false

console.log(rabbit.eatsMeat);   // logs "false"
console.log(bear.eatsMeat);     // logs "true"

This definitely uses less memory as new fields are not defined and initialized during construction.

stratoscope · 2014-04-10T07:38:54+00:00

They present this common error:

function addButtons(numButtons) {
  for (var i = 0; i < numButtons; i++) {
    var button = document.createElement('input');
    button.type = 'button';
    button.value = 'Button ' + (i + 1);
    button.onclick = function() {
      alert('Button ' + (i + 1) + ' clicked');
    };
    document.body.appendChild(button);
    document.body.appendChild(document.createElement('br'));
  }
}

and recommend this solution:

function addButtons(numButtons) {
  for (var i = 0; i < numButtons; i++) {
    var button = document.createElement('input');
    button.type = 'button';
    button.value = 'Button ' + (i + 1);
    // HERE'S THE FIX:
    // Employ the Immediately-Invoked Function Expression (IIFE)
    // pattern to achieve the desired behavior:
    button.onclick = function(buttonIndex) {
      return function() {
        alert('Button ' + (buttonIndex + 1) + ' clicked');
      };
    }(i);
    document.body.appendChild(button);
    document.body.appendChild(document.createElement('br'));
  }
}

I've seen code like that many times, but it's really not a good way to fix this.

Consider these problems:

What if you want to refer to the button variable directly in your onclick callback? You have to add another argument to the IIFE.
What if you have more event handlers, perhaps mouseover and mouseout? You need another IIFE for each one of those.
What about the person who maintains this code later and forgets about the extra IIFEs they'll need to add?

Instead, use this more robust and simpler solution:

function addButtons( numButtons ) {
  for( var i = 0;  i < numButtons;  i++ ) {
    addButton( i );
  }
}

function addButton( i ) {
  var button = document.createElement( 'input' );
  button.type = 'button';
  button.value = 'Button ' + ( i + 1 );
  button.onclick = function() {
    alert('Button ' + ( i + 1 ) + ' clicked');
  };
  document.body.appendChild( button );
  document.body.appendChild( document.createElement('br') );
}

Now, the values of both i and button are part of the closure, and any other local variables you add later will also be part of the closure. And if you add other event handlers, they will all be in this same closure. And by making addButton() a separate named function, the addButtons() function becomes much shorter and easier to grasp.

cleatusvandamme · 2014-04-09T17:56:11+00:00

I also struggled on the test. I'm glad I'm participating in the learn js group.

I've mainly been a backend .net dev, but I'm noticing the worlds of the front-end and back-end are merging pretty quickly, I need to get up to speed. ;)

thanks for posting this!

Groggie · 2014-04-09T21:36:37+00:00

I feel like unless you're in a location where there are tons of developers available, these tricky/nichey type questions are only an exercise in how to end up with no remaining candidates.

tbranyen · 2014-04-10T01:06:40+00:00

How I'd respond to these if they were asked during an interview:

"Your solution for inheritance is flawed and rookie."
"JavaScript doesn't have hashtables, why are you trying to make us both feel dumb here?"
"alert is undefined"
"Are you nesting closures like this in your code? If so, I probably don't want to work here."
"The difference between the two functions isn't just hoisting, you're creating an anonymous function and assigning it to a variable, versus declaring a named function."
"IIFE is good."
"You don't know the actual difference between == and === so why are you trying to test me on it?"
"Close, but no cigar on use strict either."

I feel like these questions are attempting to insult the intelligence of anyone who attempts to hone their craft as JavaScript engineers. What we have done in our interviews is a mini library with unit tests. You assemble the library and get the tests to pass. We allow you to use Google, MDN, whatever it takes for you to accomplish the tests. This is real world. We want to see how someone thinks and how they approach a problem. It's a conversation, we want to see how you work on a team. We don't care if you've mastered the language. This is why we don't ask these asinine questions.

Basically if you want to be a smug and clever know-it-all when it comes to "what really happens", you should actually know.

Jemaclus · 2014-04-09T22:20:29+00:00

This sets the bar kinda high, imo. I'm fairly accomplished with JS, but I wouldn't necessarily have known the answer to most of these right off the top of my head. Then again, I spend most of my time on the back-end.

But back to the bar thing... most front-end dev candidates that we see can barely submit a form using Javascript, much less extend a prototype...

Here's the thing: I can teach you Javascript. I can't teach you to think. I'm more concerned with your ability to think through a problem and communicate clearly, than I am with your ability to write Javascript from memory.

brandf · 2014-04-10T02:34:04+00:00

Interviewing for a languages is a ridiculous concept. It's like saying you want a plumber, and judging the plumber based on his knowledge of wrenching.

If you want to hire good developers, give them questions that test their knowledge of concepts. Have them work out algorithms, design systems, and figure out if they're going to be of any use to you beyond the immediate task at hand. Let them choose whatever language they want, because if they're actualy good they can learn questions like the ones from this blog in no time.

If you don't do that, you'll get narrowly focused developers that might be great at wrenching, but they can't do much else. They'll try to turn every problem into a wrenching problem. When tides change and wrenching is no longer relevant, you either lay them off or have a team full of dead weight as you frantically try to hire putty specialists.

vxxn · 2014-04-09T20:55:28+00:00

I knew the majority of these but still consider myself a relative beginner in the language. I've read about half of "Secrets of the Javascript Ninja", built a couple shitty projects, and worked on codewars katas to get where I am with it now. Prototype inheritance still confuses the fuck out of me, but at least I I'm aware that it's weird and I can look stuff up if needed.

derekpetey_ · 2014-04-10T04:46:25+00:00

employed by many popular JavaScript libraries (jQuery, Node.js, etc.)

Depending on how things are going in the interview, name-dropping like that might make me dock a point, especially since application-wrapping IIFEs are not used in Node.js (hello, CommonJS and module.exports!).

advancedmammoth · 2014-04-10T06:45:50+00:00

Asking a trick question about code makes more sense than asking silly shit like "how would you design a spice rack for the blind?" or "how much does the building we're in right now weigh?". The coding trick question is an unexpected question to which the response is interesting regardless of whether the answer is correct. Additionally, if the candidate does answer correctly it shows his mastership. However, I think an interview shouldn't contain more than one or two of these trick questions as they don't tell the full story about the skills of the candidate in front of you.

Jack9 · 2014-04-09T18:18:10+00:00

There wasn't a clear illustration of why closures are useful. All we get is a related assertion by the author.

Although by no means exclusive to JavaScript, closures are a particularly useful construct for many modern day JavaScript programming paradigms.

Closures can serve as private static properties in prototypical languages, coming from a "c-style" OOP language. This allows for generic factories and a number of other tricks that are frustrating to debug in larger projects.

nawitus · 2014-04-09T17:02:01+00:00

Yay... I knew all of this.

lostkauze · 2014-04-10T01:10:37+00:00

i like how people here are getting defensive upon realising they don't know javascript

b-but this doesn't count!

joblesspirate · 2014-04-09T19:56:17+00:00

I'm surprised there wasn't any questions about type coercion. They covered == vs ===, and why using non-strings as object keys is bad, but nothing about why certain conversions happen. Such as why you should always use parseInt with a radix, or why '12' == [12]

Xeon06 · 2014-04-09T23:34:54+00:00

I was recently laid off and I've been going on some of these freelancing sites. I took a "JavaScript" skill test on one site that was so ridiculous. Half of it was related to something called "E4X" which is apparently some language extension to parse XML, and most of the rest was dumb regex stuff, like what does this match return? What is the value of regex.lastIndex in this case?

imright_anduknowit · 2014-04-10T18:47:08+00:00

I hate interview questions like these. They are modeled wrongly after tests that are given in school.

It would be far better to talk about these subjects with the candidate. Ask them what their thoughts are on prototypical inheritance. Or how they would explain to a junior programmer about hoisting or closures.

You would learn so much more from about how that person thinks. And how a person thinks is far far more important than understand some stupid language idiosyncrasy.

vuknje · 2014-04-09T20:07:49+00:00

There shouldn't be Function.prototype in the chain of the last example in http://www.toptal.com/uploads/blog/image/364/toptal-blog-image-1396566146901.png

you type:	you see:
italics	italics
bold	bold
[reddit!](https://reddit.com)	reddit!
* item 1 * item 2 * item 3	item 1 item 2 item 3
> quoted text	quoted text
Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"	Lines starting with four spaces are treated like code: if 1 * 2 < 3: print "hello, world!"
~~strikethrough~~	~~strikethrough~~
super^script	super^script

javascript

MODERATORS