Hacker News Reader

...explain to me how a hash map works. For get about explaining the finer points of sorting algorithms

I've been in software development for 15 years and being able to explain either of these things has never come up and I probably wouldn't be able to give a decent answer without reviewing the topics specifically.

Yes, companies are hiring for competency not tenure or years of life lived while holding job. If you want the latter, I have heard it is more structured that way in Japan and much of Europe.

I would expect most people I hire to be able to explain how a hash map works.

Depends on what exactly your company is doing? Why do you care if an applicant understand how a hash map works; and what's particular about a hash map?

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.

To me, "what a hashmap is" is just an extremely basic engineering concept. Your reference to "memorizing" (to refer to the topic you don't like) vs. "understanding" (to refer to the topic you do like) is value-laden and also suggests to me that you think a hashmap is more complicated than it actually is - it is truly just one step from understanding what a hash is.

well I mean there is quite a lot of differences between what the answer to 'what is a hashmap?' can be - is it acceptable to say a hashmap is a bunch of key value pairs where the key is an identifier by which you can look up the value you want - or should it be more in depth - akin to the wikipedia article https://en.wikipedia.org/wiki/Hash_table describing not just what it is but also its place in CS and how it is implemented? If the second it's probable the memorized description would be accurate.

I would expect the basic notion of hashing to decide where to place an element as well as a strategy for dealing with collisions (the basic approach being hashing to a linked list). This didn't require any "memorization" on my part.

Ok fine, so not an in-depth definition, but someone might think you mean an in-depth definition if you don't specify the level you expect is being used (perhaps because they have encountered that situation). I mean if you ask me define a hashmap and how it works for example I might think: "aw damn, this guy wants the low level details, I bet this place sucks to work at!"

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.

I'm not sure what you even mean by an "in-depth definition." What I said is basically constitutive of a hashmap, it's place in the history of CS or whatever is not.

a not in-depth definition would be a 1 sentence definition of a hash map with probably give me an example of when you might want to use it.

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 don't think understanding how a hash map, an incredibly simple data structure used frequently, is all that "low level." If I really wanted low level, I would talk about having linked lists of arrays rather than a linked list of nodes so that you could benefit from fewer random lookups.

I work as an ML engineer, so very high level.

Ok, perhaps for your job it is reasonable to know what I call the in-depth definition - implement hash map functionality in language interview is using without using built in hash map functionality of language, discuss trade-offs (or perhaps it is your particular interests that allows you to keep this information readily available) but I guess you can see how many people's jobs do not require this and it would be reasonable for job interviews in those fields to only want the shallow understanding - one line definition of hash map, when would you use it.

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.

> why do you care if an applicant understand how a hash map works; and what's particular about a hash map?

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.

>Variations on hash maps are used all the time

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.

Knowing how to build a bone saw is a completely different skill set than surgery. Building a hash table is a job for a software engineer even if not every engineer does it frequently. Still my analogy wasn’t great.

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 :)

>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.

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.

Yes, companies are hiring for competency not tenure or years of life lived while holding job.

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.

I concede it may just be that I've been lucky, but when interviewing experienced candidates I've never really had any problem judging their competency just from discussing their past work. A little bit of back-and-forth deep dive into the technology has always exposed people who are shallower than their CV would have you believe.

What has burned me, however, cannot be tested adequately in an interview. Bad attitude and laziness. Anyone can behave well in interviews, so we've hired a few people who turned out to have a passive aggressive streak or condescending attitude that interferes with the rest of the team. We've also hired people who are really great developers ... when they work. But they're really lazy and getting them interested enough to do the work is the hard part.

Hiring is hard. I doubt I need to tell you that. There is a reason we gravitate towards hiring people we've worked with in the past, or come recommended by someone we trust.

I've had the same experience. Everyone wants you to "just look at their resume". Meanwhile, I've interviewed plenty of people with great resumes who can't solve a simple problem like reversing a string [1].

If you can point me to extensive open-source experience on projects that roughly approximate professional coding, then fine, I'd be happy to walk through your code with you instead of doing an algorithmic problem. The issue is that that's a minority of developers... most people don't have the time or desire to do extensive open-source work outside of work hours and I don't blame them for it [2]! But given that resumes are unreliable, I need to test you somehow.

[1] No, I don't ever have to reverse strings at work. But I do have to write efficient code. And if you can't conceptualize how to reverse a string then you probably won't stand a chance at more difficult algorithmic issues I often come across.

[2] I don't recall who it was, but I once heard a very well-regarded chef say that he's tired after work and so he doesn't like to cook much at home. I have zero problem with a developer doing the same with coding! Go home and work on a hobby, spend time with your family, or smoke pot and watch netflix... I care about what you are capable of at work, not what you do with your free time.

>technical applicants cannot do basic things like write a very simple linked list class, or explain to me how a hash map works

In my experience people know these things, they just don't realize that what they're doing can be described generically.

An example: If you're in an iOS interview and ask the person to describe a graph, they will get very angry and complain that this is useless knowledge and they don't need it to get the job. But if you ask the same person to describe an UIView hierarchy, they often have no problem doing so. So they _know_ what a graph is, they just didn't know it had that name.

With that in mind, my tests shows that generic algorithm questions suck and questions themed around actual features of the product are the best. If you word the question in a way that feels relevant and is familiar to developers, they will be more likely to know the answer even if deep down the solution is exactly the same as the generic ones.