loading...

A tricky JavaScript interview question asked by Google

Daniel Borowski on October 07, 2019

The following will be a short explanation, along with some solutions, of a popular JavaScript question that tends to get asked in developer intervi... [Read Full]
markdown guide
 

I just strongly dislike the idea that someone's job could be based on how well they understand the intricacies of poorly written and purposely confusing code. I understand you're providing a valuable example of what currently is, but I wish we could do something to change that paradigm. Create some other way of measuring competence in programming ability.

 

I agree with you on the interview process.

On the other hand, this question is great to start a conversation on why old-school JavaScript is bad - JavaScript has good parts, but had lots of flaws as well, most of which were fixed later by EcmaScript 6, Typescript, React, Angular, ...

Edit: clarified my answer

 

Every tool has its uses.

I started my career in Android land which, at the time, requires lots of ceremonial boilerplate to get things going.

Kotlin is a huge improvement. That’s besides the point

I’ve now been working with React and React Native professionally for a couple years and really have become enamored with the ease of iteration.

As an independent developer, shlopping JSON around the application and perhaps providing some required props here and there is all I’ve really needed. We don’t need statically typed languages to write mobile applications.

Would they have helped on some crazy debugging issues I’ve had? Absolutely.

Should I have gone through the hassle of adding another layer of abstraction just because they essentially give me better warnings? Jury is still out. For me personally, I don’t think so.

I am no fan of Android as described here :)

Every tool has its uses.

Yes, and every tool should work on fixing its main flaws. This is basically what was done with JavaScript with both EcmaScript 6 and TypeScript and React and Angular...

 

Agree with you. At first I thought the same thing everyone else did. It would print out the value. But as soon as I saw the index 4, I knew exactly what was happening.

This is the sort of thing you usually don't spot while coding but once you see it happening (usually in test run), is trivial to debug and fix. For one, using let and const over var produces more sensible and predictable results.

 

No-one would dispute that "old-school JavaScript" had lots of flaws; but most developers with a job will have migrated to a "safer" programming language some time ago; namely JavaScript. Believe it or not the language has moved on since Crockford wrote "The Good Parts"; as is obvious from the ES6 solution provided.

And Typescript is not "another programming language" that magically guarantees you are free of the issues illustrated in the example question. It's still just JavaScript. I can still type that problem loop into my editor; Typescript will still compile and it will still produce the same output.

Believe it or not the language has moved on since Crockford wrote "The Good Parts"; as is obvious from the ES6 solution provided

I believe it!
I have edited my original answer, it was not my intention to claim that the current JavaScript ecosystem is the same as "old school Javascript".

 
for (var i = 0; i < arr.length; i++) {
  setTimeout(function(index, element) {
    console.log('Index: ' + index + ', element: ' + element);
  }, 3000, i, arr[i]);
}

will also produce expected output

 

Wow! I didnt know you could pass more arguments to the setTimeout function like that. Good to know, thank you!

 

Like the article, but I think it would help more people with a more thorough explanation. The answers don't exactly state where and why you get Index: 4. We forget people who are just learning and skip steps that are obvious to more advanced developers. Saying closure doesn't explain that the 'i' variable continues to increase. I personally never had one teacher explain the details of a for loop. You might never see it without making this mistake.

 

To me this looks like a useless interview question.

I don't know the answer because I don't need to know it. It's been years since I don't write such code. People doing JS for 15 years are much more likely to know this. New frontend devs who started on ES5/6 would likely never need to learn this.

 
 

Really? Is this a tricky question? This is the first question I ask when interviewing JS devs.

code of conduct - report abuse