10 Interview Questions Every JavaScript Developer Should Know - JavaScript Scene - Medium

8/1/2016 10 Interview Questions Every JavaScript Developer Should Know — JavaScript Scene — Medium
Eri c Elliott
Comp assionate entrepreneur on a mission to end homelessness. #jshomes Javascript, tech edu...
O ct 2, 2015 · 15 min read
10 Interview Questions
Every JavaScript Developer
Should Know
AKA: The Keys to JavaScript Mastery
Bruce Lee on the Avenue — Leevin (CC BY-NC . )
At most companies, management must trust the developers to give technical
interviews in order to assess candidate skills. If you do well as a candidate,
you’ll eventually need to interview. Here’s how.
You Might Not Agree, and That s OK ’

I advise people to hire based on whether or not a developer believes in class
inheritance. Why? Because people who love it are obstinately stubborn
about it. They will go to their graves clutching to it. As Bruce Lee famously
said:
. . .
https://medium.com/javascript-scene/10-interview-questions-every-javascript-developer-should-know-6fa6bdf5ad95#.epqwyovct 1/19
“Those who are unaware

they are walking in darkness
will never seek the light. ”
. . .
I won’t hire them. You shouldn’t, either.
I’ve seen classes wreak havoc on projects, companies, and lives. Many
brilliant people disagree with my views. However, before dismissing my
opinion out of hand, consider these points:
I ran an app consulting firm in the early days of SaaS, starting before the
term was coined. I have worked on hundreds of projects for both startups
and fortune 500 companies. I have a background in C++/Java (and
assembly, AutoLisp, Delphi, etc…), and I consulted on dozens of Java and
C++ apps (both class-oriented OOP languages). I was once an avid
supporter of classical inheritance, and even wrote multi-language Rapid
Application Development (RAD) tools for it.
I saw up close the many ways in which the class paradigm invited unwary
developers down the wrong road, and I saw the extremely costly effects. I’ve
seen products abruptly discontinued to stop losses, programmers laid off,
and companies brought to their knees by brittle, tangled codebases caused
primarily by the improper use of classes and class inheritance.
Class in JS is not harmless sugar for prototypal OO. Class is a virus that
infects everything it touches. It came to us formally in JavaScript with ES6,
and at the same time, React was taking off. Lots of people started using
classes for React components (you don’t have to: the new React 0.14
supports pure function components, or try react-stamp).
Many are unaware that you can build React components in a class-free style.
This has caused confusion and incompatibility between React components
and other composable elements in the React ecosystem (components,
mixins, and component wrappers).
During the days of Backbone dominance (Backbone used its own flavor of
classes), I watched a once malleable codebase transform into a brittle mess.
I saw code complicated by abstractions necessary to unify the calling API of
classes that require `new`, and factories that don’t, forcing the use of
dependency injection container that ended up coupling every dependent
module tightly to the container API. Those of you with Angular experience
will understand what I’m talking about. Angular has four different ways to
create services, and features a dependency injection container to abstract
them all.
Many brilliant people warned of the perils of class inheritance decades ago,
before JavaScript was invented. You can find their warnings in essays with
titles like “Object Oriented Programming Considered Harmful”, “Class
Considered Harmful”, and “New Considered Harmful”. Such warnings have
been published on Usenet, in academic papers, and respected publications
such as Doctor Dobb’s Journal: a magazine that gave us nearly 40 years of
software development wisdom before its sunset at the end of 2014.
Incidentally, there’s also an essay called “Considered Harmful Considered
Harmful”, but I digress.
Joe Armstrong, the creator of Erlang summed up one of the famous
problems with class in what has become known as The Gorilla Banana
Problem from the great book, “Coders at Work” (buy it, there’s lots of other
great stuff in it):
“The problem with object-oriented languages is they’ve got all this implicit
environment that they carry around with them. You wanted a banana but
what you got was a gorilla holding the banana and the entire jungle.”
The seminal tome of OO design, “Design Patterns: Elements of Reusable
Object-Oriented Software” — the book from which design patterns get their
name — implores:
. . .
“Favor object composition

