3 ms·
great advice. id say limit yourself to 10 mins to come up with a solution, and focus on getting a solid intuition consistently
by 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 agoLet'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 agoFor 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 agoI 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?