10 ms·

Answers to front-end developer job interview questions

217 points by happy-go-lucky 9y ago

colordrops 9y ago
This is a _webtech_ front end interview handbook.
- Dude2021 9y ago
  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?”.
  - scarface74 9y ago
    The fundamentals don't change every 1-3 years. Most of these questions would have been relevant 5 years ago.
  - banachtarski 9y ago
    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.
- coderdude 9y ago
  So what? Maybe you're wrong. Maybe someone more smart and pedantic than even yourself can put an adjective between underscores that blows you out of the water and makes you question what you even think underscores as emphasis even means. That's when you have him. Edit: Kappa
realharo 9y ago
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.
- coppolaemilio 9y ago
  Yeah, I prefer working with the person 10 times more than selecting only based on a test.
- ht_th 9y ago
  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 9y ago
    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 9y ago
      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.
xor1 9y ago
This is pretty nice, anyone know of something similar for iOS?
- meggar 9y ago
  Here are some algorithms in Swift: https://github.com/raywenderlich/swift-algorithm-club https://github.com/raywenderlich/swift-algorithm-club
banachtarski 9y ago
Does anyone else get peeved by the fact that "front end" is now synonymous with "web front end?"
- TeMPOraL 9y ago
  Nah, that ship sailed a hundred thousand web-years ago. I think non-web "front end" is usually called GUI or Desktop Development (or Mobile Development for mobile platforms)?
- Ensorceled 9y ago
  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 9y ago
    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.
weego 9y ago
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.
- BillinghamJ 9y ago
  Depends whether the company is hiring for someone who can just get the job done, or whether they’re hiring for someone who understands the underlying reasons behind the choices they’re making, the things they’re using, etc. Some companies only need the former, but many - particularly tech-heavy companies - want the latter. That isn’t unreasonable, but it means that the people who can get the job done, but don’t have the depth of understanding, won’t be suitable.
- poisonborz 9y ago
  "...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 9y ago
    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?
erikrothoff 9y ago
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 9y ago
  Your friend is probably a very good designer but not a developer in the usual sense.
  - detaro 9y ago
    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 9y ago
      He doesn't know what a linked list is? Srsly?
      - detaro 9y ago
        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 9y ago
        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.
Blackstone4 9y ago
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 9y ago
  I can assure you that building things will teach you more than reading off a massive list of facts.
- alangpierce 9y ago
  You definitely don't need to know all of this in order to be a good frontend developer. There's plenty of "core skill" that isn't really covered here, and that's probably what interviews should focus most on. I really like this list because it exposes many of the "corners" of knowledge in frontend work. Many of the questions expose things that I don't know and would like to know, or questions where I only have a vague answer and would like a more confident answer.
geekamongus 9y ago
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.
joeblau 9y ago
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
jasim 9y ago
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.
- poisonborz 9y ago
  I partially disagree. "Can you think, can you write, can you build" are important, but difficult and time consuming to test, especially if there are a lot of (initial) candidates to choose from. Theoretical/trivia questions do give quick overview of field knowledge, especially connecting them thematically. For coding, 4-6 line "refactor this" tasks do the same. Candidate shouldn't even write, discussing solutions in pseudocode is enough. After jumping this bar, one can make more freeform discussions or do pair programming.
  - zbentley 9y ago
    I think selecting a first-line interviewing strategy depends on how many candidates you have for the job. Do you have a large number of candidates for a small number of positions? Then tune your process to very quickly eliminate anyone who might not make the cut, at the cost of many false negatives (qualified people who are removed from the process due to e.g. not knowing trivia). This is the Google approach. Do you have a small number of candidates? Then interview for comprehension/ability to think and work with others, at the cost of more time spent interviewing and potentially more time spent mentoring qualified hires in specific trivia/skills needed to execute. This is the smaller company/less-well-known company approach. Most of the truly egregious failures in interviewing (not just in software!) come about due to companies picking the wrong strategy given their situation.
twright 9y ago
Does anyone know of any equivalent "handbooks" for other domains like back end or machine learning?
- laichzeit0 9y ago
  Dear god, I shudder to know why you are asking this..
  - twright 9y ago
    Huh? Because sample interview questions would be nice to read over if someone was not interviewing for something that is not front end?
