[seanwilson]

> What is your definition of "roughly" and how do you think lack of that knowledge affects knowledge of optimization and scalability?

Just that you hash a value you want to store and transform that hash into an array index for fast lookup. If someone didn't know that I find it hard to believe they'd have much knowledge or interest about how to pick appropriate data structures for large collections as it's such a fundamental concept used in lots of places (e.g. indices, caching). I'm not even expecting knowledge of what happens when two keys hash to the same bucket.

> Also because I used to write large-scale real-time signal processing code that didn't use hash tables at all, so lack of knowledge there wouldn't have this effect on our code.

Is there a similar data structure question you would ask a candidate who wants to work in this domain? You don't use hashes at all?

[vonmoltke]

> Just that you hash a value you want to store and transform that hash into an array index for fast lookup. If someone didn't know that I find it hard to believe they'd have much knowledge or interest about how to pick appropriate data structures for large collections as it's such a fundamental concept used in lots of places (e.g. indices, caching). I'm not even expecting knowledge of what happens when two keys hash to the same bucket.

Makes sense to me. I just wouldn't call that knowing how a hash table "works", which is why I asked for clarification.

> Is there a similar data structure question you would ask a candidate who wants to work in this domain?

I would focus on fixed-size data structures, since those were critical to our code. I would find out if they could go lower than Big-O (which was, quite frankly, useless to us) when thinking about runtime complexity and whether they could relate what the various operations were doing to what the processor was doing.

> You don't use hashes at all?

That code had no hashes whatsoever. We had no need to look things up in that manner.