> In your specific case maybe you both weren't aware of the nomenclature?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.