Like the CTO of a famous startup who didn't understand that the order of a multicolumn index has some importance. I died a few minutes later when he told me I should add an index on a boolean (whereas the queries didn't use it) because it would speed up the queries by 2. Best day of my life.
Sorry to hear about the rent situation - I take that worked out OK eventually?
I think the basic corporate rules of signalling competence apply here. Assuming that person was both technologically and socially incompetent (which might be too harsh of a judgement), some people still have a way of getting promoted into valuable positions by appearing to do a great job.
> Sorry to hear about the rent situation - I take that worked out OK eventually?
Thankfully that was some years back, I'm doing okay today :)
Not sure it is - the usual advice is "if in doubt then don't hire" so why not apply that to employers as well as employees?
Of course, if there is an element of desperation involved then I can understand it. But I have walked away from interview processes (or turned down offers) when I had some worries and never really regretted it.
Harshness both ways would seem to be fair.
It is not 1 but that's the agreement.
In your specific case maybe you both weren't aware of the nomenclature? In any case, they did you a favor. If you are arguing about hash tables from the start, who knows how it will be when you ask for vacation or sick days.
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".
If you keep your hash table 1% full then you're unlikely to run into a collision no matter how bad your hash function is. If you keep your table 99% full then it doesn't matter how good your hash function is. You still have to modulo your hash by the number of buckets.
But now we're far outside the realm of "properties of hash tables" and instead inside "properties of my hash table", and any decent interviewer should recognize that.
Look at (Hopscotch,) Robin Hood or Cuckoo Hashing for hashing with linear probing, high fill factor (~0.9) and _amortized_ O(1). I've seen a paper somewhere that proved Robin Hood worst-case O(log log n) afair.
http://www.sebastiansylvan.com/post/robin-hood-hashing-shoul...
https://en.m.wikipedia.org/wiki/Hopscotch_hashing
You can make open probing performantly concurrent with 2 bytes of memory overhead per key/value too:
You can make an expanding array with O(1) operations, but I'm unsure if it's applicable to a hashtable. It may be, but it's beginning to become very complex.
When I was looking for a job, I flunked out of one interview where I got into an argument with an interviewer about the runtime properties of hash tables - more specifically: the interviewer was adamant their access time was always O(1), wanted me to admit my "mistake" and move on, but I just couldn't ;) It was one of those rare cases where they give you feedback on why you're not being hired, too. The lady on the phone said my "technical knowledge" was not up to par with what they needed for the position. Yeah, I'm still salty about that.