LeetCode recently released a 30-Day Challenge where they will release a beginner-friendly programming problem every day starting from April 1st, which will be handpicked from their frequently asked interview questions along with 5 new problems.
They also have some nice rewards as incentives, but the condition is that you must solve every problem within 24 hours from the release time.
This is a very good challenge and opportunity if you're new to competitive programming or you want to warm up before solving hard problems.
I'm going to start a series of articles where I will post solutions. I encourage you to solve these problems by yourself, especially if you're a beginner in this field.
I've seen the first 7 problems and I'm sure that this challenge will be helpful in getting used to thinking differently and optimally.
Why this series?
In this series, you won't just find 1 optimal solution but rather a list of solutions that will progress from ineffective to optimal.
The reason I believe this is necessary is that it's difficult to think of an optimal solution in the first attempt and to truly become better you need to make mistakes and fix them by identifying bottlenecks, unnecessary work and duplicate work(BUD from Cracking the Coding Interview).
Don'ts and Do's
Usually, people try to search and learn things to do in order to get better at something but I have found that identifying things I do but I shouldn't be doing takes precedence.
When I first began competitive programming, I used to give up early and look at solutions, copy them into the editor, read it for a while and submit and feel good looking at that green tick â .
Then after a few competitions when I saw a question that seemed similar I would either try to remember the solution or search for my submission.
Pretty soon, I realized that this didn't help me grow, so I stopped copying solutions when I couldn't solve a question and tried to understand the algorithm behind a solution and then type it out myself.
Try to look at solutions written in languages other than your primary language because you may unconsciously try to remember code which is useless.
I use a pen and paper although I would suggest a notebook so that it can be a journal of your journey.
Dont's:
- Don't search for solutions until trying to solve for a couple of hours
- Don't just solve easy problems
- Don't start by thinking of a solution in terms of Run time complexity or Space complexity
Do's:
- Learn about popular data structures and algorithms ðŽ
- Follow the BUD principle
- Test your code against weird and edge cases ðĪŠ
- Identify patterns and note them
- Try to simulate the problem in a real-world scenario and observe how you solve it (Surprisingly helps! but rarely)
- Participate in many competitions
Summary
I'm too lazy to summarize so click here for the first post.
Have fun programming ðū
Top comments (0)