> Even for a front-end developer you should have a basic knowledge of data structures like linked lists, binary trees, min/max heaps, depth/breadth first search, tries, recursion, hash tables, etc.

I would never care about these if I was specifically hiring a front-end dev. I've never once seen any of them come up in the context of front-end work in my entire career. And in fact an interviewer asking questions about them would be a huge red flag for someone who prioritizes nerd-cred over actual business needs, and is therefore likely to make poor decisions.

An interview shouldn't be purely theoretical, but I disagree that there's no place for this stuff.

As an incredibly simple example that comes up all the time, if you get back a collection of items from an API do you store them in a hash keyed by id or in a list? If you can't reason about how e.g. lists are ordered but a hash has O(1) access, and use that to decide which is better in a particular case, you won't be a very strong front-end dev.

Not to mention if you need to dig into performance issues, e.g. dropping frames in animations or something.

I've also seen a lot of frontend bugs related to not thinking about/dealing with asynchronicity well. That's not a data structure problem per se, but you need a working knowledge of some basic CS concepts like threads, concurrency patterns, queues, etc.

I think the key in interviews is that this stuff shouldn't be evaluated like a school exam, where you need immediate recall of all the terms without stumbling. It's all about being able to work towards the right answer and it's fine if that involves a bit of asking or googling to double-check your ideas.

Expecting somebody to know the difference between a hash and an array is reasonable but you can hardly complain about a lack of qualified people if you disqualify JS applicants for not knowing what a trie is.

I don't understand how that's possible. For example, in a recent project I needed to implement a path-finding algorithm to draw connections routed around arbitrarily-placed boxes. More recently, efficiently snap a line to the nearest edge from an in-memory set of (again, arbitrarily placed and changing) objects as the mouse moves. I'm having to use and think about some item from that list on a daily basis. Where's the disconnect here - are we talking about different kinds of front-end work?

> Where's the disconnect here - are we talking about different kinds of front-end work?

Yeah I would assume so. Of course if know the job requires such knowledge, you should interview for it. But I'm thinking of more average front-end work, where you'd be building forms or dashboards or ordinary websites.

It sounds like you're building a complex application that just happens to be hosted in a browser. Although even then, I'd argue that while your knowledge of when to apply those algorithms is important, you still shouldn't be writing them yourself. You should be finding a well-vetted library and taking the function from there.

We may be on the same page here. I don't like the way dev interviews are run and I think the focus on textbook algorithms is misplaced. I would say if your interview process can be aced by somebody hitting the books for a month, you're not testing for hard enough things.

I was just a little surprised about those particular items because I feel like they're such an essential background for all software development. But I don't think they should be quizzed for in an interview.

So, so many people do things the hard and reliable way, or don't do them at all and sacrifice some desired feature, because they don't recognize a well understood computer science problem lurking underneath a business problem or a UI implementation.

I'm not saying that's what anyone in this discussion is doing, just that I see it everywhere (and have done it myself). 1000s of lines of incomprehensible code because no one realized that this drag and drop flow chart creation interface can be understood as a graph.

> I would say if your interview process can be aced by somebody hitting the books for a month, you're not testing for hard enough things.

I'd say if someone can independently learn the things you think are important enough to interview around in a month then they're the sort of person you should be hiring, unless you don't expect new problems to ever emerge you'll need people who can develop their knowledge anyway.

Who vets those libraries? And who writes them in the first place?

Not sure I understand the question... are you suggesting the concept of using vetted libraries is somehow faulty? Anyway, the answer is generally "a large community" or "some big company like google or facebook."

I think GP was referring to a situation where no such library exists or the needed modification would be prohibitive. Not that uncommon scenario once you are inventing new kinds of visualizations. Libs like d3js help, but they are pretty low level.

Those "large communities" and big companies are made up of people, who are front end developers are they not?

I don't really get the point. If you're writing an app to do X, and you require functionality Y for your interface, if a library doesn't exist, or is just some random persons GitHub dump minidress and no other committees, what do you do?

I think OP's list of essential algorithms is a bit too long. I agree that knowing what a binary search is, or graph traversal, is something that everyone writing code should know, and something that does come up reasonably often. (And recursion, heh.)

But binary trees? Last time I needed them was in a CS class. Linked lists? They only came up when I had to convince a coworker that we really don't need to implement one in JS, we only have 50 items here, and someone is going to forget to update a linked list if we use one.

This is why SV needs to stop abusing the term "engineer" - because this is indeed work that can be done on the front end, but under no circumstances should you expect front end developers to know how to do this. If you have a specific need, or you're building something very complex, then you probably want an engineer -- most companies (including any of the big ones) typically only need developers. It's good to have engineers tinkering with stuff though, that's how you wind up with things like React.

Right or you could have a "developer" tinker with stuff and that's how wind up with things like redux

Oh yeah absolutely - not trying to take anything away from developers particularly. Different skill sets, but practically the same outcome most of the time. That's a great example of why knowing how to create a BST from scratch isn't the only knowledge needed to build great software.

Most frontend jobs are gluing React, Ember, or Angular to the backend and sometimes making the CSS look right.

There ends up being a wide range of skills that fall into any classification and "front-end developer" is no different from what I see. For the majority of jobs, knowing html/css/js and modern js/css frameworks probably covers it. Your case sounds a little bit more specialized.

Then sometimes you see a "front-end developer" role and you find out it's actually a designer role.

I don't have a ton of actual front-end dev experience but when I get to do it in my consulting role I like it. So I'm trying to move into a role like that but the comments here make me think I don't have those skills. I don't have a strong CS background but was hoping I could still do front-end dev work. Then people are talking about algorithms and being a math minor and I'm not sure I could do that.

