[contextnavidad]

It passes the value and index to `parseInt`, where the 2nd argument is `base`. So it does not return `[10, 10, 10]` as you'd expect. It returns `[10, NaN, 2]` instead.

You have to do `['10', '10', '10'].map((val) => parseInt(val, 10));` to get the "expected" output. In addition, you should always provide `base` to `parseInt` otherwise it has it's own interpretation infered by the value you give it.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[benatkin]

or just this:

  ['10', '10', '10'].map(val => parseInt(val))

Leading zeroes can often be considered invalid input, and you may be able to safely assume that it has been dealt with already.

Also the parens around a single argument of an arrow function are a superstitious thing suggested by some well-known react developer a while back, I think.

[contextnavidad]

I have my linting setup to force a base on `parseInt`, for the extra characters I do feel it's worth it for the safety.

The extra parentheses is just habit from Prettier formatting :)

[benatkin]

https://github.com/standard/standard/issues/384

[jakear]

Also, no reason to write extra characters just to prevent people from using hexadecimal, it's often convenient and it comes for free!

[mseepgood]

Octal is sneakier than hexadecimal, especially if the values are from user input.

['07', '08', '09'].map(val => parseInt(val)) // => [7, 0, 0]

[jakear]

Hasn't been an issue in around a decade: https://developer.mozilla.org/en-US/docs/web/javascript/refe...

[benatkin]

Plus there's this if you really want to support old browsers: https://github.com/zloirock/core-js/blob/ce52fdc735c5c809c9e...

[benatkin]

was

['07', '08', '09'].map(val => parseInt(val)) // => [7, 8, 9]

[vbezhenar]

My favourite interview question is asking what would return `"192.168.0.1".split(".").map(parseInt)` and why.

[JeremyBanks]

That seems like a very bad interview question

[vbezhenar]

Can you elaborate why do you think so? I'm not asking for correct answer on this question of course (indeed if candidate would answer correctly it means that he knew the answer and the question had no point). I'm expecting to confuse candidate by providing him correct answer and then ask him to find out why his assumption differs from correct answer. This is common in software development and observing how does one tries to understand wrong code provides valuable insight on his skills.

Another question that I like is asking to find out issues in one fragment of code. This fragment is crafted to contain style issues, some bugs and architecture issues. This allows to understand the level of candidate: which issues can he spot. Not ideal, but I think it works good enough.

[joks]

I think the assumption was that you were asking for the correct answer. Definitely makes sense after you explained it though (at least, it makes sense to me.)

[PoignardAzur]

I didn't know about that one. What the hell, JavaScript?