4 ms·

While implementation details may be unnecessary, I feel like knowing how something performs for lookups, insertions, deletions, etc. is important. It definitely

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.

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.