3 ms·

I'm also trying to figure this out, here's my approach so far. 1. Categorize - Can I identify what type of problem this is? (ie Graph problem, bit problem, sli

I'm also trying to figure this out, here's my approach so far. 1. Categorize - Can I identify what type of problem this is? (ie Graph problem, bit problem, sliding window, etc.)? 2. Plan a solution - Can I come up with a strategy to solve it? 3. Based on how I felt about 1 and 2, am I confident enough to dive in and solve it? 3A. If yes, as a final check, go to the discussions and see if you can get some confirmation that you had the right approach just by reading the titles. For example, if you were thinking that this was a backtracking problem because that was the only way you thought it could be solved and you see that the most upvoted posts are talking about priority queus, you probably had the wrong approach. Otherwise if it looks like you were on the right track, only then should you go ahead and start coding it. 3B. If you had the wrong approach or if you weren't confident that you could solve it, then go ahead and learn from the solution. You will learn a lot from the solutions that others posts but you will hardly learn anything by wasting hours on a flawed solution. To be clear, to get good requires going well beyond the fundamentals, you need to learn from the best of the best in order to stand a chance.

marcuspvk 7y ago
great advice. id say limit yourself to 10 mins to come up with a solution, and focus on getting a solid intuition consistently
- rubicon33 7y ago
  Let's take ThreeSum as an example. Imagine you're encountering ThreeSum for the FIRST TIME as I did a few days ago. I'd never before seen this problem. What should my EXPECTATION OF SELF be for this? What is reasonable for someone STUDYING to improve at algorithms. What would be considered SUCCESS? Should I .... be able to intuit the O(N + NlogN) solution? Ok maybe you would agree that's unreasonable to be able to just come up with naturally having never seen the problem before. Should I ... be able to intuit the O(n^2 * logn) solution? Even that solution might reasonably evade someone? Or not? Should I .... be able to intuit the brute force solution O(N^3) but have the O(N + NlogN) solution memorized? From wiki https://en.wikipedia.org/wiki/3SUM https://en.wikipedia.org/wiki/3SUM ... it appears that the O(N + NlogN) took formal algorithm research and study. Perhaps it's unreasonable to expect myself to on-the-fly solve some of these algorithms with sub-cubic time?
  - shahbaby 7y ago
    For a new problem, success is any solution that passes all test cases and implemented within an acceptable time frame. I personally think leetcode focuses a bit too much on runtime. In a real interview, the clock is ticking down and the stakes are high. Most people won't pass all test cases. Sometimes it's not even necessary to pass them all to make it to the next round. It's much easier to rank candidates by how many test cases they passed than by their algorithm's efficiency. So in a real interview: #passedTCs > algorithm efficiency
  - bakuninsbart 7y ago
    I would count the stages of success like this: 1. Brute force it. -> That is actually the most important step. In regards to this one specifically, I would be surprised if interviewers expect more than O(n^2). 2. Guess what the best runtime would be. -> If you can reason why you expect what to be the best runtime, it should bring you through all interviews. 3. Get good solutions, but memorizing won't help you in the real world (though it might in some interviews). Interview situation is pretty unique. In a normal work environment, you can search the internet, argue with collegues, sleep over it. If runtime is essential for the program you are writing, it cannot be expected of anyone to come up with best solutions on the fly. Regarding brute force solutions, they can still vary in quality. Is it correct, easily understandable, without side-effects?

marcuspvk 7y ago

great advice. id say limit yourself to 10 mins to come up with a solution, and focus on getting a solid intuition consistently

rubicon33 7y ago
Let's take ThreeSum as an example. Imagine you're encountering ThreeSum for the FIRST TIME as I did a few days ago. I'd never before seen this problem. What should my EXPECTATION OF SELF be for this? What is reasonable for someone STUDYING to improve at algorithms. What would be considered SUCCESS? Should I .... be able to intuit the O(N + NlogN) solution? Ok maybe you would agree that's unreasonable to be able to just come up with naturally having never seen the problem before. Should I ... be able to intuit the O(n^2 * logn) solution? Even that solution might reasonably evade someone? Or not? Should I .... be able to intuit the brute force solution O(N^3) but have the O(N + NlogN) solution memorized? From wiki https://en.wikipedia.org/wiki/3SUM https://en.wikipedia.org/wiki/3SUM ... it appears that the O(N + NlogN) took formal algorithm research and study. Perhaps it's unreasonable to expect myself to on-the-fly solve some of these algorithms with sub-cubic time?
- shahbaby 7y ago
  For a new problem, success is any solution that passes all test cases and implemented within an acceptable time frame. I personally think leetcode focuses a bit too much on runtime. In a real interview, the clock is ticking down and the stakes are high. Most people won't pass all test cases. Sometimes it's not even necessary to pass them all to make it to the next round. It's much easier to rank candidates by how many test cases they passed than by their algorithm's efficiency. So in a real interview: #passedTCs > algorithm efficiency
- bakuninsbart 7y ago
  I would count the stages of success like this: 1. Brute force it. -> That is actually the most important step. In regards to this one specifically, I would be surprised if interviewers expect more than O(n^2). 2. Guess what the best runtime would be. -> If you can reason why you expect what to be the best runtime, it should bring you through all interviews. 3. Get good solutions, but memorizing won't help you in the real world (though it might in some interviews). Interview situation is pretty unique. In a normal work environment, you can search the internet, argue with collegues, sleep over it. If runtime is essential for the program you are writing, it cannot be expected of anyone to come up with best solutions on the fly. Regarding brute force solutions, they can still vary in quality. Is it correct, easily understandable, without side-effects?