Leetcode - HackMD

# Leetcode ## Goals Many people use LeetCode incorrectly. Here's our step-by-step guide to most effectively grind LeetCode. The most important thing to recognize is what you are practicing for. In general, the primary goal of most people on Leetcode is to practice technical interviews. ## What not to do * Look at a question, think you know the solution, move on. * Do 30 problems the day before your interview. * Not do any leetcode at all. ## LeetCode vs Real Interviews The commonalities between leetcode and real interviews are: * The types of problems * Your first solution doesn't have to be the best solution * Online/Phone interviews are very similar to the LeetCode environment. The differences are: * Real interviews are timed. * Real interviews don't provide any starter code. * Real interviews don't tell you the problem category. * Real interviews don't tell you how hard a problem is going in. * Real interviews don't have a "Test" button which has all the unit tests. * Real interviews require communicating how you got to your solution just as much as arriving at the solution. That's a lot of differences, so when you do commit to practicing for interviews you need to have mechanisms for getting holistic practice sessions that can closely simulate a real interview. ## What's the best language It doesn't matter. If you use any of these you should almost never have an issue: * C++ * Java * Python * Javascript > [color=green] **Pick the one you know best. However, actually know the language you use. As a general rule of thumb, before you use a language in interviews, go write a 1000+ line project in it.** <details><summary>C++ Checklist</summary> // TODO * Standard Library * [Algorithms](https://en.cppreference.com/w/cpp/algorithm) * auto * shared_ptr, unique_ptr, vs raw pointer * const * Object Lifetime * Construstor vs Copy Constructor vs Move Constructor * Memory Leaks * Realize that C++ is a double edge sword. You'll either really show off your deep understanding or possibly make mistakes the interviewer considers very trival. </details> <details><summary>Java Checklist</summary> // TODO </details> <details><summary>Python Checklist</summary> // TODO </details> <details><summary>Javascript Checklist</summary> // TODO </details> ## Data Structure Review You won't gain much from Leetcode if you don't understand data structures. > **Have you implemented each of these data structures on your own without standard libraries?** > [color=red] If not, do that first! Its a much better use of your time than LeetCode. As a bonus, you can show off your knowledge on Github after you're done! | Category | Data Structures | | -------------------- | --------------------------------------------------------------- | | Linear | Array Vector Linked List Circular Buffer | | Restricted Linear | Stack Queue Priority Queue | | Heirarchial | Trie Binary Search Tree (BST) Balanced BST+ | | Containers | Unordered Set Unordered Map (Dictionary) | | *Group Name Pending* | Graphs Heap | +This is to implement Ordered Set and Ordered Map. For each data structure above, can you fill out this table without references? Some actions may not be applicable for certain data structures. Can you identify those? | | Insert * Index * Front * Back | Remove * Index * Front * Back | Access * Index * Front * Back | Find By Value | | - | - | - | - | - | | Array | | Vector | | Linked List | | Circular Buffer | | | | Stack | | Queue | | Priority Queue | | | | Trie | | Binary Search Tree (BST) | | Balanced BST | | | | Unordered Set | | Unordered Map | | | | Graph | | Heap | ### Properties Tables (Y/N unless otherwise specified). | | Sorted? | Indexable? | Insert Order Preserved | Memory Overhead (Big O) | | - | - | - | - | - | | Array | | Vector | | Linked List | | Circular Buffer | | | | Stack | | Queue | | Priority Queue | | | | Trie | | Binary Search Tree (BST) | | Balanced BST | | | | Unordered Set | | Unordered Map | | | | Graph | | Heap | ## General Routine > [color=green] **Practice every day, just two questions a day. One in the morning and one at night.** Don't aim to get good at problem solving over a month, aim to get good over six months. In six months, you'll have done 360 questions! > [color=green] **Set a 40 minutes timer.** If you don't solve a problem within the time limit, stop, look at the solution and try to fully understand the logic behind the implementation. Then try to implement the solution without looking at it. If you do solve the problem before the timer, ask yourself how you can improve that code? Organization? Runtime? Memory? If there's nothing left to improve, write a comment in your code describe why there's nothing left to improve. If there's still time left, pause the time and look at the solution and see what you can learn. > [color=green] **At least 2 sessions a week, practice without hitting the run button.** Some companies don't have compilers available so you just have a text editor. If you have the luxary of having access to a whiteboard, practice on that. > [color=green] **Ask for help.** If you see a solution you don't understand, ask someone else to help explain it to you. Conversely, explaining a solution is the same skillset you will need to explain your code in an interview so explaining solutions is important too. ## Breaking down a session. In this section we'll outline exactly how you should approach the 60 minute timer you've set for yourself. | Time | Section | Goal | |--- |- | --- | | 0:00 | 2 min | Understand the problem. | | 0:02 | 1 min | Write down the fuction signature. | | 0:03 | 5 min | Validate your understanding by throwing some test cases and seeing the result. During this process you may start to see some pattern. | | 0:08 | 5 min | Recommend a brute force solution orally. Can you write the psuedocode for it? If no solution use this time to quickly vocalize the thoughts you had from your test cases. | | 0:13 | 5 - 17 mins | For very easy questions, you should be able to implement the solution, express the runtime. Often in a real interview, for easy questions, the interviewer will then ask a second harder problem for which you can start from 0:00 again. | | 0:30 | 5 mins | Test your solution again the cases you came up with initially and fix any bugs | | 0:35 | 4 mins | Vocalize your undertanding of the solution. How could you make it better? Do you see optimizations? Are there any advesarial input cases? etc. | | 0:39 | 1 min | Congratulate yourself on a job well done and take a quick mental reset break | | 0:40 | 20 mins | Review the solution on leet code. Do you understand the solution? Is the O(runtime) different? What about O(memory)? Did they use different data structures? Did you miss some edge cases? Were there any key insight that you missed? | Notice at the 40 minute mark of every session, you should ALWAYS stop solving the problem and review instead. That will help leetcode not feel like an endless task. After one hour you should be done for that session. If you find you aren't able to understand the solution, or after two weeks you don't see any improvements, you may need to add an additional segment where you implement the solution without looking any reference.