Probably not the best way to do it, but I've done something like this before.
els[i].addEventListener("click",(new function(){var this._i = i; function message(){alert(_i);}}).message);
JavaScript Interview Question
41–50 of 63 posts
Re: JavaScript Interview Question
#42Earlier quoted context omitted.
Please do.
this is what I usually tell people to do: var els = document.getElementsByTagName('li');//use var unless you really really really meant global for(var i=0; i
Does this work (from a non-JS person -- I like reading JS books, but don't code in it at all). This is certainly less elegant, but seems easier to follow:
var els = document.getElementsByTagName('li');
for(i=0; i Re: JavaScript Interview Question
#43Earlier quoted context omitted.
this is what I usually tell people to do: var els = document.getElementsByTagName('li');//use var unless you really really really meant global for(var i=0; i
i agree with the choice of code, but I have a different style for laying out the code. i dislike the declaration and immediate execution of an anonymous function. i much prefer to give it a name, move it out of the loop itself and then call it within the loop. it makes reading the code more top-to-bottom. with this approach, when I get to the anon func declaration, i have to scan down looking for when it is invoked.…
I don't generally care too much to talk about style when the problem at hand is that someone has been banging their head against the desk for the past two hours and they just want it to work (and, in my experience, this usually is the case, for some reason)
But yeah, if we're gonna be super nitpicky, yeah sure, improve the for loop also, while we're at it.
for (var i = -1; els[++i];) {//given the code in the loop body, this is shorter and fasterRe: JavaScript Interview Question
#44Earlier quoted context omitted.
this is what I usually tell people to do: var els = document.getElementsByTagName('li');//use var unless you really really really meant global for(var i=0; i
Does this work (from a non-JS person -- I like reading JS books, but don't code in it at all). This is certainly less elegant, but seems easier to follow: var els = document.getElementsByTagName('li'); for(i=0; i
That doesn't work. Variables in javascript are not block scoped but function scoped.
Re: JavaScript Interview Question
#45I think they all alert '3' because of the missing 'var' keyword.
Just adding var wouldn't be enough, you're still referencing the variable from the outer scope. You need to create your own copy. Instead of: els[i].addEventListener('click', function(){alert(i);}); Do: els[i].addEventListener('click', function() { var j = i; alert(j); }); Edit: This is wrong, archgoon has the correct answer below. That'll teach me for jumping on closure problems in the morning :)
I create a closure outside of the event registration: http://pastebin.com/igzWkgKF
Re: JavaScript Interview Question
#46This is a bit of a "gotcha" question.
I have absolutely no faith that someone in an interview who doesn't figure out the scoping issue in the interview doesn't understand Javascript scopes. In the "real world" of a job, the problem is presented like this: "This code exhibits the following behaviour: It outputs a four every time instead of one, two, three, and four Find out why and fix it, please."
Given as a gotcha, I would stare at the code, and possibly figure out the scope issue. Then I would keep staring. Is this the only "gotcha," or has the interviewer diabolically inserted two bugs and I have to find the second one?
The entire process would make me feel like I was in an adversarial position, where the interviewer is trying to point his finger at me and yell "FAIL! I pwn3d you with my l33t Javascript questioning skillz!!"
FWIW, I think I understand the solution. In fact, I wrote a blog post about the exact same thing:
https://github.com/raganwald/homoiconic/blob/master/2010/10/...
But nevertheless, I know that from time to time I unwittingly make this mistake when coding and quickly fix it. I don't have a lot of confidence I would be guaranteed to get the correct answer in an interview every time.
Which is maybe why I don't like it as an interview question: Perhaps I'm not smart enough to get the answer right every time. Perhaps the only questions I like are the ones I like to be asked :-)
Re: JavaScript Interview Question
#47Boring rookie question. Add a closure. I expect it does a good job of sorting out people who know js from those that have no clue though.
Re: JavaScript Interview Question
#48It's not the question itself with which I have a problem; it's the whole approach. Let me explain... 1. Every programmer I have ever worked with (except for an inept few) knew something that I didn't. They could show me a piece of their code and say, "When you do , it causes , the compiler does , the operating system does , which results in ." To which I think, "Great. Who cares. I would have just done and been done…
2. If you can't read code well, how the hell are you going to be able to write code well? Too many programmers are terrible at reading code and that correlates IMHO with being terrible at writing it.
If you're planning on being an author, it's useful to first be able to read, and to read loads. That's how you learn.
The interview question is a simple rookie js question that basically asks "Do you know javascript to any degree".
Re: JavaScript Interview Question
#49Earlier quoted context omitted.
Does this work (from a non-JS person -- I like reading JS books, but don't code in it at all). This is certainly less elegant, but seems easier to follow: var els = document.getElementsByTagName('li'); for(i=0; i
That doesn't work. Variables in javascript are not block scoped but function scoped.
Thanks. Good to know.
Re: JavaScript Interview Question
#50It's not the question itself with which I have a problem; it's the whole approach. Let me explain... 1. Every programmer I have ever worked with (except for an inept few) knew something that I didn't. They could show me a piece of their code and say, "When you do , it causes , the compiler does , the operating system does , which results in ." To which I think, "Great. Who cares. I would have just done and been done…
I think you have a very enlightened approach, Edw519. I actually take it one step further and ask candidates to work on problems or portions of problems the company actually has. E.g., how would you approach fixing this bug.
It also has the side benefit of letting candidates see our codebase, bug tracking, etc.
As far as asking how technologies work under the hood. I really don't care if a web developer knows how pointers work, etc. If they can consistently get challenging problems done, that's all I need to know.