3 ms·

> Being good at "leetcode" problems and being good at writing good production algorithms certainly have some overlap... but it's not very large, and they're act

> Being good at "leetcode" problems and being good at writing good production algorithms certainly have some overlap... but it's not very large, and they're actively at odds with each other quite often. Except in this particular example, where someone managed to write a quadratic algorithm for arranging icons.

jerf 6y ago
It's the leetcoder who would have written the O(n^2) algorithm and figured it's OK because it passes all the cases thrown at it. A leetcoder doesn't optimize everything, just the thing for the problem they're facing today. It's the person used to writing production code who would have stopped to think about the fact that the cases we tested with today may not be representative of the entire problem space. Leetcode is throwaway code. Writing tons and tons of throwaway code is, like I said, not completely unrelated to writing good production code. To get good at coding, as with anything, it is necessary but not sufficient to code a lot. But this is the sort of thing that I'd expect a leetcoder to do in practice; to miss the real problems, probably because they were off hyperoptimizing something else that was irrelevant.
- baobabKoodaa 6y ago
  I don't understand why you're trying to make this argument. You said: > being good at writing good production algorithms certainly have some overlap... but it's not very large I agreed with you, and noted that this specific case is an exception: > Except in this particular example, where someone managed to write a quadratic algorithm for arranging icons. It seems to me like you're trying to take the most extreme position that's available in this discussion: you're trying to claim that being good at optimizing algorithmic time complexity ("good at leetcode") does not help someone at optimizing algorithmic time complexity in production, because there's some kind of mythical distinction between "throwaway code" and "production code". That distinction is not relevant here. Someone who is good at optimizing algorithmic time complexity in throwaway code is certainly good at optimizing algorithmic time complexity in production code. Just like someone who is good at riding horses is also good at riding horses on a sunny day. Or someone who is good at painting with acrylic is also good at painting with watercolors, if you compare to another person who doesn't have any experience painting.

jerf 6y ago

It's the leetcoder who would have written the O(n^2) algorithm and figured it's OK because it passes all the cases thrown at it. A leetcoder doesn't optimize everything, just the thing for the problem they're facing today. It's the person used to writing production code who would have stopped to think about the fact that the cases we tested with today may not be representative of the entire problem space. Leetcode is throwaway code. Writing tons and tons of throwaway code is, like I said, not completely unrelated to writing good production code. To get good at coding, as with anything, it is necessary but not sufficient to code a lot. But this is the sort of thing that I'd expect a leetcoder to do in practice; to miss the real problems, probably because they were off hyperoptimizing something else that was irrelevant.

baobabKoodaa 6y ago
I don't understand why you're trying to make this argument. You said: > being good at writing good production algorithms certainly have some overlap... but it's not very large I agreed with you, and noted that this specific case is an exception: > Except in this particular example, where someone managed to write a quadratic algorithm for arranging icons. It seems to me like you're trying to take the most extreme position that's available in this discussion: you're trying to claim that being good at optimizing algorithmic time complexity ("good at leetcode") does not help someone at optimizing algorithmic time complexity in production, because there's some kind of mythical distinction between "throwaway code" and "production code". That distinction is not relevant here. Someone who is good at optimizing algorithmic time complexity in throwaway code is certainly good at optimizing algorithmic time complexity in production code. Just like someone who is good at riding horses is also good at riding horses on a sunny day. Or someone who is good at painting with acrylic is also good at painting with watercolors, if you compare to another person who doesn't have any experience painting.