
Answers to front-end developer job interview questions - happy-go-lucky
https://github.com/yangshun/front-end-interview-handbook
======
jasim
If you're new to front-end development and this questionnaire freaks you out,
that's okay. This is probably useful for the author as a preparation aid, or
for programmers whose interviewing style is based on regurgitating trivia. And
this is trivia - man-made transient factoids, most of which are quirks of
history that will go out of fashion in a few years.

This is not how a well-run interview happens. Can you read things and
comprehend them? Can you think? Can you write? Can you be kind? Can you be
professional in times of stress? Ultimately, can you build? If you can and if
you've already built things, go into the interview so that you can speak about
the things you know, the things you have opinions on, the things you've built
and the things you want to build. If it is a good interviewer on the other end
you'll have a good time jamming with a fellow maker; if it is a bad
interviewer they'll ask you questions from a checklist they collected maybe
from this handbook, and it is best that you don't work with those people.

~~~
crazygringo
Honestly? If this were back-end programming I'd agree, but as someone who's
done a tremendous amount of front-end programming, the guide feels spot-on.

Sure many of these questions are "quirks of history", but your job as an
effective front-end programmer is to know them so your site works everywhere
where it's supposed to, and you have the knowledge to make the right trade-
offs between legacy support and future maintainability. Front-end programming
really is much more about sheer accumulated _knowledge_ than back-end is --
and it's not knowledge you can just "look up", because a huge part is knowing
the gotchas in advance, in order to avoid them.

This shouldn't be a _whole_ interview -- all the things you list are important
too -- but validating a candidate's experience of all these "transient
factoids" is not just valid but necessary, like it or not.

~~~
qualitytime
What a b_ll_x reply to a sensible comment.

Mate, the personal website url you list in your HN profile don't work.

Funny that this is about frontend.

------
realharo
I find the whole concept of "preparing for an interview" kinda strange.

I understand why people do it, and I certainly wouldn't fault anyone for
giving themselves the best possible chance. But at a certain level, it really
feels like trying to cheat the system.

In an ideal world, a normal conversation about the technology - your opinions,
preferences and experiences regarding it - should be able to reveal what the
interviewer needs to know.

~~~
ht_th
True.

I've never been asked these kinds of "knowledge" questions in any interview.
Nor have I asked them of any candidate. To me, interviewing is more about
finding a fit to the company's and team's culture, than to ascertain if a
candidate knows what she is supposed to know. Even if a candidate succeeds in
bluffing her way through an interview, she will fall short in the one-month
trial period.

I like the one-month trial period. I've walked away twice during the trial
period from a company because they were a lot less organized than they did
appear during the interviews. Similarly, we have let go of a couple of
employees during their one-month trial because they were unable to learn fast
enough or were too arrogant.

~~~
nojvek
How does one even hire senior folks on a trial period?

So you work at this big co. How about you leave your job and come work for us
and we may fire you after a month?

The best people are never on the market. You have to get them before they even
leave their existing company otherwise someone else will

~~~
ht_th
What's the difference? The intention of employing them is to offer them a
permanent contract, but if things do not work out, firing people is hard. So,
we almost always have three stages when we employ someone:

\- one-month trial period \- one-year contract \- permanent contract

For senior people, the trial period is more of a formality as they are often
quick to become productive in the organization. Of course, when after a couple
of months it is discovered that the new senior and management do have a
fundamental difference of opinion with regard to the future of the
organization, professionally, or even personally, the end of the one-year
contract is the moment to part ways. This can be initiated by employer,
employee, or even both, but that depends on the situation.

~~~
toomuchtodo
What do you offer that makes a contract position attractive versus other
companies that will bring you on permanently immediately?

~~~
ht_th
Nothing. It is quite common to do it like this here in the Netherlands. Of
course, once we have a new employee and after a couple of months we think she
is a great addition to the team, we will start negotiate for the permanent
contract immediately.

Our team consists of experienced and above-average educated developers. We are
not looking to attract that one 10x developer, nor do we desperately need a
senior developer now. We sort of have too many senior level developers; our
retention is high. Anyway, we are looking for similarly educated and
experienced people that fit our team, and we offer a culture where such a
person can thrive. We prefer to take a while longer to find and grow a great
match rather than to gamble on potential talent that might leave again soon.

