5 ms·

this. I'll chime in as someone with a skill set that is completely not special (linux application development, and hardware / firmware / software integration),

this. I'll chime in as someone with a skill set that is completely not special (linux application development, and hardware / firmware / software integration), but in certain circles, is unique since it doesn't involve JavaScript (yet). I think the question is too vague, but I've asked a similar question: To kernel hackers (not application developers) - Tell me what you know about the Linux boot process To anyone with a 5th-gen language on their resume: how's a hash table implemented? (use of a feature or function without understanding why and how it works can lead to really interesting performance problems, even if the code is functionally correct)

akerl_ 11y ago
I'd argue that the cases where a hash table's performance characteristics come into play are few and far between for most developers, and when they do, it's way more relevant that the person have a general idea how to profile perf in their code and say "yup, this is the spot that I need to worry about optimizing first". By marking down people who don't know how to implement a hash table, you're cutting out a large chunk of your candidate pool, and I'm willing to stake my hiring choices on the fact that a decent chunk of them could easily by taught that knowledge if it became relevant for their career on your team.
- a8da6b0c91d 11y ago
  > "yup, this is the spot that I need to worry about optimizing first". This almost never actually happens. In practice slow software of any size and complexity is sprinkled with many small inefficiencies that add up and no single thing makes a huge difference. To be performant you have to write with performance in mind from the get-go and not make many small mistakes.
  - plonh 11y ago
    And "what implementation to use for a map" is a decision nobody makes at first, as it depends a lot on hownit ends up used. In reality there are a few worst spots in our code. Being 2x too slow isn't big a deal except in the rare cases where your whole business is turning compute resources into money withn no other expenses. Investing programmer energy in features and correctness is a better use than premature optimization, say, 97% of the time.
