3 ms·

I also keep seeing leetcode interview problems about iterating over a list of 100k items a few times. I can see that it is not optimal but iterating over 100k i

I also keep seeing leetcode interview problems about iterating over a list of 100k items a few times. I can see that it is not optimal but iterating over 100k items is NOTHING compared to the network call you made right after that iteration - in terms of actual production time. And every time I interview, the hiring managers want me but my hiring decision gets vetoed by a leetcode newbie who hasn't experienced production scars yet.

deleted 3y ago
[deleted]
diarrhea 3y ago
In an async framework of execution, this doesn't apply. A lot of programming happens in that space, and in it, the network call is "free", but you're clogging the thread(s) with actual CPU work. If execution is single-threaded, the problem becomes very relevant, but it applies to multi-threaded async just the same (you might exhaust the pool of workers). Keeping this in mind isn't esoteric either, as it applies to JavaScript, Python, Rust, C#, and probably others.
- nine_zeros 3y ago
  > In an async framework of execution, this doesn't apply. That's right. Async execution prevents the IO from being the bottleneck by offloading it to a different thread. There are 3 situations where this statement falls apart: 1. If the execution is single threaded, as you rightly pointed out 2. If the response of the async execution matters to the final response of your service. In this case, the primary thread may finish its work but its still waiting for IO to complete. Basically making it synchronous but using async primitives. 3. The CPU utilization of iterating over 100k items in a list is negligible compared to the hundreds of daemons and services running on the host. Even a docker container will utilize more CPU than iteration over 100k items. The point is: over-indexing over iteration and time-complexity in interviews is pointless as real systems are going to face challenges far beyond that.
mikhailfranco 3y ago
So true. Managers really want to hire architects/seniordevs who are experienced, practical, smart and get things done. But if they let the other devs into the interview process they will get vetoes all the way down, because the reports will be: - envious of your amazing pragmatic and effective skills - jealous guarding of the architect promotion that they covet for themselves
- wizofaus 3y ago
  Good managers for dev teams should have enough technical knowledge themselves and demand explanations from participating devs why a candidate is or isn't good enough to see through that though. Further personally as a tech lead I've always been keen to take on new devs that clearly are a cut above, as they usually mean an opportunity to work more effectively as a team. And I really don't want to spend even more of day doing reviews of mediocre code.
  - foobarian 3y ago
    > And I really don't want to spend even more of day doing reviews of mediocre code. Or writing essentially pseudocode in Jira description for the dev who can't figure things out. Ask me how I spent my day
  - nine_zeros 3y ago
    > Good managers for dev teams should have enough technical knowledge themselves and demand explanations from participating devs why a candidate is or isn't good enough to see through that though. I have a hunch that this is quite rare in most companies. Most managers are unskilled enough to override their own intuitions in favor of the mediocre leetcode dev that just vetoed a strong engineer.

deleted 3y ago

[deleted]

diarrhea 3y ago

In an async framework of execution, this doesn't apply. A lot of programming happens in that space, and in it, the network call is "free", but you're clogging the thread(s) with actual CPU work. If execution is single-threaded, the problem becomes very relevant, but it applies to multi-threaded async just the same (you might exhaust the pool of workers). Keeping this in mind isn't esoteric either, as it applies to JavaScript, Python, Rust, C#, and probably others.

nine_zeros 3y ago
> In an async framework of execution, this doesn't apply. That's right. Async execution prevents the IO from being the bottleneck by offloading it to a different thread. There are 3 situations where this statement falls apart: 1. If the execution is single threaded, as you rightly pointed out 2. If the response of the async execution matters to the final response of your service. In this case, the primary thread may finish its work but its still waiting for IO to complete. Basically making it synchronous but using async primitives. 3. The CPU utilization of iterating over 100k items in a list is negligible compared to the hundreds of daemons and services running on the host. Even a docker container will utilize more CPU than iteration over 100k items. The point is: over-indexing over iteration and time-complexity in interviews is pointless as real systems are going to face challenges far beyond that.

mikhailfranco 3y ago

So true. Managers really want to hire architects/seniordevs who are experienced, practical, smart and get things done. But if they let the other devs into the interview process they will get vetoes all the way down, because the reports will be: - envious of your amazing pragmatic and effective skills - jealous guarding of the architect promotion that they covet for themselves

wizofaus 3y ago
Good managers for dev teams should have enough technical knowledge themselves and demand explanations from participating devs why a candidate is or isn't good enough to see through that though. Further personally as a tech lead I've always been keen to take on new devs that clearly are a cut above, as they usually mean an opportunity to work more effectively as a team. And I really don't want to spend even more of day doing reviews of mediocre code.
- foobarian 3y ago
  > And I really don't want to spend even more of day doing reviews of mediocre code. Or writing essentially pseudocode in Jira description for the dev who can't figure things out. Ask me how I spent my day
- nine_zeros 3y ago
  > Good managers for dev teams should have enough technical knowledge themselves and demand explanations from participating devs why a candidate is or isn't good enough to see through that though. I have a hunch that this is quite rare in most companies. Most managers are unskilled enough to override their own intuitions in favor of the mediocre leetcode dev that just vetoed a strong engineer.