Are You a JavaScript Guru? Try This Test | Hacker News Reader

Are You a JavaScript Guru? Try This Test

asserttrue.blogspot.com

24 pointstechdog34 comments

This isn't a JavaScript quiz. Mostly it tests if you know how numbers really work, operator precedence, and some obscure coercion rules. Boring.

The only slightly relevant question, I thought, was what typeof NaN was. Not knowing that might result is actual bugs.

Also, it's so absurd that you would remember it.

Are you sure? The only reason why it's absurd is because deep inside, Number knows that it should've really been called PossiblyANumber. It's a different abstraction and an unfortunate naming collision.

Weird, for me the hard part was being sure it was a trick question and thus trying to come up with an answer other than "number" that made sense. I couldn't so I guess I got it right. What else could it possibly be?

I have been asked questions like this before in interviews and it makes me wonder if the technical interviewers were so indifferent about their jobs they would pull clever questions from the web instead of practical questions applicable to the position. I rarely answer these clever questions correctly and I've been doing JS for a while.

Much more relevant JS interview questions would be relevant to scope. Considering understanding nuances of scope in JS is what differentiates beginners from the experienced.

this.

Bravo.

Being able to answer these questions has very little to do with being a good javascript developer, because a good javascript developer knows he should never, ever write code like that.

Javascript has flaws and pitfalls, to be a good Javascript developer you must know what they are, but is it really necessary to be able to pull the results of (1/null) out of your ass?

God, I hate this crap. Edge cases != useful knowledge

Agreed. It seems like the lesson is "don't write ambiguous JS, because it will bite you" - I'm not sure you have to know the nature of every bite in order to be a JS expert, because a JS expert should generally be writing very predictable code!

Many years ago, I had a bookmark in my Harbinson-Steele's C book, for the precedence of operators.

After a while, I decided that was stupid and removed the bookmark -- if I ever needed to look at operator precedence, then I should use parentheses.

That said, to understand the edge cases are valuable, because you should recognize when you get close to them (not only in your own code).

Edge cases !== useful knowledge

FTFY

The second question

  (0.1 + 0.2) + 0.3 == 0.1 + (0.2 + 0.3)

is not an edge case, unfortunately.

At least two questions are bad.

7. a = "5"; b = 2; c = a+++b;

Why even ask that? It's boring. And operator precedence is not really important in practive, and it's bad style and no one writes like that. It's a question for junior-level interview, when you can't ask anything meaningful and (because you have to ask anything) you ask _this_.

9. (16).toString(16)

Oh, so Guru should memorize every obscure parameter, shouldn't he?

Other questions are fine, though (except 10. Numerical systems, c'mon, it's 2013, not 1980s)

Regarding "(16).toString(16)": yep you should know that param and nearly always write myNumber.toString(10) and parseInt(myNumber, 10).

JSHint complains if you don't provide the radix. The reason is to not get your ass in fire in production by the fact (016).toString() === "14" (leading 0 means JS guesses a number is in octal representation, unless it contains 8 or 9). And you use JSHint, don't you? If no, install it right now as a pre-build hook.

EDIT: what I wrote above is bullshit, see the comments below; toString is a different story than parseInt.

Sorry, but that advice about number.toString(radix) is mistaken.

JSHint does not complain if you omit the radix in a number.toString() call, nor should it. The default radix value for number.toString() is 10, and there are no magical surprises as there are with parseInt(). If you write number.toString() it means exactly the same thing as number.toString(10). There is no reason to provide an explicit radix of 10 unless you just like it better than way.

In the (016).toString() example, the problem isn't the missing radix; (016).toString(10) returns the same value, "14". The problem is the 016 constant itself. That is an octal constant and has already been converted to decimal 14 before the .toString() call. There is nothing that .toString() can do to fix this problem.

Now you're right that it is useful for a developer to know about the radix parameter, so you can easily convert a number to its string representation in hex or binary or whatever base you need.

parseInt() is a different story, of course. You are quite correct that you should never write parseInt(number) without a radix argument, unless you actually want the behavior of a leading zero making it octal and a leading 0x making it hexadecimal.

(edited for clarity)

I must admit you're right with the first part. I haven't thought twice nor checked things. Thanks for pointing it out.

