3 ms·

My advice is to get good at leetcode "the right way". Don't memorize problems. Instead, learn the underlying algorithms. Learn heapsort, quicksort, how to find

by lacker 4y ago

My advice is to get good at leetcode "the right way". Don't memorize problems. Instead, learn the underlying algorithms. Learn heapsort, quicksort, how to find medians, how to derandomize and calculate the running time of the quicksort/median algorithms. Learn how hash tables, red-black trees, and b trees work. Learn why vectors allow O(1) append but only if you amortize the analysis. Learn depth-first and breadth-first search, learn A*, learn all-pairs-shortest-paths. Learn enough dynamic programming that you could implement a memoize decorator. All of this is valuable knowledge. It'll pay off to learn this in the long run. Yeah, interviews overrate its importance. It's good to learn it anyway. If you learn that stuff and you are good at the basics of practical programming like string and array manipulation, you'll be able to do well at interviews.

spike021 4y ago
I won't argue that being able to apply different patterns to problems is incredibly useful, but a lot of these are also fairly domain-specific. It really depends on what your typical work is like. I've worked on teams that dealt with messaging queues and associated backend systems. In those cases it was rare, if ever needed at all, to see or use any kind of graph searching algorithms. Sometimes some forms of memoization were helpful when it came to system issues that required a meaningful but efficient backfilling strategy. But they were almost never in the same form that typical DP interview problems are. I would argue many of these patterns can be helpful to test candidates with but only depending on what roles they're interviewing for. I've seen more "trivial" problems that test for the same kinds of answers that interviewers usually want anyway. Usually the messaging is something like "we want to test that you can write code. We want to test that you can iterate over and consume/aggregate some data. We want to test that you can evaluate this codes performance." You can do all those things with simpler classes of problems than some of the brain teasers I've seen. And I don't mean the usual stuff like how many tennis balls fit in a school bus, but leetcode style, overly complex problems.
62951413 4y ago
As much as I agree with your advice in general my interviewing experience is completely the opposite. To begin with reading algo books/being aware of the topics you mentioned doesn't necessarily translate to solving leetcode _puzzles_. The last time they simply asked me to implement quicksort was almost ten years ago. What is even worse, usually you have about 30 minutes to solve a puzzle. You won't have time to think even if you are capable of thinking under such circumstances. Where I completely disagree with the original statement is that leetcoding hurts mostly experienced developers. What else are fresh graduates supposed to know well if not algorithms and data structures? Experienced developers are from generations when few people majored in CS and spent formative years interviewing long before anyone heard about leetcode. And they have too much experience with building real software to tolerate artificial puzzles.
romeros 4y ago
After all this knowledge you still won't be able to solve "Next Permutation" or "Integer to Words" or "LFU Cache" within a 45 min Interview if you haven't seen the problem before or never practiced enough leetcode for it to become subconscious and automatic.
- lacker 4y ago
  If you learn all this and you can't solve LFU cache in 45 minutes, go back and study the parts about heapsort, red-black trees, and B trees. If you learn all this and you can't solve "integer to words", go back and do some more practical programming. Build your own blog in Django or something. If you learn all this and you can't solve "next permutation", well, yeah sometimes interviews ask you dumb theoretical stuff that you will never use in real life. Them's the breaks.
dominotw 4y ago
>Learn heapsort, quicksort, how to find medians, how to derandomize and calculate the running time of the quicksort/median algorithms. i've done around 800 leets and never had to learn any of these. you can do a whole bunch of leets if you just learn the following and fill the gaps along the way 1. data structures: tries, maps, lists, heaps/priorityques, stack, dequeue. 2. graph: shortest paths, dfs, bfs, cycle detection, topological sorting, union find. 3. binary search

by lacker 4y ago

spike021 4y ago

I won't argue that being able to apply different patterns to problems is incredibly useful, but a lot of these are also fairly domain-specific. It really depends on what your typical work is like. I've worked on teams that dealt with messaging queues and associated backend systems. In those cases it was rare, if ever needed at all, to see or use any kind of graph searching algorithms. Sometimes some forms of memoization were helpful when it came to system issues that required a meaningful but efficient backfilling strategy. But they were almost never in the same form that typical DP interview problems are. I would argue many of these patterns can be helpful to test candidates with but only depending on what roles they're interviewing for. I've seen more "trivial" problems that test for the same kinds of answers that interviewers usually want anyway. Usually the messaging is something like "we want to test that you can write code. We want to test that you can iterate over and consume/aggregate some data. We want to test that you can evaluate this codes performance." You can do all those things with simpler classes of problems than some of the brain teasers I've seen. And I don't mean the usual stuff like how many tennis balls fit in a school bus, but leetcode style, overly complex problems.

62951413 4y ago

As much as I agree with your advice in general my interviewing experience is completely the opposite. To begin with reading algo books/being aware of the topics you mentioned doesn't necessarily translate to solving leetcode _puzzles_. The last time they simply asked me to implement quicksort was almost ten years ago. What is even worse, usually you have about 30 minutes to solve a puzzle. You won't have time to think even if you are capable of thinking under such circumstances. Where I completely disagree with the original statement is that leetcoding hurts mostly experienced developers. What else are fresh graduates supposed to know well if not algorithms and data structures? Experienced developers are from generations when few people majored in CS and spent formative years interviewing long before anyone heard about leetcode. And they have too much experience with building real software to tolerate artificial puzzles.

romeros 4y ago

After all this knowledge you still won't be able to solve "Next Permutation" or "Integer to Words" or "LFU Cache" within a 45 min Interview if you haven't seen the problem before or never practiced enough leetcode for it to become subconscious and automatic.

lacker 4y ago
If you learn all this and you can't solve LFU cache in 45 minutes, go back and study the parts about heapsort, red-black trees, and B trees. If you learn all this and you can't solve "integer to words", go back and do some more practical programming. Build your own blog in Django or something. If you learn all this and you can't solve "next permutation", well, yeah sometimes interviews ask you dumb theoretical stuff that you will never use in real life. Them's the breaks.

dominotw 4y ago

>Learn heapsort, quicksort, how to find medians, how to derandomize and calculate the running time of the quicksort/median algorithms. i've done around 800 leets and never had to learn any of these. you can do a whole bunch of leets if you just learn the following and fill the gaps along the way 1. data structures: tries, maps, lists, heaps/priorityques, stack, dequeue. 2. graph: shortest paths, dfs, bfs, cycle detection, topological sorting, union find. 3. binary search