[blueside]

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?

[MatmaRex]

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.

[nilkn]

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

[MatmaRex]

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.

[sotojuan]

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

[pauljaworski]

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.