Skip to content

Commit 785165b

Browse files
authored
Merge pull request #49 from tiationg-kho/update
update README
2 parents f799f34 + 9c90e81 commit 785165b

File tree

1 file changed

+27
-1
lines changed

1 file changed

+27
-1
lines changed

README.md

Lines changed: 27 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -536,4 +536,30 @@ Feel free to raise issues or post in discussions.
536536
| 514 | | [218. The Skyline Problem](https://leetcode.com/problems/the-skyline-problem/) | [P]segment-tree | use max type segment tree | [Python]([P]segment-tree/[P]segment-tree/218-the-skyline-problem.py) |
537537
| 515 | | [2407. Longest Increasing Subsequence II](https://leetcode.com/problems/longest-increasing-subsequence-ii/) | [P]segment-tree | use max type segment tree | [Python]([P]segment-tree/[P]segment-tree/2407-longest-increasing-subsequence-ii.py) |
538538
| 516 | | [731. My Calendar II](https://leetcode.com/problems/my-calendar-ii/) | [P]segment-tree | use max type segment tree | [Python]([P]segment-tree/[P]segment-tree/731-my-calendar-ii.py) |
539-
| 517 | | [basic]([Q]basic/basic.md) | [Q]basic | | |
539+
| 517 | | [basic]([Q]basic/basic.md) | [Q]basic | | |
540+
541+
**How to crack LeetCode problems?**
542+
543+
- For beginners tackling 0-50 problems, I suggest starting with curated lists like the Blind 75, Grind 75, or NeetCode 150. It's crucial to begin with EASY problems. If you stumble upon unfamiliar concepts, don't hesitate to seek explanations from sources like ChatGPT or the LeetCode discussion section. Aim to accomplish three key objectives during this phase: familiarize yourself with the syntax of common data structures like hashmaps or stacks, gain a holistic understanding of necessary DSA topics, and grasp at least the brute force solution approach, along with basic analyses of time and space complexity for each problem.
544+
545+
- For intermediates solving 50-150 problems, understanding how and why to evolve from brute force to more efficient or optimal solutions is vital. Grasping this transition process is crucial, not just memorizing solutions. At this stage, deeply comprehending the improvement mechanism is the key focus. Often, the breakpoint for a better solution comes from identifying and refining repetitive elements in the old approach.
546+
547+
- After solving over 150 problems, you'll likely have covered around 85% of the topics that could appear in coding interviews. The key at this phase is to recognize patterns across the multitude of problems available. Most questions are variations of a few core concepts or classic problems you've already encountered. Identifying these patterns allows you to apply known solutions to new, seemingly complex problems effectively. Additionally, you should start using different approaches to solve the same problem you already know. For example, if it is a DFS problem, then try both recursive and iterative methods; if it is a DP problem, try both top-down and bottom-up approaches; if it is a top-k problem, then try using a heap or sort. Furthermore, attempt to understand other solutions that use approaches that are not as straightforward as your old solutions. At this stage, it's crucial to recognize recurring patterns across various problems, understanding both the application of consistent approaches to different questions and the exploration of multiple strategies for a single problem. This dual awareness enables a more adaptable and comprehensive problem-solving skill set.
548+
549+
**How to prepare for a coding interview?**
550+
551+
During the interview, consistently share your thoughts with the interviewer and use code comments to note down things while speaking. This ensures both of you are aligned.
552+
553+
1. `Clarify the requirement of the question`. You must truly understand what the question is asking for. Once you understand the question’s description, make sure to generate a simple input and expect output other than the given one based on your understanding and ask the interviewer if it is correct or not.
554+
555+
2. `Clarify the input and output and edge cases`. For instance, ask if the input array is sorted or not, whether numbers can include positives, negatives, or zeros, or if the input contains duplicate elements or not, and how to handle multiple valid answers, whether to return the first one or if outputs need sorting, and what is the expected outcome when there are no valid solutions. Take LC 209. Minimum Size Subarray Sum as example, if numbers in the input array can be negative, the question will become LC 862. Shortest Subarray with Sum at Least K, and will need a totally different approach to solve.
556+
557+
3. `Start from a brute force approach`, just write some very simple pseudo steps of it. If you have ideas to improve it, then you can continue to explain how and where you can improve and use which DSA or classic pattern (like prefix sum, trie, or two pointers) to solve it. Mention the expected time and space complexity. If you do not have any clue to improve the naive approach, then just ask the interviewer, can we start from implementing this naive approach or not, sometimes you would find out the key point during implementing. If it is not allowed, then try to analyze some common DSA which might be useful here to the interviewer and try to get some feedback or hints from the interviewer. (If brute force is still too hard to get, then try to simulate the whole process in the description of the question or try to enumerate things).
558+
559+
4. `Implement the solution`, adhering to proper coding style and indentation. If stuck on certain code, ask to finish the main logic first and leave comments for unimplemented parts. If stuck on the main logic, share your thoughts and discuss potential next steps with the interviewer.
560+
561+
5. `Final check and dry run`. Once finished, do not directly run the code, because there might be some stupid typos in the code. Ask if you can dry run one time, and explain the whole process and your thoughts.
562+
563+
6. `Test and debug`. Generate 1 or 2 standard cases and 1 or 2 edge cases which are related to the problem. And start testing and debugging. Avoid trial and error multiple times when debugging. Fix the error you find, and try to quickly dry run once and explain why you fix the error.
564+
565+
7. `Complexity analysis`. Try to analyze the time and space complexity about your solutions and try to mention some potential follow up questions you have thought of. Like what if we change the condition of the input, or what if we have a limitation on time or space usage.

0 commit comments

Comments
 (0)