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.
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.
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.
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.
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.
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).
At close to 20 years of experience, I consider myself pretty senior and every job I've has had a 6 months probation period.
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.
> 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.
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.
I really want this to be true, however in our "not so ideal" world, many interviewers are just bad at interviewing or they are asking candidates more than what they really need, mean while not willing to pay higher price. In short, recruiters are trying to cheat the system too. So, fair world.
I tend to be really solid on the ins and outs of what I'm working on right now, or in the last year. And on stuff older than that I have a good idea of the landscape and the location of certain gotchas, but I find I have to Google certain things like syntax or accessible ways to do something as I go.
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.
When I've been involved in interviews from the interviewer side, I always try to focus on questions that don't have concrete, Googleable answers. Sure, it's good to include a question or two to filter out the actual impostors—such as asking a candidate claiming extensive Java experience how to check string equality (it's astonishing how many people this filters out)—but after that sanity check, I'm more interested in your approach to problem-solving and communication.
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.
Yeah, I can understand preparing for the job itself, e.g. brushing up on your financial knowledge when applying for an HFT job or something. But interviews and actual jobs seem to have diverged to the point that there is now somewhat of an industry around 'preparing for the tech interview'. It's almost like a new branch of science.
I prepare for interviews but rather than rehearsing technicalities I make sure I know all I can about the company, I think about what problems I might encounter in the role and what solutions might look like, and I think how my skills and experience might benefit the company.
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)?
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.
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.
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.
"...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.
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?
The problem is that there's a lot of "fake it until you make it" in the industry, and we don't have time to actually interview individually all of the applicants you get for a job opening.
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.
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)
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.
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?
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.
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.
The reason almost any developer should have heard of linked lists is that understanding them is fairly fundamental to understanding a bunch of other useful data structures.
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?
And what data structure do you use when you have to insert and remove efficiently many items from a container ? For example when you have a big queue ?
You use the language native array implementation until your queue gets so huge that it's actually a problem to add or remove items. Everything else is just premature optimisation. Modern web programming has the luxury of fast iteration cycles so any problem that appear at scale are easily and swiftly fixed.
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?
I had CS classes but in my work I do 80% front (because I enjoy it actually) and 20% back. Not using anything fancy in my work though. So how does one avoid being classified like you do ? (well you edited, your original post had Just call it "frontend dev"., but my question still stands, how can I counter the prejudices you seem to have ?)
Well if you know that then this sub thread is not about you. Move on. This thread was about people who insist that they are fine being ignorant about basic knowledge.
You seem to have painted yourself into the corner where you're not willing to accept the reasoning everyone else has provided in the comments. The point has always been that any developer can learn what a linked list is with hints and collaboration.
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.
The thing is that you can build applications full-time for years where you just aren't doing that ever.
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.
Sounds like you're arguing that Cheng Zhao is not a developer and the kind of "designer"/"app builder" that companies should try to avoid by asking "what is a linked list" and other theoretical questions during job interviews.
I think it's safe to assume that every developer who has got a bachelor degree knows what a linked list is (and is familiar with other data structures as well). However, many incredibly talented developers haven't bothered to memorize how these data structures work and their advantages/disadvantages, and whenever they encounter a situation where they need it, then they can simply Google the best solution within a couple of seconds/minutes.
That's why these 'technical interviews' are so ridiculous, because they test theoretical abilities rather than programming abilities.
Hold on, you can't call a linked list theoretical knowledge. It's a basic data structure used in tons of real world code, including this forum. And even then, theoretical knowledge does have an impact in the real world. People don't study and research theoretical subjects because they have nothing better to do, they do it because it has real world implications.
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).
You'd be surprised to see the excellent code written by people who don't know basic data structure theory. Arrays/Objects in JavaScript, Hashes and Arrays in Ruby, Dicts and Lists in Python go all the way to fill the needs of that. At what point would you need the implementation details of any of these to write code?
>At what point would you need the implementation details of any of these to write code?
...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.
Failing to memorize how a linked list works and its advantages/disadvantages does not mean the developer will write sub-optimal software, as an experienced developer can easily find out which data structure would be optimal for any given problem by spending a couple of seconds/minutes googling. A 'technical interview' should not include asking these questions that everyone studied during their bachelor.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
> 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?
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.
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.
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.
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 :)
the section about local storage is wrong, localStorage and sessionStorage are definitely domain scoped, it will be an egregious security hole otherwise
105 comments
[ 3.0 ms ] story [ 127 ms ] threadEdit:
Kappa
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.
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?
Have fun
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.
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.
[1] - https://www.gitbook.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.
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.
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.
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
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.
> 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.