sigi45 9y ago
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.
tambourine_man 9y ago
And yet the anchor links don’t work
sklivvz1971 9y ago
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 9y ago
  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 9y ago
    Woah, woah, woah. Let's not start doing in interviews what we all do when working. That's crazy talk!
    - nojvek 9y ago
      We allow devs to use google and stack overflow while doing interviews. You can even use your own editor with whatever crazy extensions you want. Just write good code is the motto!
    - gambler 9y ago
      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.
  - alangpierce 9y ago
    If you're doing an interview over the phone or in some other context where the interviewer can't see what you're doing, you should NOT just look things up on the internet without first asking if it's ok. That is cheating in every interview I have given. It's unethical, and you really don't want to start off a job having tricked your peers into thinking you know more off the top of your head than you actually do. Testing what people know off the top of their head and testing how well people can look things up on the internet are both legitimate things to test in an interview setting, and I've done both types of interviews. One big downside to letting people use the internet is that it tends to slow down the interview significantly and it adds variability unrelated to the skill of the candidate (e.g. maybe you got unlucky in your search terms and found an unrelated/unhelpful result that took up a bunch of time). In many cases, it's better to get a sense of which concepts the candidate is already comfortable and experienced with, which isn't something that should require the internet. (I tend to avoid tests of knowledge in the first place, but I think they make plenty of sense when hiring for a specialized role.) It's also naive to think that (for example) someone who hasn't heard of CSS specificity could be just as productive solving a specificity-related CSS issue than someone who has solved a bunch of specificity-related problems in the past, as long as both of them have access to Stack Overflow.
simonpantzare 9y ago
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 9y ago
  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 9y ago
    Each Hacker News commenter believes that the exact set of topics that they are knowledgeable on are requisite to be a software engineer.
  - simonpantzare 9y ago
    Nothing against specialization really. I wouldn't hire a chef who doesn't know how to work a knife though. :)
brwsr 9y ago
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.
klenwell 9y ago
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 9y ago
  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.
- neon_electro 9y ago
  Bootstrap can serve as a good example of how to organize z-indexes: https://getbootstrap.com/docs/4.0/layout/overview/#z-index https://getbootstrap.com/docs/4.0/layout/overview/#z-index
nojvek 9y ago
As a senior FE engineer, I have a lot to learn. Some of the questions are sneaky and interesting.
pleasecalllater 9y ago
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 9y ago
  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 9y ago
    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 :)
- pault 9y ago
  The correct answer is "don't use JavaScript to write accounting software."
Yhippa 9y ago
As a back-end fullstack developer this guide is great. Allows me to fill some gaps in a very readable and concise way.
ivankolev 9y ago
the section about local storage is wrong, localStorage and sessionStorage are definitely domain scoped, it will be an egregious security hole otherwise
CSMastermind 9y ago
Don't take a job where the interview includes trivia questions.

This is a _webtech_ front end interview handbook.

Dude2021 9y ago
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?”.
- scarface74 9y ago
  The fundamentals don't change every 1-3 years. Most of these questions would have been relevant 5 years ago.
- banachtarski 9y ago
  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.
coderdude 9y ago
So what? Maybe you're wrong. Maybe someone more smart and pedantic than even yourself can put an adjective between underscores that blows you out of the water and makes you question what you even think underscores as emphasis even means. That's when you have him. Edit: Kappa

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.

coppolaemilio 9y ago
Yeah, I prefer working with the person 10 times more than selecting only based on a test.
ht_th 9y ago
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 9y ago
  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 9y ago
    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.

xor1 9y ago

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

meggar 9y ago
Here are some algorithms in Swift: https://github.com/raywenderlich/swift-algorithm-club https://github.com/raywenderlich/swift-algorithm-club

banachtarski 9y ago

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

TeMPOraL 9y ago
Nah, that ship sailed a hundred thousand web-years ago. I think non-web "front end" is usually called GUI or Desktop Development (or Mobile Development for mobile platforms)?
Ensorceled 9y ago
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 9y ago
  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.

weego 9y ago

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.

BillinghamJ 9y ago
Depends whether the company is hiring for someone who can just get the job done, or whether they’re hiring for someone who understands the underlying reasons behind the choices they’re making, the things they’re using, etc. Some companies only need the former, but many - particularly tech-heavy companies - want the latter. That isn’t unreasonable, but it means that the people who can get the job done, but don’t have the depth of understanding, won’t be suitable.
poisonborz 9y ago
"...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 9y ago
  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?

erikrothoff 9y ago

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 9y ago
Your friend is probably a very good designer but not a developer in the usual sense.
- detaro 9y ago
  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 9y ago
    He doesn't know what a linked list is? Srsly?
    - detaro 9y ago
      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 9y ago
        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.

