3 ms·

Just the other day during a JavaScript/React interview I was asked how a HashMap was implemented. At this point it's only being used for its Computer Science s

by lhnz 11y ago

Just the other day during a JavaScript/React interview I was asked how a HashMap was implemented. At this point it's only being used for its Computer Science signalling value. JavaScript doesn't even have true HashMaps, and it's unlikely you'll find yourself implementing them while building a web app. It's just one example of poor interviewing practice but it's not the only problem.

pech0rin 11y ago
While implementation details may be unnecessary, I feel like knowing how something performs for lookups, insertions, deletions, etc. is important. It definitely shouldn't be the end all be all of hiring, but it is definitely helpful day-to-day to know how the code works performance wise with the data structures you are using.
- ilostmykeys 11y ago
  that CS stuff you can look up and understand when you need it, like when you're looking for an efficient algorithm to do xyz, and so you should have curiosity and a wise intuition but beyond that as a web developer that knowledge should not sit in your brain because it will occupy precious thinking resources that you should dedicate to building great UX and making the code modular and maintainable which takes dedicating brain cells to understanding the world around you, not just a commodity piece of textbook knowledge that makes you feel smarter and covers up insecurities about having produced dull or even terrible UX -- "hey I know how to balance a red/black tree or build a hashmap implementation so I must be a under appreciated genius" when in fact that is commodity knowledge anyone can pick up from Google and a few hours of research and benchmarking (and having ability to allocate regions of your brain to tasks of wildly different nature on the fly which means you never keep crap in your head unless you're using it on daily basis) We could write a thesis on this, right? and we would disagree wildly, but in the end go put up your amazing UX n youtube and show me how memorizing the Algorithm Design Manual helped you create that amazing UX. UI work is mostly art and craft, with math/cs still relevant but applied from an intuitive dynamic center of your brain, not stored and ready to put on a white board on demand.
  - ryandrake 11y ago
    Bingo. If you're looking for someone who's a walking Wikipedia, then those "how does this algorithm work" or "what's the Big-O notation of that algorithm" questions will find that person. If you want someone who gets stuff done and is resourceful when they need to look something up, then that line of questioning is going to filter those people out.
- ssmoot 11y ago
  I get what you're saying. But I think there's a limit. IME there are platforms (Ruby, JS, others) that have such high method dispatch overhead that the fastest "algorithm" is generally the one with the smallest stack-trace for 99% of problems. It can be a very very very difficult bar to overcome. I've only ever seen algorithm choice play a meaningful role in traditionally fast/compiled languages. YMMV.
  - tomp 11y ago
    Absolutely not. Even if you write an interpreter in Python, a hashtable lookup (O(1)) leading to an O(n) algorithm will be faster in this interpreted language than a O(n^2) algorithm using the O(n) list lookup in C; for a sufficiently high n, of course, but it's not uncommon to have n of several million these days.
    - ssmoot 11y ago
      It's absolutely very uncommon to have a single collection of several million in the languages I mentioned in the web-app space IME. Anyways, that's my experience with Ruby. Since each allocation (at the time) took 23 bytes of memory, even object graphs c# or Java might consider fairly modest (say loading 10,000 rows with a dozen fields into an Array<User>) would burn through a silly amount of memory comparably and probably trigger a GC cycle. We're talking nanoseconds on the compiled side vs hundreds of milliseconds. It takes a very very high N to overcome that sort of issue. One you might run into in scientific computing a lot more frequently, but not the sort of issue you'd often (if ever really) run into writing a web-app.
      - tomp 11y ago
        Ok, you're probably right about Ruby and JS. I was thinking about Python, which I would consider in the same class of "slow" (wav) languages, but it's also quite common to do data processing and machine learning in it.
JustSomeNobody 11y ago
This doesn't really address my first question. But, I can see how if they job doesn't require data structures and algorithms (say, just a simple CRUD app), sure, this type of interviewing is not beneficial.
cheapsteak 11y ago
Did they mean HashMap or were they using a fancier word for key/val store? Were they expecting you to account for collisions? If you ever have an array of a few thousand or hundred thousand items, knowing how to make a hashmap can be pretty useful for performance even in js
- lhnz 11y ago
  They were Java developers so I think they were coming at the interview from the perspective of Java developers. I wish I'd known this beforehand as I could have markedly improved my answers by bearing this in mind and explaining myself better. For example later on they were trying to test me on JavaScript type irregularities. I did not realise that `typeof null === 'object'` or think this was important in practice (although I expressed no surprise as when I'm trying to test any JavaScript type I generally use a high-level interface to avoid JavaScript 'wat' moments). They seemed to think I'd be doing if-elses at the top of each function in order to perform the type checks that Java would have given me for free. I mentioned that 'flow' would be a better idea if you weren't happy with duck typing, but this probably sounded like I was trying to dodge the question to a Java developer. In practice when you're writing JavaScript code, it's popular to be lax about this kind of thing and write code like `config || {}.property`. In conclusion: I think that Computer Science is useful but less useful here. I'm actually now mid-way into some Coursera algorithms courses for my own personal learning as I think they'll be very valuable in other tasks. I think the problem was that you could tell that they were primarily Java programmers by the topics that they gave importance. I'd say there's a strong chance that they'll hire somebody with a similar skill set to themselves and will not end up writing natural, best practices JavaScript. People hiring in languages and domains they do not know well can bias themselves with the wrong kinds of questions and opinions. This seems to be a common interview failure case.

