3 ms·
> 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 th
by rhapsodic 8y ago
> 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.
- mattmanser 8y agoA 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.
- rhapsodic 8y ago>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?
- zbentley 8y ago>It's like the flip-side of foobar... I suspect they meant FizzBuzz, but am not sure. > 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.