On the other hand, we do need new developers, particularly specialists, and we
have gotten to the point that we are willing to take more risk. But the
organization as a whole is still figuring out how to grow beyond a 10 person
post-startup development team towards a 100+ person company (we merged with
our biggest partner).

------
weego
Some if these are just kinda...why does it matter. Honestly who cares what a
doctype does/is for when you only ever use one from a boilerplate.

For most people in most companies weeding out the overly zealous, the ones who
are unable to be pragmatic and the ones who can't play well in a team or in
front of clients instead of biasing selection on technical knowledge is far
more beneficial to the business.

Spending some time pair programming in an interview doing something actually
relevant to the job is much more enlightening than throwing questions.

~~~
poisonborz
"...who cares what a doctype does/is for when you only ever use one from a
boilerplate..."

This sums up many of the front-end candidates nowadays. Reminds me of "why do
I have to know what XMLHttpRequest or a browser event is, I just use jQuery
.ajax() and .on() anyway" from a few years ago.

~~~
xtrapolate
This same logic can literally be applied to anyone working on anything.
Engineers, carpenters, pilots, literally anyone.

I bet there are many people who know everything about "XMLHttpRequest", but
know nothing about congestion control. Or how a network stack comes
together...

You do realize "XMLHttpRequest" wasn't even a thing until several years ago,
and it's safe to assume further down the road it may well be phased out (in
favor of better/more secure APIs).

Instead of asking about "XMLHttpRequest", wouldn't it be better to talk about
the general need for "websites" to communicate with a backend on demand, at
runtime, after everything has been loaded and rendered? Or, put
"XMLHttpRequest" on the table, and talk about how one would implement such an
API within the context of a browser?

~~~
mysore
xmlhttprequest has been obsolete for 3-4 years.

[https://developer.mozilla.org/en-
US/docs/Web/API/Fetch_API/U...](https://developer.mozilla.org/en-
US/docs/Web/API/Fetch_API/Using_Fetch)

~~~
LaGrange
It's used everywhere though, so you'll likely still encounter.

In fact you'll probably encounter it in code your coworker wrote 15 minutes
ago.

