
10 Interview Questions Every JavaScript Developer Should Know - radmuzom
https://medium.com/javascript-scene/10-interview-questions-every-javascript-developer-should-know-6fa6bdf5ad95
======
acjohnson55
While I think this sheet is a great reference, the level of opinionatedness is
a turn off. It strikes me not open to people that might bring a point of view
that challenges the author's orthodoxy. Some of the opinions expressed seem to
indicate a lack of understanding of successful patterns from outside of the
mainstream JS world. I would not use as a filter in hiring.

For example, I might agree that composition is better than inheritance if I'd
never experienced the joy of algebraic data types. Pattern matching doesn't
work out so hot without some concept of "is-a". Languages that support type-
classes also tend to avoid the brittle-class problem. I agree that Java style
single-inheritance hierarchies are a recipe for disaster, but that's not the
only type of class-based inheritance. Scala, for example, has a much better
story.

While Javascript's prototype system is really powerful, I'm not at all
convinced anything more than a small number of library writers should be
interacting directly with it. CoffeeScript and ES6 have class stories that are
vastly more productive in most cases, in my opinion -- and by the way, are
pretty thin layers of prototypes, if someone needs to really hack on that
level. In my experience, most people spin monstrosities when they try to hack
together their own prototypal logic, when all they is something pretty basic.
The author's stamps [1] are very cool. They're more powerful than `class`. But
they still expose a level of variation and control people don't generally need
in reality. To analogize with functional programming -- sure you can solve
almost every problem with `reduce`, but that doesn't make it better than `map`
in all cases. There's huge value to using a tool with just the power you need
for the task at hand.

In general, I'm suspicious of anything that tries to establish some kind of
knowledge quota for new hires. How much time would it take to acquire this
knowledge? If the answer is "not that long, just read all the links on this
page" then why not evaluate your candidates on skills and knowledge that
aren't so easily acquired, and then assign the reading those links you want
understood as orientation homework? Don't get me wrong, I want people on my
team capable of thinking at the level of depth some of these questions
explore. I just think it's more productive to find ways to let the applicant
expose that depth through descriptions of their past experience, not by
adhering to my preconceived list. I wrote a piece [2] when I worked for
HuffPost that explored ideas for evaluating potential hires, with out being
overly prescriptive regarding their specific knowledge at the time of
interview.

[1] [https://medium.com/javascript-scene/introducing-the-stamp-
sp...](https://medium.com/javascript-scene/introducing-the-stamp-
specification-77f8911c2fee)

[2] [http://www.huffingtonpost.com/alanjohnson/were-hiring-
engine...](http://www.huffingtonpost.com/alanjohnson/were-hiring-engineers-
all-wrong_b_7973484.html)

