4 ms·

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 p

by 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.
crazygringo 9y ago
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 9y ago
  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.
indescions_2018 9y ago
Seems a pretty solid list to me ;) It's a decent representation of your journey on the path to mastery. With a few years experience building several large (10K+ users) sites. One should at least have an opinion on 80-90% of this material. It demonstrates a proclivity to dive deep into web technologies. And a willingness to understand rather than simply mimic. The number of folks who claim proficiency, but who merely copy and paste code becomes pretty self-evident after collecting your first dozen or so resumes. For example consider javascript's "this" keyword. Not really concerned with a textbook definition from the ECMA spec. Or how its implemented in V8 runtimes. But you should be able to demonstrate how to bind a function call to any context you want, when to use global scope, why eval is not necessarily evil, etc. This knowledge base represents the shared technical language your team mates will use to communicate. That requires some fluency in it.
- gambler 9y ago
  >It's a decent representation of your journey on the path to mastery. Mastery of what? Most of them are trivia questions. They don't concern any fundamental knowledge or capability, just familiarity with some arbitrary aspect of browser's working or even a particular JS library. Asking trivia questions during interviews is a giant disservice to the hiring company. But people do it anyway, either to show off and assert their own "competence" or to filter out "profane" candidates. Personally, I mostly ask scenario-based questions. "If you need to do X, what would be your options?" "What steps would you take to figure out Y?" Works great and quickly filters out buzzword-spewing idiots who know things, but can't actually do anything. >This knowledge base represents the sha6red technical language your team mates will use to communicate. Social signalling. That's all it is. I remember how my company's interview guidelines use to state that we must ask all C#/.NET candidates about GAC. Meanwhile, 90% of all current developers never had any non-trivial interactions with GAC. Plus, the answer expected from the candidates was kind of bullshit. Plus, it was something you could find online in 5 seconds. sigh I never asked that myself, but I wonder how many qualified people were rejected just because they didn't know some arbitrary set of .NET quirks.
  - mercer 9y ago
ryanmarsh 9y ago
I totally agree with you. On the upside I found this to be a great list of interesting trivia I didn’t know or always wondered about and never had the time to research. Definitely a worthwhile read for any front end dev.

by jasim 9y ago

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.

crazygringo 9y ago

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 9y ago
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.

indescions_2018 9y ago

Seems a pretty solid list to me ;) It's a decent representation of your journey on the path to mastery. With a few years experience building several large (10K+ users) sites. One should at least have an opinion on 80-90% of this material. It demonstrates a proclivity to dive deep into web technologies. And a willingness to understand rather than simply mimic. The number of folks who claim proficiency, but who merely copy and paste code becomes pretty self-evident after collecting your first dozen or so resumes. For example consider javascript's "this" keyword. Not really concerned with a textbook definition from the ECMA spec. Or how its implemented in V8 runtimes. But you should be able to demonstrate how to bind a function call to any context you want, when to use global scope, why eval is not necessarily evil, etc. This knowledge base represents the shared technical language your team mates will use to communicate. That requires some fluency in it.

gambler 9y ago
>It's a decent representation of your journey on the path to mastery. Mastery of what? Most of them are trivia questions. They don't concern any fundamental knowledge or capability, just familiarity with some arbitrary aspect of browser's working or even a particular JS library. Asking trivia questions during interviews is a giant disservice to the hiring company. But people do it anyway, either to show off and assert their own "competence" or to filter out "profane" candidates. Personally, I mostly ask scenario-based questions. "If you need to do X, what would be your options?" "What steps would you take to figure out Y?" Works great and quickly filters out buzzword-spewing idiots who know things, but can't actually do anything. >This knowledge base represents the sha6red technical language your team mates will use to communicate. Social signalling. That's all it is. I remember how my company's interview guidelines use to state that we must ask all C#/.NET candidates about GAC. Meanwhile, 90% of all current developers never had any non-trivial interactions with GAC. Plus, the answer expected from the candidates was kind of bullshit. Plus, it was something you could find online in 5 seconds. sigh I never asked that myself, but I wonder how many qualified people were rejected just because they didn't know some arbitrary set of .NET quirks.
- mercer 9y ago

ryanmarsh 9y ago

I totally agree with you. On the upside I found this to be a great list of interesting trivia I didn’t know or always wondered about and never had the time to research. Definitely a worthwhile read for any front end dev.