:[

------
simonpantzare
I'm doing backend development but interact with frontend developers all the
time. Something I've noticed, especially among younger devs, is that they are
sometimes unknowledgeable about how HTTP, DNS, certificates, and related tech
work, and have a hard time grasping why state persistence and synchronization
need to be done a certain way. The problems arise when something goes wrong
and they immediately need support from backend, when a little more knowledge
about the technologies below React or Angular would suffice.

~~~
allsunny
Sure, but to be fair, I've met plenty of back-end developers, even senior
ones, who don't know the intricacies of DNS, certificates, OS, etc. It's best
to recognize the domain is enormous and a lot of folks have a desire, or
arguably a requirement, to specialize.

I'm reasonably certain that if we created a union of all of the topic sets
that HackerNews commenters identified as requisite knowledge to be a software
engineer it would take a lifetime to plow through.

Like putting together a winning baseball team, it's best to recognize that
your team wins when you put together a group of contributors that contribute
their specific honed skills.

"Try to learn something about everything and everything about something." \-
Thomas Huxley

~~~
woah
Each Hacker News commenter believes that the exact set of topics that they are
knowledgeable on are requisite to be a software engineer.

------
sklivvz1971
Most of the questionnaire is (in my humble opinion) absolutely bad, as it
focuses on stuff that you either know on the top of your head or you don't.

I'm sorry, but I'd rather hire someone that can't describe all the nitty
gritties of `float`, but that can _think properly_.

Questions that can be looked up on Stack Overflow in 2 minutes are absolutely
useless in hiring someone. They just favor people that have better memory.

~~~
zappo2938
If someone asks me a question that I don't know in an interview, I'm going to
search the answer on Stack Exchange. If the person has an issue with that, I
probably wouldn't be happy working there and should move on sooner than later.

~~~
mathgeek
Woah, woah, woah. Let's not start doing in interviews what we all do when
working. That's crazy talk!

~~~
gambler
You mean you actually look things up on the Internet when you work? How
unprofessional!

I for one rote-memorize all the aspects of languages and frameworks before
using them. If I can't remember the name of some function, I just implement it
from scratch using my superior knowledge or algorithms and data structures.
Also, I write code on etch-a-sketch (sometimes whiteboard) in one go and then
let a trained monkey type it into an IDE on a computer.

------
Blackstone4
Damn..... I've been learning and actively using React + Bootstrap over the
last 8 months. I can barely answer any of these questions....probably the only
one I can answer is fizz buzz.....

Is it just me but do you even need to know all of this to make an SPA? If I
need to know something, I just go and figure it out.

~~~
Introvertuous
I can assure you that building things will teach you more than reading off a
massive list of facts.

------
brwsr
I am a full stack senior with quite some years of experience. I use the
internet when I have the tiniest bit of doubt about any of these questions. To
get my app right and have fewer bugs I tend to use my own memory less because
it's simply not reliable. Another reason to look up things is that standards
change over time.

Why would you need a handbook like this in the first place? Clearly because
your memory is not reliable. So the interviewer acknowledges his own poor
memory, using this handbook to find a candidate with better memory? Oh my..

I know hiring is hard, but this doesn't cut it at all IMAO.

------
joeblau
This would be really cool as a GitBook[1]. That way people could download a
clean pdf, mobi, or ePub file while still maintaining open contribution.

[1] - [https://www.gitbook.com](https://www.gitbook.com)

------
sigi45
I like stuff like these handbooks.

Because i see my work / skill not only in 'i'm doing what i'm doing and i'm
good in exaclty what i'm doing' but more like 'i like software development and
i should know more about that than just what i need right now'.

I also take interviews more serious than before: Its always a good chance to
evolve. Thinking about technologies in a different angle.

Understanding products on version number level. Really trying to understand
what i'm doing.

------
geekamongus
This looks more like a list of questions you'd prepare in order to show your
boss that you are a good interviewer, not to find the right candidate for a
position.

------
banachtarski
Does anyone else get peeved by the fact that "front end" is now synonymous
with "web front end?"

~~~
Ensorceled
It’s always been synonymous with “web front end”. I was hiring “GUI
Developers” in the 80’s and 90’s not “Motif Front End Developers”

~~~
perl4ever
I was curious so I searched Google Books for the phrase "front end developer".
It appears that before 1995, it was used to refer to a software product called
"Front End Developer" and it was also used to refer to a tech company (as
opposed to an individual) that developed the "front end" for a larger system.

------
klenwell
On this one:

> Describe z-index and how stacking context is formed.

I have another question: what are best practices for using z-index and simply
setting z-index values?

This came up at my last company where we had some huge unruly stylesheets with
what looked like arbitrary z-index values sprinkled throughout (e.g. 1, 100,
660, 661, 10000). I guess maybe this is the answer: keep your stylesheets
organized from the start.

I had added an action item to draw up some best practices for using z-index
but never got a chance to get to it before I left. I did do some cursory
googling and didn't come across anything especially enlightening on the topic.

The links provided in this section of this guide explain how it works but
don't really address this question. Can anybody point to a good reference for
using (as opposed to explaining) z-indexes?

~~~
nojvek
Try to use a css preprocessor like sass, less, stylus.

Now make a file Called z-index.styl

Make variables for all your z indexes used in the app, organized by stack
level

Do not use a z-index directly in css. Always use a variable after you import
the file. This means you can see all the z-indexes in the app and change them
atomically if you want.

------
pleasecalllater
I'd add this one: can you explain how you are going to make exact number
operations on the website, e.g. for calculating an invoice according to the
law, when you have only float type in JS? Any answer "I don't care" would
automatically fail any interview, as any programmer who doesn't care for the
program correctness or working according to the business rules should be
automatically fired.

~~~
alangpierce
Have you really had people answer "I don't care" to an interview question?
I've done a lot of interviews and I don't think I've ever heard that.

My impression is that mistakes due to floating point issues are usually due to
ignorance (not understanding floating point nuances) or oversight, or due to
an incorrect judgement call that it won't matter. (And really, I think that in
the vast majority of situations, normal float math is fine. The backend should
be doing the important math anyway.) "Automatically fired" seems very harsh in
these situations, or even the situation you described.

~~~
pleasecalllater
I haven't, however for the last 20 years I've been working with people who
didn't care about things like that. The worst thing is that they were proud of
that, and they got promoted quite fast. Of course the software was buggy, but
the manager got bonus for deploying things on time :)

