The rules for implicit coercion in JavaScript are rather unintuitive. When people post funny examples of JavaScript "WTF's" it is almost always surprising consequences of coercion rules. {}+[]==0 and so on.
Of course you could memorize all those rules and then use them in your in your codebase to save a few keystrokes - requiring all other developers to also memorize them of course. Alternatively, you could just avoid the mess altogether and use explicit conversions, which is also what JavaScript linters recommend. But then you will easily forget the rules since you never use them.
Therefore the questions say a lot about what forms of knowledge the workplace prioritize, so it is a valuable signal to the applicant. Knowing that the interviewer requires applicants to be able to rattle off these rules say a lot about what kind of colleagues you will get and how the company approach code.
> The rules for implicit coercion in JavaScript are rather unintuitive.
Yes. And a lot of self-described Javascript developers don't even know that. Because they've never read a book or any other document that explains those rules. And that's why they struggle, like the person in this thread to whom I originally replied, and they can't produce correct code quickly and efficiently, and they create bugs that they don't understand and can't fix, and they can't correctly understand code written by someone who actually understands those aspects of the language.
I agree that you can't memorize everything there is to know about Javascript. But if you don't know something, you have to at least know that you don't know it, so you can look up the correct information when you need it. But a lot of self-described Javascript developers don't even know what they don't know.
For example, I know that the methods String.prototype.substr and String.prototype.substring both exist and they're both used to extract substrings from a string. But I still, for some reason, unless I've used one or the other within the last day or so, I have to check the API docs to determine which one I want to use and what its parameters are. I know that I don't know what I need to know. What I will never do, is write a loop that extracts the characters I need one at a time and builds the substring from them. But I have seen where people have done that, in production code and in technical interviews. I am of the opinion (not universally shared here on HN, apparently) that that is not acceptable from a highly paid professional software developer.
And certain basic things about JS, like the ones I originally described, I think you should just know. But again, that's just me.
A huge reply after being so damningly called out? Please do keep asking those gotcha questions.
It's like the flip-side of foobar, avoid like the plague any place where all the tech questions are gotchas or obscure language features. The lead developer is probably someone you do not want to work with.
>A huge reply after being so damningly called out?
Serious question: what the hell are you talking about?
>It's like the flip-side of foobar...
WTF does that even mean?
>avoid like the plague any place where all the tech questions are gotchas or obscure language features. The lead developer is probably someone you do not want to work with.
If you consider those questions "gotchas" or "obscure language features" you don't stand a chance of working with those lead developers. Their process is designed to weed people like you out.
I think, for the book I'm writing, I can build an entire chapter around this subthread. Can I quote you by name, mattmanser?
> If you consider those questions "gotchas" or "obscure language features" you don't stand a chance of working with those lead developers. Their process is designed to weed people like you out.
> I think, for the book I'm writing, I can build an entire chapter around this subthread. Can I quote you by name, mattmanser?
I recognize that this may not be how you meant it, but that comes off as condescending and rude. Please be polite--for our sakes on HN, and in order to attract good interview candidates! I and many of my colleagues have left offers on the table before, even without other open offers, due to impressions of similar (much worse, but on the same axis) condescension and hostility during interviews.
Of course you could memorize all those rules and then use them in your in your codebase to save a few keystrokes - requiring all other developers to also memorize them of course. Alternatively, you could just avoid the mess altogether and use explicit conversions, which is also what JavaScript linters recommend. But then you will easily forget the rules since you never use them.
Therefore the questions say a lot about what forms of knowledge the workplace prioritize, so it is a valuable signal to the applicant. Knowing that the interviewer requires applicants to be able to rattle off these rules say a lot about what kind of colleagues you will get and how the company approach code.