

Are You a JavaScript Guru? Try This Test - techdog
http://asserttrue.blogspot.com/2013/02/are-you-javascript-guru-try-this-test.html

======
neilk
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.

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

~~~
skrebbel
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.

------
valdiorn
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?

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

~~~
CognitiveLens
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!

~~~
berntb
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).

------
shepik
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)

~~~
jakub_g
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.

~~~
Stratoscope
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)

~~~
jakub_g
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...](https://developer.mozilla.org/en-
US/docs/JavaScript/Reference/Global_Objects/parseInt)

~~~
Stratoscope
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!

------
nirvanatikku
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.

~~~
politician
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.

~~~
svachalek
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.

------
asher_
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.

------
cwbrandsma
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.

~~~
berntb
>>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... :-)

------
voidr
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.

------
biscarch
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?

------
jakub_g
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.

------
mattparlane
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.

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

------
orangethirty
Anyone else feel weird they got all of them right?

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

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

