|
|
|
|
|
by vonmoltke
3555 days ago
|
|
> 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. |
|