over class inheritance.”
. . .
Edit:
Some readers are asking about the class rant. Learn more about why I don’t like
classes in JavaScript:
* The Two Pillars of JavaScript: How to Escape the 7th Circle of Hell
* A Simple Challenge to Classical Inheritance Fans
* Common Misconceptions About Inheritance in JavaScript
* How to Fix the ES6 `class` Keyword
* Introducing the Stamp Specification
If you’re one of those obstinate classical inheritance fans, you may disagree
with lots of this article, but there are still some gems here for you, too. Take
what you like, toss the rest. I won’t be offended.
. . .
It Starts With People
In “How to Build a High Velocity Development Team” , I made a couple
points worth repeating:
“Nothing predicts business outcomes better than an exceptional team. If you’re
going to beat the odds, you need to invest here, first.”
As Marcus Lemonis says, focus on the 3 P’s:
. . .
“People, Process, Product”
. . .
The Pro t Principles With Marcus Lemonis | The P...
Your early hires should be very strong, senior-level candidates. People who
can hire and mentor other developers, and help the mid-level and junior
developers you’ll eventually want to hire down the road.
Read “Why Hiring is So Hard in Tech” for a good breakdown of the general
do’s and don’ts of candidate evaluation.
. . .
The best way to evaluate a candidate
is a pair programming exercise.
. . .
Pair program with the candidate. Let the candidate drive. Watch and listen
more than you talk. A good project might be to pull tweets from the Twitter
API and display them on a timeline.
That said, no single exercise will tell you everything you need to know. An
interview can be a very useful tool as well, but don’t waste time asking
about syntax or language quirks. You need to see the big picture. Ask about
architecture and paradigms — the big decisions that can have a major impact
on the whole project.
Syntax and features are easy to Google. It’s much harder to Google for
software engineering wisdom or the common paradigms and idioms
JavaScript developers pick up with experience.
JavaScript is special, and it plays a critical role in almost every large
application. What is it about JavaScript that makes it meaningfully different
from other languages?
Here are some questions that will help you explore the stuff that really
matters:
1. Can you name two programming paradigms important for
JavaScript app developers?
JavaScript is a multi-paradigm language, supporting
imperative/procedural programming along with OOP (Object-Oriented
Programming) and functional programming. JavaScript supports OOP
with prototypal inheritance.
Good to hear:
• Prototypal inheritance (also: prototypes, OLOO).
• Functional programming (also: closures, first class functions, lambdas).
Red flags:
• No clue what a paradigm is, no mention of prototypal oo or functional
programming.
Learn More:
• The Two Pillars of JavaScript Part 1 — Prototypal OO.
• The Two Pillars of JavaScript Part 2 — Functional Programming.
2. What is functional programming?
Functional programming produces programs by composing mathematical
functions and avoids shared state & mutable data. Lisp (specified in 1958)
was among the first languages to support functional programming, and was
heavily inspired by lambda calculus. Lisp and many Lisp family languages
are still in common use today.
Functional programming is an essential concept in JavaScript (one of the
two pillars of JavaScript). Several common functional utilities were added to
JavaScript in ES5.
Good to hear:
• Pure functions / function purity.
• Avoid side-effects.
• Simple function composition.
• Examples of functional languages: Lisp, ML, Haskell, Erlang, Clojure,
Elm, F Sharp, OCaml, etc…
• Mention of features that support FP: first-class functions, higher order
functions, functions as arguments/values.
Red flags:
• No mention of pure functions / avoiding side-effects.
• Unable to provide examples of functional programming languages.
• Unable to identify the features of JavaScript that enable FP.
Learn More:
• The Two Pillars of JavaScript Part 2 .
• The Dao of Immutability.
• Professor Frisby’s Mostly Adequate Guide to Functional Programming.
• The Haskell School of Music.
3. What is the di erence between classical inheritance and
prototypal inheritance?
Class Inheritance: instances inherit from classes (like a blueprint — a
description of the class), and create sub-class relationships: hierarchical class
taxonomies. Instances are typically instantiated via constructor functions
with the `new` keyword. Class inheritance may or may not use the `class`
keyword from ES6.
Prototypal Inheritance: instances inherit directly from other objects.
Instances are typically instantiated via factory functions or Òbject.create()`.
Instances may be composed from many different objects, allowing for easy
selective inheritance.
. . .
In JavaScript, prototypal inheritance is simpler &
more exible than class inheritance.
. . .
Good to hear:
• Classes: create tight coupling or hierarchies/taxonomies.
• Prototypes: mentions of concatenative inheritance, prototype
delegation, functional inheritance, object composition.
Red Flags:
• No preference for prototypal inheritance & composition over class
inheritance.
Learn More:
• Common Misconceptions About Inheritance in JavaScript.
4. What are the pros and cons of functional programming vs
object-oriented programming?
OOP Pros: It’s easy to understand the basic concept of objects and easy to
interpret the meaning of method calls. OOP tends to use an imperative style
rather than a declarative style, which reads like a straight-forward set of
instructions for the computer to follow.
OOP Cons: OOP Typically depends on shared state. Objects and behaviors
are typically tacked together on the same entity, which may be accessed at
random by any number of functions with non-deterministic order, which
may lead to undesirable behavior such as race conditions.
FP Pros: Using the functional paradigm, programmers avoid any shared
state or side-effects, which eliminates bugs caused by multiple functions
competing for the same resources. With features such as the availability of
point-free style (aka tacit programming), functions tend to be radically
simplified and easily recomposed for more generally reusable code compared
to OOP.
FP also tends to favor declarative and denotational styles, which do not spell
out step-by-step instructions for operations, but instead concentrate on what
to do, letting the underlying functions take care of the how. This leaves
tremendous latitude for refactoring and performance optimization, even
allowing you to replace entire algorithms with more efficient ones with very
little code change. (e.g., memoize, or use lazy evaluation in place of eager
evaluation.)
Computation that makes use of pure functions is also easy to scale across
multiple processors, or across distributed computing clusters without fear of
threading resource conflicts, race conditions, etc…
FP Cons: Over exploitation of FP features such as point-free style and large
compositions can potentially reduce readability because the resulting code is
often more abstractly specified, more terse, and less concrete.
More people are familiar with OO and imperative programming than
functional programming, so even common idioms in functional
programming can be confusing to new team members.
FP has a much steeper learning curve than OOP because the broad
popularity of OOP has allowed the language and learning materials of OOP
to become more conversational, whereas the language of FP tends to be
much more academic and formal. FP concepts are frequently written about
using idioms and notations from lambda calculus, algebras, and category
theory, all of which requires a prior knowledge foundation in those domains
to be understood.
Good to hear:
• Mentions of trouble with shared state, different things competing for
the same resources, etc…
• Awareness of FP’s capability to radically simplify many applications.
• Awareness of the differences in learning curves.
• Articulation of side-effects and how they impact program
maintainability.
• Awareness that a highly functional codebase can have a steep learning
curve.
• Awareness that a highly OOP codebase can be extremely resistant to
change and very brittle compared to an equivalent FP codebase.
• Awareness that immutability gives rise to an extremely accessible and
malleable program state history, allowing for the easy addition of
features like infinite undo/redo, rewind/replay, time-travel debugging,
and so on. Immutability can be achieved in either paradigm, but a
proliferation of shared stateful objects complicates the implementation
in OOP.
Red flags:
• Unable to list disadvantages of one style or another — Anybody
experienced with either style should have bumped up against some of
the limitations.
Learn More:
• The Two Pillars of JavaScript Part 2 — Functional Programming.
5. When is classical inheritance an appropriate choice?
This is a trick question. The answer is never. I’ve been issuing this challenge
for years, and the only answers I’ve ever heard fall into one of several
common misconceptions. More frequently, the challenge is met with silence.
“If a feature is sometimes useful
and sometimes dangerous
and if there is a better option
then always use the better option.”
~ Douglas Crockford
Good to hear:
• Rarely, almost never, or never.
• “Favor object composition over class inheritance.”
Red flags:
• Any other response.
• “React Components” — no, the pitfalls of class inheritance don’t
change just because a new framework comes along and embraces
the `class` keyword. Contrary to popular awareness, you don’t need to
use `class` to use React. This answer reveals a misunderstanding of
both `class` and React.
Learn More:
• JS Objects — Inherited a Mess.
6. When is prototypal inheritance an appropriate choice?
There is more than one type of prototypal inheritance:
• Delegation (i.e., the prototype chain).
• Concatenative (i.e. mixins, Òbject.assign()`).
• Functional (Not to be confused with functional programming. A
function used to create a closure for private state/encapsulation).
Each type of prototypal inheritance has its own set of use-cases, but all of
them are equally useful in their ability to enable composition, which creates
has-a or uses-a or can-do relationships as opposed to the is-a relationship
created with class inheritance.
Good to hear:
• In situations where modules or functional programming don’t provide
an obvious solution.
• When you need to compose objects from multiple sources.
• Any time you need inheritance.
Red flags:
• No knowledge of when to use prototypes.
• No awareness of mixins or Òbject.assign()`.
Learn More:
• “Programming JavaScript Applications”: Prototypes section.
7. What does “favor object composition over class inheritance”
mean?
This is a quote from “Design Patterns: Elements of Reusable Object-Oriented
Software”. It means that code reuse should be achieved by assembling
smaller units of functionality into new objects instead of inheriting from
classes and creating object taxonomies.
In other words, use can-do, has-a, or uses-a relationships instead of is-a
relationships.
Good to hear:
• Avoid class hierarchies.
• Avoid brittle base class problem.
• Avoid tight coupling.
• Avoid rigid taxonomy (forced is-a relationships that are eventually
wrong for new use cases).
• Avoid the gorilla banana problem (“what you wanted was a banana,
what you got was a gorilla holding the banana, and the entire jungle”).
• Make code more flexible.
Red Flags:
• Fail to mention any of the problems above.
• Fail to articulate the difference between composition and class
inheritance, or the advantages of composition.
Learn More:
Composition over Inheritance
Intro ducing
th e Stamp Specification
Mov e Over, `class`:
Compos able Factory Functions Are Here
m edium.com
8. What are two-way data binding and one-way data ow, and
how are they di erent?
Two way data binding means that UI fields are bound to model data
dynamically such that when a UI field changes, the model data changes with
it and vice-versa.
One way data flow means that the model is the single source of truth.
Changes in the UI trigger messages that signal user intent to the model (or
“store” in React). Only the model has the access to change the app’s state.
The effect is that data always flows in a single direction, which makes it
easier to understand.
One way data flows are deterministic, whereas two-way binding can cause
side-effects which are harder to follow and understand.
Good to hear:
• React is the new canonical example of one-way data flow, so mentions
of React are a good signal. Cycle.js is another popular implementation
of uni-directional data flow.
• Angular is a popular framework which uses two-way binding.
Red flags:
• No understanding of what either one means. Unable to articulate the
difference.
Learn more:
Introduction to React.js
9. What are the pros and cons of monolithic vs microservice
architectures?
A monolithic architecture means that your app is written as one cohesive
unit of code whose components are designed to work together, sharing the
same memory space and resources.
A microservice architecture means that your app is made up of lots of
smaller, independent applications capable of running in their own memory
space and scaling independently from each other across potentially many
separate machines.
Monolithic Pros: The major advantage of the monolithic architecture is that
most apps typically have a large number of cross-cutting concerns, such as
logging, rate limiting, and security features such audit trails and DOS
protection.
When everything is running through the same app, it’s easy to hook up
components to those cross-cutting concerns.
There can also be performance advantages, since shared-memory access is
faster than inter-process communication (IPC).
Monolithic cons: Monolithic app services tend to get tightly coupled and
entangled as the application evolves, making it difficult to isolate services for
purposes such as independent scaling or code maintainability.
Monolithic architectures are also much harder to understand, because there
may be dependencies, side-effects, and magic which are not obvious when
you’re looking at a particular service or controller.
Microservice pros: Microservice architectures are typically better
organized, since each microservice has a very specific job, and is not
concerned with the jobs of other components. Decoupled services are also
easier to recompose and reconfigure to serve the purposes of different apps
(for example, serving both the web clients and public API).
They can also have performance advantages depending on how they’re
organized because it’s possible to isolate hot services and scale them
independent of the rest of the app.
Microservice cons: As you’re building a new microservice architecture,
you’re likely to discover lots of cross-cutting concerns that you did not
anticipate at design time. A monolithic app could establish shared magic
helpers or middleware to handle such cross-cutting concerns without much
effort.
In a microservice architecture, you’ll either need to incur the overhead of
separate modules for each cross-cutting concern, or encapsulate cross-
cutting concerns in another service layer that all traffic gets routed through.
Eventually, even monolthic architectures tend to route traffic through an
outer service layer for cross-cutting concerns, but with a monolithic
architecture, it’s possible to delay the cost of that work until the project is
much more mature.
Microservices are frequently deployed on their own virtual machines or
containers, causing a proliferation of VM wrangling work. These tasks are
frequently automated with container fleet management tools.
Good to hear:
• Positive attitudes toward microservices, despite the higher initial cost vs
monolthic apps. Aware that microservices tend to perform and scale
better in the long run.
• Practical about microservices vs monolithic apps. Structure the app so
that services are independent from each other at the code level, but
easy to bundle together as a monolithic app in the beginning.
Microservice overhead costs can be delayed until it becomes more
practical to pay the price.
Red flags:
• Unaware of the differences between monolithic and microservice
architectures.
• Unaware or impractical about the additional overhead of microservices.
• Unaware of the additional performance overhead caused by IPC and
network communication for microservices.
• Too negative about the drawbacks of microservices. Unable to articulate
ways in which to decouple monolithic apps such that they’re easy to
split into microservices when the time comes.
• Underestimates the advantage of independently scalable microservices.
10. What is asynchronous programming, and why is it important
in JavaScript?
Synchronous programming means that, barring conditionals and function
calls, code is executed sequentially from top-to-bottom, blocking on long-
running tasks such as network requests and disk I/O.
Asynchronous programming means that the engine runs in an event loop.
When a blocking operation is needed, the request is started, and the code
keeps running without blocking for the result. When the response is ready,
an interrupt is fired, which causes an event handler to be run, where the
control flow continues. In this way, a single program thread can handle
many concurrent operations.
User interfaces are asynchronous by nature, and spend most of their time
waiting for user input to interrupt the event loop and trigger event handlers.
Node is asynchronous by default, meaning that the server works in much
the same way, waiting in a loop for a network request, and accepting more
incoming requests while the first one is being handled.
This is important in JavaScript, because it is a very natural fit for user
interface code, and very beneficial to performance on the server.
Good to hear:
• An understanding of what blocking means, and the performance
implications.
• An understanding of event handling, and why its important for UI code.
Red flags:
• Unfamiliar with the terms asynchronous or synchronous.
• Unable to articulate performance implications or the relationship
between asynchronous code and UI code.
Learn more:
Philip Roberts: What the heck is the event loop an...
. . .
Conclusion
That’s it for the interview. Stick to high-level topics. If they can answer these
questions, that typically means that they have enough programming
experience to pick up language quirks & syntax in a few weeks, even if they
don’t have a lot of JavaScript experience.
Don’t disqualify candidates based on stuff that’s easy to learn (including
classic CS-101 algorithms, or any type of puzzle problem).
What you really need to know is, “does this candidate understand how to
put an application together?”
. . .
Level up your skills with courses & webcasts on ES6, TDD,
prototypal OO, React. $495 Lifetime Access
. . .
Eric Elliott is the author of “Programming JavaScript Applications” (O’Reilly),
and “Learn JavaScript Universal App Development with Node, ES6, & React”.
He has contributed to software experiences for Adobe Systems, Zumba
Fitness, The Wall Street Journal , ESPN, BBC, and top recording artists
including Usher, Frank Ocean, Metallica, and many more.
He spends most of his time in the San Francisco Bay Area with the most
beautiful woman in the world.

10 Interview Questions Every JavaScript Developer Should Know - JavaScript Scene - Medium

Uploaded by

Copyright:

Available Formats

10 Interview Questions Every JavaScript Developer Should Know - JavaScript Scene - Medium

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

10 Interview Questions Every JavaScript Developer Should Know - JavaScript Scene - Medium

Uploaded by

Copyright:

Available Formats

8/1/2016 10 Interview Questions Every JavaScript Developer Should Know — JavaScript Scene — Medium

Every JavaScript Developer

Bruce Lee on the Avenue — Leevin (CC BY-NC . )

At most companies, management must trust the developers to give technical

interviews in order to assess candidate skills. If you do well as a candidate,

you’ll eventually need to interview. Here’s how.

You Might Not Agree, and That s OK ’

inheritance. Why? Because people who love it are obstinately stubborn

“Those who are unaware

will never seek the light. ”

I won’t hire them. You shouldn’t, either.

brilliant people disagree with my views. However, before dismissing my

opinion out of hand, consider these points:

and fortune 500 companies. I have a background in C++/Java (and

assembly, AutoLisp, Delphi, etc…), and I consulted on dozens of Java and

C++ apps (both class-oriented OOP languages). I was once an avid

supporter of classical inheritance, and even wrote multi-language Rapid

Application Development (RAD) tools for it.

seen products abruptly discontinued to stop losses, programmers laid oﬀ,

and companies brought to their knees by brittle, tangled codebases caused

primarily by the improper use of classes and class inheritance.

infects everything it touches. It came to us formally in JavaScript with ES6,

supports pure function components, or try react-stamp).

This has caused confusion and incompatibility between React components

and other composable elements in the React ecosystem (components,

mixins, and component wrappers).

classes), I watched a once malleable codebase transform into a brittle mess.

I saw code complicated by abstractions necessary to unify the calling API of

dependency injection container that ended up coupling every dependent

create services, and features a dependency injection container to abstract

titles like “Object Oriented Programming Considered Harmful”, “Class

Considered Harmful”, and “New Considered Harmful”. Such warnings have

been published on Usenet, in academic papers, and respected publications

such as Doctor Dobb’s Journal: a magazine that gave us nearly 40 years of

software development wisdom before its sunset at the end of 2014.

Incidentally, there’s also an essay called “Considered Harmful Considered

Harmful”, but I digress.

Joe Armstrong, the creator of Erlang summed up one of the famous

great stuﬀ in it):

The seminal tome of OO design, “Design Patterns: Elements of Reusable

“Favor object composition

* A Simple Challenge to Classical Inheritance Fans

* Common Misconceptions About Inheritance in JavaScript

* How to Fix the ES6 `class` Keyword

* Introducing the Stamp Speciﬁcation

what you like, toss the rest. I won’t be oﬀended.

It Starts With People

In “How to Build a High Velocity Development Team” , I made a couple

points worth repeating:

“Nothing predicts business outcomes better than an exceptional team. If you’re

going to beat the odds, you need to invest here, ﬁrst.”

As Marcus Lemonis says, focus on the 3 P’s:

“People, Process, Product”

The Pro t Principles With Marcus Lemonis | The P...

developers you’ll eventually want to hire down the road.

do’s and don’ts of candidate evaluation.

The best way to evaluate a candidate

is a pair programming exercise.