Comment by jasim | Hacker News Reader

Comment by jasim | Hacker News Reader

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.

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.

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.

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.

>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.

> 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.

I can think of a lot of cases in front-end programming where knowing the volumes of trivia is very important/useful and can very well be considered a job in itself (and often is).

It's precisely the reason why I'm moving away from most of it for the time being, because I feel it's just too much trivia and too little 'fundamental knowledge or capability'. The latter ages well, the former doesn't.

However, I don't think they're just trivia questions. If you want to create a web app that supports a good range of devices, multiple browsers on these devices, and all the various quirks that exist until this moment, do you really want your 'master' developers to memorize this trivia? The same goes for CSS and its quirks, and quite a lot of js/dom stuff. It's getting better, but there's still a staggering amount of trivia to learn, and there's immense value in the kind of person who would willingly learn all this.

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.

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.

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.

Reply on news.ycombinator.com