Well, "always O(1)" is simply wrong in my opinion. This may be a cultural thing, but I'm used to referring to the worst case behavior in big O as a default, so I would have said something along the lines of "the worst case is O(n) and that can turn out to be problematic in some cases". And normally interviewers do want you to talk about these kind of corner cases. I don't think I'm using the nomenclature wrong, and I certainly didn't ever refer to something as O(5) which as far as I can tell is not and should never a thing...

To my best recollection, the question came up as a dynamic language issue. Specifically what the interviewer wanted to hear is that accessing (both read and write) an object property in JavaScript is always O(1), since it's a hash map access under the hood. Leaving aside for a moment that this is fuzzily untrue in a typically JITed environment, it's also untrue in general. You could try to make a case for that when doing a read on a specially optimized hash table, but it would certainly not be true in the general case where you also add things to the table. But all of these considerations are already way too detailed and far beyond what the interviewer wanted to talk about.

They just wanted to check off "knows it's a hash table under the hood" and "knows that hash tables are always O(1)", even though both of these are untrue in my opinion.

https://m.reddit.com/r/compsci/comments/2z74z8/why_is_hashta...

JavaScript does (unless I'm wrong) a layer of variable lookup, so the time is far off from O(1).

So, you are right on technical terms, and on interview terms, it depends. When I was just out of university I'd have probably went for the job. As I'm getting more senior, I'd still be polite and explain them where they are wrong, but stand my ground with the recruiter afterwards and tell him the interviewer was out of his depth, and checking off questions he probably googled somewhere. I'd then ask him to give me more serious companies to be considered by. Stuff like your story have more to do with team skills then technical skills. Who cares if you answer right or wrong on the question, when you are the guy you are supposed to work with get pissed off with each other after few minutes technical discussion.

General advice: go for where you are celebrated and not for where you are tolerated. A bit of synergy can go a long way.

In all the usual cases, the hashed key size is way less than the unhashed key size, and you need to pay the price for collisions somewhere.

I'm sorry, but you don't really understand hash tables.

> I'm sorry, but you don't really understand hash tables.

I'm not the one who made this personal, but I'll match that allegation back to you, and I raise you one "you don't really know how to interpret what people say".