I would expect most people I hire to be able to explain how a hash map works.
I'd care more about an applicant understanding the concept of a hash; or hashing in general. If an applicant shows that he understands that a hash is a magical and fascinating mathematical concept; and it can have uses in Information/Computers, that would be more interesting (to me) than someone who memorized a hash map definition.
He can always learn about a particular application of hashing (hash map, for example). But the latter shows aptitude and capacity to learn these later on the job.
Because a hash map is:
1) a pretty basic concept in data structures
2) Variations on hash maps are used all the time in the real world. If you use objects in javascript, dictionaries in python, or maps in C++, then you are using things that essentially implement hash maps.
Point number 1 is like if I went to an orthopedic surgeon and they couldn't tell me what the liver does. You can say "well the liver has nothing to do with my finger that got smashed in a car crash, so what do I care." Or you can say, "that seems like a red flag. Maybe I'd be safer choosing a different doctor."
* Note: I have no idea how often the liver comes up in orthopedic finger surgery and for all I know it's a lot. But I think you get the point.
Yes, you use them. You don't build them. To torture your analogy it's like asking the surgeon to explain how their bone saw works. Why should they know? All they care is that it cuts bone.
Analogies aside, hashmaps (in one implementation or another), arrays, vectors/lists, strings and arguably sets are very very common data structures in most modern languages. I don’t expect someone to be able to build a hashmap from scratch but I do expect an experienced engineer to have some basic idea of the pieces that go into building it as well as it’s properties (not necessarily ordered, O(1)ish sets/gets, collisions, etc). Knowing this kind of thing helps you understand when to use an object in JavaScript vs a map. Or how dictionaries differ between python 2 and 3. If you understand the underlying data structure, then you know what questions to ask.
* in python 2, a dictionary’s keys are not guaranteed to have consistent order. In more recent versions of python 3, they ARE guaranteed to have consistent ordering. This has ramifications for the code you write, and it’s especially confusing if you don’t understand hashmaps because 99% of the time, the order will be maintained in python 2 even though it isn’t guaranteed. But relying on things that are true most of the time is a very bad way to write production code :)
Yeah, I'd say this is all in knowing how to use a hash. How to build one would go into the underlying data structure.
Although I would probably ask them to specify the level of detail they want before trying to comply, and then not get the job because I ask a lot of unnecessary questions or something.
an in-depth definition would be that, followed by how you implement a hash map (thus if your language of choice already has a hash map, don't use that but show us how you would implement this classic data structure), how do you avoid collisions, maybe discuss some various ways that you could implement it and what the tradeoffs are. This would be you 'understand!!' what a hashmap is, like deeply. (I hope my tone makes clear I do not advocate for this)
on edit: I think it seems you might actually be advocating for this deep definition? If so, probably you are working at relatively low level?
on edit 2: for example if you were using Python you might say a hash map is a dict, and talk about how to use dict, the in-depth definition would not allow this. Which I think is what the other posters were worried about, being asked not to use your language's implementation of the concept but go lower and show you can make the whole thing.
I work as an ML engineer, so very high level.
If you ask for the in-depth understanding for positions that would never need it, it follows that you will be disadvantaging many applicants who might be great for the position and advantaging applicants who know at least one non-relevant thing.
Oh I wasn't trying to say that this knowledge was valuable or not. I was just pointing out that you seem surprised that experienced people wouldn't be able to provide a good answer to that question. And the answer is that in many jobs, its not useful knowledge.