3 ms·

10 Interview Questions Every JavaScript Developer Should Know

4 points by radmuzom 11y ago

acjohnson55 11y ago
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-specification-77f8911c2fee https://medium.com/javascript-scene/introducing-the-stamp-sp... [2] http://www.huffingtonpost.com/alanjohnson/were-hiring-engineers-all-wrong_b_7973484.html http://www.huffingtonpost.com/alanjohnson/were-hiring-engine...

4 points by radmuzom 11y ago

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-specification-77f8911c2fee https://medium.com/javascript-scene/introducing-the-stamp-sp... [2] http://www.huffingtonpost.com/alanjohnson/were-hiring-engineers-all-wrong_b_7973484.html http://www.huffingtonpost.com/alanjohnson/were-hiring-engine...