Regaring parseInt(), the story is even more complex though :) You should never use it without the radix because that behavior is not reliable when it comes to implying octal representation. Calling parseInt("016") yields 16 in Chrome (ES5 compliant [1]), while 14 in Firefox, Opera and IE8.

[1] https://developer.mozilla.org/en-US/docs/JavaScript/Referenc...

Oh wow, you're right about parseInt(). For some reason I thought the octal thing was standard across browsers. That's what I get for adding that throwaway comment at the end without checking it. Thanks for catching that!

Surprised to see people claiming that this isn't essential knowledge. Understanding what the system is doing at its core allows you to answer these questions; as 'tricky' as they may seem. If you're dealing with JS, you should know how things are working under the hood. There shouldn't be any memorizing, instead, you should be able to reason what the outcome is in those cases. At least that's what I strive for.

Agreed, knowing how 1/x behaves for x in [null, 0, void 0] is helpful. Specifically, don't expect a "div by 0" error to be thrown. Instead, check for infinity. That's not something a C# developer would necessarily expect.

Yes, unfortunately many languages have borrowed C's rather bizarre ideas about what's permissible. 1/0 should crash but it's perfectly okay for 0xffffffffu + 1 to give different answers depending on your architecture.

Dividing a float by zero yields infinity (or -infinity) in C# as well.

This was interesting if nothing else.

Maybe its just because I just woke up, but I didn't even realise why Q1 was interesting until after I read the HN comments. Those that are saying these are all useless for practical work are wrong in my opinion. Some of them are, but not all.

If you saw Q2 and didn't realise the possibility of it being false, the reasons for that are something you need to learn when dealing with any language that uses floating points. Q3 is something every JS programmer should know, as is Q4.

Q5 is more interesting, because the correct answer is "what version of javascript?" Protected terms cannot be used as object properties without being put in quote marks in earlier versions of JS. Doing something like this in an older browser would throw an error.

Q6 could have been better, it would be pretty hard to get it wrong. Something like "5" + 2 would have been more interesting because + is overloaded so you would have to know how javascript treated it in different situations, which is close to essential knowledge.

Q7 is definitely just trivia. No sane person writes code like that. Q8 is trivia too; easy if youre familiar with JS but not hugely useful. Q9 is easily guessable; I didn't know what the param for toString did but I guessed it correctly.

Q10 is important, if you dont know how JS treats numbers with a leading 0 you can get yourself into trouble and have no idea why.

Q11 I learned something new, I didn't know about the ~ operator, I wouldn't use it in regular code though.

Q12 is regex. Either you knew it or you didn't. If you didn't, you learned about \b, which can be rather useful.

My current favorite questions involve asking people what their favorite Javascript library is, then asking detailed questions about how it works. Even pulling up common functions from the library and ask what is going on.

Better questions involve things like variable scoping, modules, arguments, event bubbling, prototypes, etc.

Now, where I get stuck: Regular Expressions. I just don't think I will ever get comfortable with that.

>>Now, where I get stuck: Regular Expressions

Read Mastering Regular Expressions. I thought I understood regexps before I read that book. Now I can use them -- and am, at a minimum, confused on a higher plane... :-)

Answering correctly to these questions only means that you know these edge cases/quirks, heck you could memorize most of them. A real developer should never write code like that.

I'm curious about how the utility of tools such as JSHint/Lint affect how many edge cases a new programmer actually needs to memorize, in the context of hiring said programmer. Unless a programmer is trying to abuse an edge case, wouldn't a Lint tool remove the need for the wrote memorization of all edge cases?

The thing about Math.PI can be confusing. It allows you to preincrement it, but it actually doesn't change the value:

(function(){console.log(++Math.PI); console.log(Math.PI)})()

logs 4.14... and then 3.14.

Of course no one sane should write a code like this.

I think you need more linebreaks between the questions and the answers -- the first four answers were above the fold when I loaded the page.

As someone that writes JS on an almost daily basis I now feel like a n00b.

Anyone else feel weird they got all of them right?

Can anyone explain the ++Math.PI thing to me?

Looks like this quiz got many people upset. Relax it's just fun. Like jeopardy. Gurus in their own right

Reply on news.ycombinator.com