> If you are a professional developer, you can consider these examples as a great resource for interview questions and quizzes for newcomers in your company<p>No, do not consider these examples as a "great" resource for interview questions. They are nothing more than tricks and hacks abusing the bad aspects of the language and anyone who includes them in an interview has failed in screening JavaScript developers, at least in my book.<p>A JS developer should understand that JavaScript has some flawed, unfixable core concepts and educate themselves on how to avoid them, not use them in actual production code or memorize every coercion scenario.<p>Some simple rules:<p>1. Always use referential equality checks (triple equal `===`). In idiomatic JS you can also use double equality only when explicitly checking against undefined or null (foo == null). It's the only use of abstract equality that I find acceptable.<p>2. Learn how the `this` execution context works. Kyle Simpson explains it very well in YDKJS (<a href="https://github.com/getify/You-Dont-Know-JS/blob/master/this%20%26%20object%20prototypes/ch2.md" rel="nofollow">https://github.com/getify/You-Dont-Know-JS/blob/master/this%...</a>). There are four simple rules that matter and are straightforward to grasp.<p>3. Familiarize yourself with how type coercion works in JS but avoid it. The spec is quite easy to follow in this matter and follows very specific, documented rules. e.g.:<p><a href="https://www.ecma-international.org/ecma-262/8.0/index.html#sec-additive-operators" rel="nofollow">https://www.ecma-international.org/ecma-262/8.0/index.html#s...</a>
<a href="https://www.ecma-international.org/ecma-262/8.0/index.html#sec-abstract-equality-comparison" rel="nofollow">https://www.ecma-international.org/ecma-262/8.0/index.html#s...</a><p>Use strictly as reference.<p>4. Stop using plain ES5, the language currently is ES2017. ES2015 and beyond provide modern constructs that make most of ES5's weirdness obsolete. For example, never use `var` anymore, `const` and `let` are superior initializers.<p>By following the above rules a JS developer should be fine in 99% of cases, in my experience. Yes, JavaScript will possibly implode on you on the rest 1%, but I'd be hard pressed to find a (similarly popular) language that doesn't. If one finds that to be unacceptable, enabling types via TypeScript or Flow should make their life even easier.