by lhnz 11y ago

pech0rin 11y ago

While implementation details may be unnecessary, I feel like knowing how something performs for lookups, insertions, deletions, etc. is important. It definitely shouldn't be the end all be all of hiring, but it is definitely helpful day-to-day to know how the code works performance wise with the data structures you are using.

ilostmykeys 11y ago
that CS stuff you can look up and understand when you need it, like when you're looking for an efficient algorithm to do xyz, and so you should have curiosity and a wise intuition but beyond that as a web developer that knowledge should not sit in your brain because it will occupy precious thinking resources that you should dedicate to building great UX and making the code modular and maintainable which takes dedicating brain cells to understanding the world around you, not just a commodity piece of textbook knowledge that makes you feel smarter and covers up insecurities about having produced dull or even terrible UX -- "hey I know how to balance a red/black tree or build a hashmap implementation so I must be a under appreciated genius" when in fact that is commodity knowledge anyone can pick up from Google and a few hours of research and benchmarking (and having ability to allocate regions of your brain to tasks of wildly different nature on the fly which means you never keep crap in your head unless you're using it on daily basis) We could write a thesis on this, right? and we would disagree wildly, but in the end go put up your amazing UX n youtube and show me how memorizing the Algorithm Design Manual helped you create that amazing UX. UI work is mostly art and craft, with math/cs still relevant but applied from an intuitive dynamic center of your brain, not stored and ready to put on a white board on demand.
- ryandrake 11y ago
  Bingo. If you're looking for someone who's a walking Wikipedia, then those "how does this algorithm work" or "what's the Big-O notation of that algorithm" questions will find that person. If you want someone who gets stuff done and is resourceful when they need to look something up, then that line of questioning is going to filter those people out.
ssmoot 11y ago
I get what you're saying. But I think there's a limit. IME there are platforms (Ruby, JS, others) that have such high method dispatch overhead that the fastest "algorithm" is generally the one with the smallest stack-trace for 99% of problems. It can be a very very very difficult bar to overcome. I've only ever seen algorithm choice play a meaningful role in traditionally fast/compiled languages. YMMV.
- tomp 11y ago
  Absolutely not. Even if you write an interpreter in Python, a hashtable lookup (O(1)) leading to an O(n) algorithm will be faster in this interpreted language than a O(n^2) algorithm using the O(n) list lookup in C; for a sufficiently high n, of course, but it's not uncommon to have n of several million these days.
  - ssmoot 11y ago
    It's absolutely very uncommon to have a single collection of several million in the languages I mentioned in the web-app space IME. Anyways, that's my experience with Ruby. Since each allocation (at the time) took 23 bytes of memory, even object graphs c# or Java might consider fairly modest (say loading 10,000 rows with a dozen fields into an Array<User>) would burn through a silly amount of memory comparably and probably trigger a GC cycle. We're talking nanoseconds on the compiled side vs hundreds of milliseconds. It takes a very very high N to overcome that sort of issue. One you might run into in scientific computing a lot more frequently, but not the sort of issue you'd often (if ever really) run into writing a web-app.
    - tomp 11y ago
      Ok, you're probably right about Ruby and JS. I was thinking about Python, which I would consider in the same class of "slow" (wav) languages, but it's also quite common to do data processing and machine learning in it.

JustSomeNobody 11y ago

This doesn't really address my first question. But, I can see how if they job doesn't require data structures and algorithms (say, just a simple CRUD app), sure, this type of interviewing is not beneficial.

cheapsteak 11y ago

Did they mean HashMap or were they using a fancier word for key/val store? Were they expecting you to account for collisions? If you ever have an array of a few thousand or hundred thousand items, knowing how to make a hashmap can be pretty useful for performance even in js

lhnz 11y ago
They were Java developers so I think they were coming at the interview from the perspective of Java developers. I wish I'd known this beforehand as I could have markedly improved my answers by bearing this in mind and explaining myself better. For example later on they were trying to test me on JavaScript type irregularities. I did not realise that `typeof null === 'object'` or think this was important in practice (although I expressed no surprise as when I'm trying to test any JavaScript type I generally use a high-level interface to avoid JavaScript 'wat' moments). They seemed to think I'd be doing if-elses at the top of each function in order to perform the type checks that Java would have given me for free. I mentioned that 'flow' would be a better idea if you weren't happy with duck typing, but this probably sounded like I was trying to dodge the question to a Java developer. In practice when you're writing JavaScript code, it's popular to be lax about this kind of thing and write code like `config || {}.property`. In conclusion: I think that Computer Science is useful but less useful here. I'm actually now mid-way into some Coursera algorithms courses for my own personal learning as I think they'll be very valuable in other tasks. I think the problem was that you could tell that they were primarily Java programmers by the topics that they gave importance. I'd say there's a strong chance that they'll hire somebody with a similar skill set to themselves and will not end up writing natural, best practices JavaScript. People hiring in languages and domains they do not know well can bias themselves with the wrong kinds of questions and opinions. This seems to be a common interview failure case.