Answers to front-end developer job interview questions
github.com
github.com
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.
After jumping this bar, one can make more freeform discussions or do pair programming.
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.
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.
Mate, the personal website url you list in your HN profile don't work.
Funny that this is about frontend.
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.
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.
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.
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.
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.
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.
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
- 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.
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).
During that time both the employee and/or the company can terminate the contract giving a small notice - one week in every country I've worked, but it might be different in other places. In most companies you don't even have access to some (or all) benefits - pension, healthcare, shares... - until you pass that period.
I don't know about your experience, but from where I come from it's almost a fact of life and one of the things you have to weight when looking to move to a new position.
Studying which opinions are fashionable this time is part of preparation for interview process :).
But more importantly, that kind of interview is strongly biased toward people who are charizmatic, great talker and biased against doers. Especially biased against those more on nerds side.
In real life, that googling or checking the docs fits right into the flow of solving the problem. But for an interview it's better to be fresh on as much as you can, even if you haven't been "in it" recently. And it can help a lot with nerves. One or two follow-up questions should help the interviewer figure out whether the person has experience with something or just knows what it is, and as long as the candidate's not pretending to have used things they haven't used, it's hard for me to call preparation cheating.
One fun thing to do as an interviewer is to play the role of a business analyst, asking for how they would implement a particular feature; then, make the requirements purposefully vague (while encouraging the interviewee to ask follow-up questions if they'd like). This is a lot closer to most real-world programming challenges than a detailed discussion of reactive programming.
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.
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.
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.
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?
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/U...
In fact you'll probably encounter it in code your coworker wrote 15 minutes ago.
:[
I use a set of questions during phone screenings similar to this one (but way shorter, of course). During them, I'm not expecting regurgitation or even a full description, but a general understanding of the underlying mechanisms of a language. I don't care about the difference between `call` or `apply`, but I do care about this person being able to know what they are, and when can they be used.
Then, during a face to face interview, you should forget about all these things, and get your hands dirty with the applicant.
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
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.
Just write good code is the motto!
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.
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.
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.
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.
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.
[1] - https://www.gitbook.com
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.
> 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?
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.
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.
Where does a JS frontend developer really need to have heard of linked lists?
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.
Some of it may be a terminology problem as well - frontend devs may not have met "linked lists" but what's the difference between a doubly linked list and a straight series of nested objects where no object has more than one child?
What do you mean by "know how Javascript works"?
I'm really curious if you could point to a real world example where a custom data structure is needed, where it's not written for performance critical reasons?
edit: front end devs.. LOL, you hold dear that delusion :-)
The prejudice that I see in this thread is that: Only people who already know what a linked list is can call themselves a developer. A developer will learn if she needs to what a linked list is. If tasked with something requiring one a developer will simply learn the theory behind linked lists and be able to execute it. In reality however, they probably won't because most day-to-day tasks don't.
I don't remember the last time I had a queue so large and in such a hot loop that it would matter, for example. And it was a channel.
Lately it's been browser-side code in an interactive online game that has gotten me to think about data access patterns again so that it performs well on slow phones, but that's just not what most people are working on.
We have this whole belabored HN meme where people complain how the internet is for documents, not applications. Do people in these comments really think generating those documents involves heavy data access patterns?
And then "being an experienced app builder" you decide to create Electron.. and now I have to use Electron applications which are productive and necessary (VS Code) but are frustrating like hell on anything but recent hardware because some moron somewhere doesn't know when to use linked lists instead of arrays.
That's why these 'technical interviews' are so ridiculous, because they test theoretical abilities rather than programming abilities.
If you ignore the theory, you end up with sub-optimal software that only kinda works (who cares about studying the theory and actually verifying those pesky edge cases) and is slower than it should be (who cares about advanced data structures, just use arrays and hash tables everywhere).
...literally any time you are performing a computation on a collection of items and care even the least bit about performance?
It sounds like your bar for what makes "excellent code" simply excludes performance issues completely. That's fine if you're talking about scrappy startup devs who move from MVP to MVP. But when it comes time to turn an MVP into an honest-to-goodness P, you can't totally ignore the efficiency of your code. And you can't write efficient code without understanding the basic strengths and weaknesses of the data structures your programming language implements.