3 ms·

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

• 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.
  • Gibbon1 11y ago
    The comment about mirror approach to interviewing reminds me of the first place I worked. At one point we needed to hire someone to do something outside the usual skill set. The CTO interviewed a bunch of people and hired the one that knew slightly less than he did. What O got was the ones that knew what they were doing, disagreed with the CTO on some issues, and so were out of the running.