[dcosson]

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.

[cageface]

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.