- davnicwil 11y ago
  I did an interview once where they asked me questions around the implementation of a hashmap. At the time I'd been working about a year out of university, and had not in that job come across any situation where I'd needed to know anything about how hashmaps worked under the hood (if anyone had a first job where you did, I'm happy for you, yours was a lot more interesting than mine). Any remnant of an explanation I'd got from my CS degree, most likely in first year, was way back in the mists of time. In the pressured situation, I simply admitted I didn't know. At this point the interviewer's face soured, and he basically wrapped up the interview straight away - it had been running about 5 minutes at that point, with only one question before that, so it was pretty obviously being cut short. Immediately after the interview I went to Wikipedia to look up hashmaps, instantly understood the basic mechanics, and 5 minutes later could have given a stellar answer to that question. If that interviewer was looking for someone with an encyclopaedic knowledge of data structures, with flawless recall under pressure, then his question served him well in filtering me out. I sincerely doubt that's what he was looking for, though. Since that experience I've been very careful, doing interviews myself, never to ask straight-up knowledge questions like this - or at least if I veer into a question like that, allow the candidate to explore the idea (even tell them the answer, and just talk about it to see if they get it) if they initially don't know. That will get you a lot closer to what you're actually trying to assess them for. It's very easy to fall into a trap of interviewing with a 'mirror' approach, where you assume that the candidate must know what you know, or else be bad. Kind of a paint by numbers, where the finished product looks a lot like you. But everyone learns on a different path. You need to remember that there was a time where each concept you use take for granted every day in your job was once new and alien to you, too. You picked it up just fine, and so can they. In fact, this is by far the most core skill you are looking for - that ability to actually pick up new things and use them.
  - opless 11y ago
    Well said.
  - Rapzid 11y ago
    Could even flip it around: prepare a simple implementation of a hash map, maybe even in sudo code, and then show it to the interviewee and ask them what's going on/discuss it.
bpicolo 11y ago
> use of a feature or function without understanding why and how it works can lead to really interesting performance problems, even if the code is functionally correct Which you shouldn't worry about until a profile shows it's an issue. Otherwise, having a basic understanding of data structure usage is the actual critical bit
- nirvdrum 11y ago
  Given the choice between two functionally correct data structures with different performance profiles, you should pick the one more appropriate to the task at hand. A lot of performance issues can be proactively avoided with a bit of analytical thinking, but you do need to know how your data structures work and what their trade-offs are. Profilers are wonderful tools, but in the 15 years I've been professionally writing software the number of people I know that have ever used one numbers in the low 10s. Of those, the number that can derive meaningful data from a profile is even smaller. And finally, those that can spot "death from a thousand cuts" situations (quite common) from the proverbial method that takes 20% of all CPU time is even smaller yet. Profiling has a place, of course. But it's tricky to get right, incredibly time consuming without sampling, and often doesn't give you a complete picture. It's the performance equivalent of a debugger and really should be a fallback, not the only tool in your arsenal.
- AnthonyMouse 11y ago
  That doesn't necessarily work at the level of fundamental data structures. If you make the same mistake in 1500 different places the profiler won't show any of them as particularly hot but your program will still be slow.
kybernetikos 11y ago
> to anyone with a 5th-gen language on their resume: how's a hash table implemented? use of a feature or function without understanding why and how it works can lead to really interesting performance problems, even if the code is functionally correct) Someone recently argued something similar with me, although they were even more emphatic about the importance of taking an interest in how the datastructures you're using are put together. Interestingly though, there are a few well known languages where if you assumed that the default Map was implemented as a Hashtable, you'd be making bad assumptions, as it's a Hash Array Mapped Trie, a data structure that certainly wasn't taught back when I was studying computer science. Unsurprisingly, despite the strong opinion that you should always find out how the things you use are implemented, my interlocutor didn't know this. And I didn't expect him to. I think that an obsession with particular shibboleths that "any decent programmer should know" misses the point that you're a decent programmer because of what you can do when you need to, not because of the datastructure implementations you've memorised.
- Retra 11y ago
  People vastly underestimate the amount of useful information that exists that you could learn. If someone asked me why I don't know some micro-fact, I'd want to respond by saying "because I've learned these other 10 things instead." If you spend all your time learning some particular domain of knowledge, you're not going to be prepared to ask questions about the domains you don't know. And most people will have a hard time seeing the value in those things they didn't learn. Especially when they're playing an authority figure.

akerl_ 11y ago

I'd argue that the cases where a hash table's performance characteristics come into play are few and far between for most developers, and when they do, it's way more relevant that the person have a general idea how to profile perf in their code and say "yup, this is the spot that I need to worry about optimizing first". By marking down people who don't know how to implement a hash table, you're cutting out a large chunk of your candidate pool, and I'm willing to stake my hiring choices on the fact that a decent chunk of them could easily by taught that knowledge if it became relevant for their career on your team.

a8da6b0c91d 11y ago
> "yup, this is the spot that I need to worry about optimizing first". This almost never actually happens. In practice slow software of any size and complexity is sprinkled with many small inefficiencies that add up and no single thing makes a huge difference. To be performant you have to write with performance in mind from the get-go and not make many small mistakes.
- plonh 11y ago
  And "what implementation to use for a map" is a decision nobody makes at first, as it depends a lot on hownit ends up used. In reality there are a few worst spots in our code. Being 2x too slow isn't big a deal except in the rare cases where your whole business is turning compute resources into money withn no other expenses. Investing programmer energy in features and correctness is a better use than premature optimization, say, 97% of the time.
davnicwil 11y ago
I did an interview once where they asked me questions around the implementation of a hashmap. At the time I'd been working about a year out of university, and had not in that job come across any situation where I'd needed to know anything about how hashmaps worked under the hood (if anyone had a first job where you did, I'm happy for you, yours was a lot more interesting than mine). Any remnant of an explanation I'd got from my CS degree, most likely in first year, was way back in the mists of time. In the pressured situation, I simply admitted I didn't know. At this point the interviewer's face soured, and he basically wrapped up the interview straight away - it had been running about 5 minutes at that point, with only one question before that, so it was pretty obviously being cut short. Immediately after the interview I went to Wikipedia to look up hashmaps, instantly understood the basic mechanics, and 5 minutes later could have given a stellar answer to that question. If that interviewer was looking for someone with an encyclopaedic knowledge of data structures, with flawless recall under pressure, then his question served him well in filtering me out. I sincerely doubt that's what he was looking for, though. Since that experience I've been very careful, doing interviews myself, never to ask straight-up knowledge questions like this - or at least if I veer into a question like that, allow the candidate to explore the idea (even tell them the answer, and just talk about it to see if they get it) if they initially don't know. That will get you a lot closer to what you're actually trying to assess them for. It's very easy to fall into a trap of interviewing with a 'mirror' approach, where you assume that the candidate must know what you know, or else be bad. Kind of a paint by numbers, where the finished product looks a lot like you. But everyone learns on a different path. You need to remember that there was a time where each concept you use take for granted every day in your job was once new and alien to you, too. You picked it up just fine, and so can they. In fact, this is by far the most core skill you are looking for - that ability to actually pick up new things and use them.
- opless 11y ago
  Well said.
- Rapzid 11y ago
  Could even flip it around: prepare a simple implementation of a hash map, maybe even in sudo code, and then show it to the interviewee and ask them what's going on/discuss it.

bpicolo 11y ago

> use of a feature or function without understanding why and how it works can lead to really interesting performance problems, even if the code is functionally correct Which you shouldn't worry about until a profile shows it's an issue. Otherwise, having a basic understanding of data structure usage is the actual critical bit

nirvdrum 11y ago
Given the choice between two functionally correct data structures with different performance profiles, you should pick the one more appropriate to the task at hand. A lot of performance issues can be proactively avoided with a bit of analytical thinking, but you do need to know how your data structures work and what their trade-offs are. Profilers are wonderful tools, but in the 15 years I've been professionally writing software the number of people I know that have ever used one numbers in the low 10s. Of those, the number that can derive meaningful data from a profile is even smaller. And finally, those that can spot "death from a thousand cuts" situations (quite common) from the proverbial method that takes 20% of all CPU time is even smaller yet. Profiling has a place, of course. But it's tricky to get right, incredibly time consuming without sampling, and often doesn't give you a complete picture. It's the performance equivalent of a debugger and really should be a fallback, not the only tool in your arsenal.
AnthonyMouse 11y ago
That doesn't necessarily work at the level of fundamental data structures. If you make the same mistake in 1500 different places the profiler won't show any of them as particularly hot but your program will still be slow.

kybernetikos 11y ago

> to anyone with a 5th-gen language on their resume: how's a hash table implemented? use of a feature or function without understanding why and how it works can lead to really interesting performance problems, even if the code is functionally correct) Someone recently argued something similar with me, although they were even more emphatic about the importance of taking an interest in how the datastructures you're using are put together. Interestingly though, there are a few well known languages where if you assumed that the default Map was implemented as a Hashtable, you'd be making bad assumptions, as it's a Hash Array Mapped Trie, a data structure that certainly wasn't taught back when I was studying computer science. Unsurprisingly, despite the strong opinion that you should always find out how the things you use are implemented, my interlocutor didn't know this. And I didn't expect him to. I think that an obsession with particular shibboleths that "any decent programmer should know" misses the point that you're a decent programmer because of what you can do when you need to, not because of the datastructure implementations you've memorised.

Retra 11y ago
People vastly underestimate the amount of useful information that exists that you could learn. If someone asked me why I don't know some micro-fact, I'd want to respond by saying "because I've learned these other 10 things instead." If you spend all your time learning some particular domain of knowledge, you're not going to be prepared to ask questions about the domains you don't know. And most people will have a hard time seeing the value in those things they didn't learn. Especially when they're playing an authority figure.