Hahaha, I feel like this was taken directly from one of my HN comments.
If you're stepping up from writing web apps, you should have done some homework first.
JustSomeNobody figured that if the interviewer is quizzing you on data structures and algorithms, surely the job you're applying for must rely on such knowledge. If only.
If the job is hiring for just another web/CRUD dev, then sure, asking CS questions might be out of place.
The idea of "do your homework" for interviews trivializes professionals down to meaningless data points where real experience and past accomplishments are all rendered as null.
At this point it's only being used for its Computer Science signalling value. JavaScript doesn't even have true HashMaps, and it's unlikely you'll find yourself implementing them while building a web app.
It's just one example of poor interviewing practice but it's not the only problem.
We could write a thesis on this, right? and we would disagree wildly, but in the end go put up your amazing UX n youtube and show me how memorizing the Algorithm Design Manual helped you create that amazing UX. UI work is mostly art and craft, with math/cs still relevant but applied from an intuitive dynamic center of your brain, not stored and ready to put on a white board on demand.
IME there are platforms (Ruby, JS, others) that have such high method dispatch overhead that the fastest "algorithm" is generally the one with the smallest stack-trace for 99% of problems.
It can be a very very very difficult bar to overcome.
I've only ever seen algorithm choice play a meaningful role in traditionally fast/compiled languages. YMMV.
Anyways, that's my experience with Ruby. Since each allocation (at the time) took 23 bytes of memory, even object graphs c# or Java might consider fairly modest (say loading 10,000 rows with a dozen fields into an Array<User>) would burn through a silly amount of memory comparably and probably trigger a GC cycle.
We're talking nanoseconds on the compiled side vs hundreds of milliseconds.
It takes a very very high N to overcome that sort of issue. One you might run into in scientific computing a lot more frequently, but not the sort of issue you'd often (if ever really) run into writing a web-app.
But, I can see how if they job doesn't require data structures and algorithms (say, just a simple CRUD app), sure, this type of interviewing is not beneficial.
Were they expecting you to account for collisions?
If you ever have an array of a few thousand or hundred thousand items, knowing how to make a hashmap can be pretty useful for performance even in js
For example later on they were trying to test me on JavaScript type irregularities. I did not realise that `typeof null === 'object'` or think this was important in practice (although I expressed no surprise as when I'm trying to test any JavaScript type I generally use a high-level interface to avoid JavaScript 'wat' moments). They seemed to think I'd be doing if-elses at the top of each function in order to perform the type checks that Java would have given me for free. I mentioned that 'flow' would be a better idea if you weren't happy with duck typing, but this probably sounded like I was trying to dodge the question to a Java developer. In practice when you're writing JavaScript code, it's popular to be lax about this kind of thing and write code like `config || {}.property`.
In conclusion:
I think that Computer Science is useful but less useful here. I'm actually now mid-way into some Coursera algorithms courses for my own personal learning as I think they'll be very valuable in other tasks.
I think the problem was that you could tell that they were primarily Java programmers by the topics that they gave importance. I'd say there's a strong chance that they'll hire somebody with a similar skill set to themselves and will not end up writing natural, best practices JavaScript.
People hiring in languages and domains they do not know well can bias themselves with the wrong kinds of questions and opinions. This seems to be a common interview failure case.