Blackstone4 9y ago

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 9y ago
I can assure you that building things will teach you more than reading off a massive list of facts.
alangpierce 9y ago
You definitely don't need to know all of this in order to be a good frontend developer. There's plenty of "core skill" that isn't really covered here, and that's probably what interviews should focus most on. I really like this list because it exposes many of the "corners" of knowledge in frontend work. Many of the questions expose things that I don't know and would like to know, or questions where I only have a vague answer and would like a more confident answer.

geekamongus 9y ago

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.

joeblau 9y ago

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

jasim 9y ago

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.

poisonborz 9y ago
I partially disagree. "Can you think, can you write, can you build" are important, but difficult and time consuming to test, especially if there are a lot of (initial) candidates to choose from. Theoretical/trivia questions do give quick overview of field knowledge, especially connecting them thematically. For coding, 4-6 line "refactor this" tasks do the same. Candidate shouldn't even write, discussing solutions in pseudocode is enough. After jumping this bar, one can make more freeform discussions or do pair programming.
- zbentley 9y ago
  I think selecting a first-line interviewing strategy depends on how many candidates you have for the job. Do you have a large number of candidates for a small number of positions? Then tune your process to very quickly eliminate anyone who might not make the cut, at the cost of many false negatives (qualified people who are removed from the process due to e.g. not knowing trivia). This is the Google approach. Do you have a small number of candidates? Then interview for comprehension/ability to think and work with others, at the cost of more time spent interviewing and potentially more time spent mentoring qualified hires in specific trivia/skills needed to execute. This is the smaller company/less-well-known company approach. Most of the truly egregious failures in interviewing (not just in software!) come about due to companies picking the wrong strategy given their situation.

twright 9y ago

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

laichzeit0 9y ago
Dear god, I shudder to know why you are asking this..
- twright 9y ago
  Huh? Because sample interview questions would be nice to read over if someone was not interviewing for something that is not front end?

sigi45 9y ago

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.

tambourine_man 9y ago

And yet the anchor links don’t work

sklivvz1971 9y ago

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 9y ago
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 9y ago
  Woah, woah, woah. Let's not start doing in interviews what we all do when working. That's crazy talk!
  - nojvek 9y ago
    We allow devs to use google and stack overflow while doing interviews. You can even use your own editor with whatever crazy extensions you want. Just write good code is the motto!
  - gambler 9y ago
    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.
- alangpierce 9y ago
  If you're doing an interview over the phone or in some other context where the interviewer can't see what you're doing, you should NOT just look things up on the internet without first asking if it's ok. That is cheating in every interview I have given. It's unethical, and you really don't want to start off a job having tricked your peers into thinking you know more off the top of your head than you actually do. Testing what people know off the top of their head and testing how well people can look things up on the internet are both legitimate things to test in an interview setting, and I've done both types of interviews. One big downside to letting people use the internet is that it tends to slow down the interview significantly and it adds variability unrelated to the skill of the candidate (e.g. maybe you got unlucky in your search terms and found an unrelated/unhelpful result that took up a bunch of time). In many cases, it's better to get a sense of which concepts the candidate is already comfortable and experienced with, which isn't something that should require the internet. (I tend to avoid tests of knowledge in the first place, but I think they make plenty of sense when hiring for a specialized role.) It's also naive to think that (for example) someone who hasn't heard of CSS specificity could be just as productive solving a specificity-related CSS issue than someone who has solved a bunch of specificity-related problems in the past, as long as both of them have access to Stack Overflow.

simonpantzare 9y ago

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 9y ago
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 9y ago
  Each Hacker News commenter believes that the exact set of topics that they are knowledgeable on are requisite to be a software engineer.
- simonpantzare 9y ago
  Nothing against specialization really. I wouldn't hire a chef who doesn't know how to work a knife though. :)

brwsr 9y ago

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.

klenwell 9y ago

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 9y ago
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.
neon_electro 9y ago
Bootstrap can serve as a good example of how to organize z-indexes: https://getbootstrap.com/docs/4.0/layout/overview/#z-index https://getbootstrap.com/docs/4.0/layout/overview/#z-index

nojvek 9y ago

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

pleasecalllater 9y ago

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 9y ago
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 9y ago
  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 :)
pault 9y ago
The correct answer is "don't use JavaScript to write accounting software."

Yhippa 9y ago

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

ivankolev 9y ago

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

CSMastermind 9y ago

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