------
twright
Does anyone know of any equivalent "handbooks" for other domains like back end
or machine learning?

~~~
laichzeit0
Dear god, I shudder to know why you are asking this..

~~~
twright
Huh? Because sample interview questions would be nice to read over if someone
was not interviewing for something that is not front end?

------
xor1
This is pretty nice, anyone know of something similar for iOS?

~~~
meggar
Here are some algorithms in Swift: [https://github.com/raywenderlich/swift-
algorithm-club](https://github.com/raywenderlich/swift-algorithm-club)

------
ivankolev
the section about local storage is wrong, localStorage and sessionStorage are
definitely domain scoped, it will be an egregious security hole otherwise

------
Yhippa
As a back-end fullstack developer this guide is great. Allows me to fill some
gaps in a very readable and concise way.

------
nojvek
As a senior FE engineer, I have a lot to learn. Some of the questions are
sneaky and interesting.

------
CSMastermind
Don't take a job where the interview includes trivia questions.

------
tambourine_man
And yet the anchor links don’t work

------
colordrops
This is a _webtech_ front end interview handbook.

~~~
Dude2021
And it misses the important question: “what is your 1-3 year plan for when new
web assembly GUI frameworks make 75% of your knowledge obsolete?”.

~~~
banachtarski
When we get closer to the reality that a game like Grand Theft Auto or
something runs in your browser without audio hitching, asset streaming and
more, maybe this will make sense. 1-3 years though? Seems dubious.

------
erikrothoff
A friend of mine (who also happens to be the best developer I've ever had the
pleasure of working with) was interviewing for a web frontend job. He didn't
get it because he couldn't answer the question "What is a linked list?" I'm
surprised to see that this handbook does not include that question (hint:
sarcasm)

~~~
leaveyou
Your friend is probably a very good designer but not a developer in the usual
sense.

~~~
detaro
Since linked lists are a concept you don't need in many languages, I don't
think you can nowadays say someone not knowing about them is "not a
developer". They are a developer without knowledge of some fundamentals, but
they can be perfectly productive as a developer without that knowledge.

~~~
sigi45
He doesn't know what a linked list is? Srsly?

~~~
detaro
Yes, seriously. If someone learns programming with JS (or Python or ...) and
has neither been interested in nor exposed through work to lower levels they
can easily go years of professional work without having to deal with the
concept (not meaning that they wouldn't understand it, just that it never came
up). Thanks to abstraction, you can go far without really knowing what's
happening below, and that has moved up the layers more and more.

Where does a JS frontend developer really need to have heard of linked lists?

~~~
leaveyou
JS and Python can't decide what's best for your problem: an array or a linked
list. It's the programmer who decides these things. I'm currently working on a
project started by people who apparently were completely unaware (among other
intellectual obscenities) that it's not OK to return a long list of integers
by concatenating them into a long string only to split and parse them again
later when some subset of this list was needed. Recently, due to increased
traffic, the web service kept crashing.. with 64GB of RAM. Some of these
people are probably on this forum, trying to justify why "you can be
productive" without knowing wtf you are actually doing.

~~~
always_good
To be fair, languages like Ruby and Javascript only have one sequence
container in their standard lib and the difference just doesn't come up for
most people most of the time. Just like how most day-to-day data for most
people probably fits in array with a capacity <100\. And the most common day-
to-day operations are array[0] and array.append().

And even when it's thrown in your face like listOf() vs arrayOf() in Kotlin or
[] vs '() in Clojure, one is the conventional default that you use most of the
time anyways.

That said, someone who doesn't know what a linked list may also be lacking
experience with many other things that you would expect from a candidate, but
it's no mystery how someone can go far without really encountering one.