I think it is always good to know what kind of skills a candidate has besides what will be his average work, but could add to the skill set of the team and might come in handy.

Be that knowledge of data structures, algorithms, ui design, ux, project management or advertisment. Especially in startups where you can't afford dedicated teams for every aspect.

If the team is already strong on the design/ux front, I might favor a candidate with better cs fundamentals. And if my team mostly consists of the latter, I might favor a "worse" programmer but one who knows and cares about typography, color harmony, paper prototyping etc.

I'm confused. You've never even seen a hash table come up before? What sort of front-end work are you doing?

I just find this extremely unlikely if not borderline impossible. Hash tables are one of the most universal data structures in practical software development. This is just as true in JavaScript for front-end work as it is anywhere else.

I use js objects, of course, which are hash tables.

Would I hire a front-end developer who didn't know that, or didn't know that they had O(1) lookup time? Very possibly. Because there are so many things that are more important than that knowledge when you are actually building software for a business. Things like experience with usability testing, JS/CSS build tools, unit testing and refactoring, a decent eye for graphic design (even if they won't be doing that work themselves), an open-mind and lack of ego -- just off the top of my head, these are all things I'd consider orders of magnitude more important than knowing technical details about hash tables.

Expecting somebody to know what a hash table is and understand the time complexity of inserting and looking up elements is fair. Expecting them to build one from scratch on a whiteboard is just ritualized hazing.

I don't see anyone mentioning requiring one to build all these data structures from scratch. I'd agree with you that this is a less useful exercise for interviews, in particular front-end interviews, but I don't think it's fair to assume that this is what the poster above meant. Only "basic knowledge" was mentioned.

> I would never care about these if I was specifically hiring a front-end dev.

I would find these things very relevant if you were working on apps that deal with large datasets as picking the wrong data structure can lead to slow execution. It's also good to know what the limits of the candidate's knowledge is.

Agreed. Front-end developers should have experience using libraries that encapsulate collections, trees, sets, hashes, etc... and know when to use certain data structures.

But unless they're being hiring to develop a library, they don't need to have these algorithms memorized.

So, the first-half, no... never use. But depth/breadth first search, tries, recursion, hash tables... Absolutely use these as much in front-end as in back-end.

I've said it before and I'll say it again: "Ask every developer I've worked with at every job I've had in the industry questions related to these topics on the spot and 95% will fail."

Can somebody provide a real example of where you'd need to use "linked lists, binary trees, min/max heaps, depth/breadth first search, tries, recursion, hash tables, etc" in your typical everyday front end angular/react/ember project?

Depth-first and breadth-first graph traversal does come up. Example: you're implementing a task tracking system, where tasks can have dependencies. Boom, that's a graph. You want to display a whole graph of dependencies of a task (and dependencies of dependencies, etc.). Boom, there's graph traversal. You need to limit the number of tasks displayed in that graph, because someone added a thousand dependencies somewhere and now the graph rendering is choking up. Boom, traverse breadth-first and stop displaying more tasks after some preset number. This is an actual issue I ran into in actual code.

Now, about most of the other things that were mentioned… I'm not convinced.

> Now, about most of the other things that were mentioned… I'm not convinced.

Your graph example could just as well also be a tree example depending on the structure of the dependencies. Hash tables show up everywhere. Recursion is a natural and general programming technique. That only leaves linked lists, tries, and heaps from the original list. I'd agree that these are less likely to pop up in general front-end development, but it's not impossible to imagine them being useful.

I'd rank the concepts from the list in this order (obviously very subjective):

- Hash tables. Universal concept in programming. If you don't know this, you don't know how to program.

- Recursion. General technique for structuring code. Not understanding this indicates a severe lack of exposure to code in general.

- Graphs. Lots of data is naturally structured as a graph. I think it's natural to include trees in this category as well.

- Linked lists. Classic data structure. They're mainly worth knowing about in order to be aware of their performance shortcomings with lots of data. It's less about knowing when to use one and more about knowing when not to use one.

- Heaps. When useful, they tend to be incredibly useful. But they're not all that useful for front-end development.

- Tries. Similar to heaps in this regard.

Personally, I think for a purely front-end role that won't be focusing on the development of new libraries but just the usage of existing ones, I'd focus only on hash tables from this list and use the rest of the interview for more targeted questions.

Right, recursion is elementary, I missed that one. (It's even pretty much a prerequisite for depth-first graph traversal.) As far hash tables, I agree it's important to vaguely know how they work and to know the performance characteristics, but I wouldn't consider it critical to know how to implement one from scratch.

I don't know if zzzmarcus means they're useful, but it sadly shouldn't be surprising that OP might be asked that anyway.

I've used hash tables a fair amount in an order processing front-end app. In our batch order processing component, it was useful to hash the orders returned from the API on their "order_id" for fast and easy access to them in various stages of processing. You don't want to be using Array.find() every time you need to refer to an order.

> Even for a front-end developer you should have a basic knowledge of data structures like linked lists, binary trees, min/max heaps, depth/breadth first search, tries, recursion, hash tables, etc. These often come up in whiteboarding questions.

Most of these have not come up for me ever when interviewing with a strong frontend bent, even at companies like Google. Recursion has come up for me some (mostly for senior or higher positions), and knowing space/time complexity, but otherwise nothing super specific for frontend.

In the past year or so, I've been asked to live code various UI components at a fairly dependable clip, whether it be a typeahead/autocomplete, components with iteration (i.e. containing lists), and aligning various elements horizontally and vertically. Oftentimes these questions lead to various other questions while carrying out the implementations, probing for knowledge on various approaches and various tradeoffs/benefits of each approach.

>Stay postive about past employers.

That's a nice thought, but what if your past employer was Oracle? Doesn't honesty count for anything?