30-Day Leetcoding Challenge
Tags: leetcode, computerscience, problemsolving, beginners
Published: 2020-04-08 12:52:07

[LeetCode](https://leetcode.com/) recently released a [30-Day Challenge](https://leetcode.com/explore/other/card/30-day-leetcoding-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?

![Why gif](https://media.tenor.com/images/937a21d12418e7879009a5e3f0d7ce2a/tenor.gif)

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](http://www.crackingthecodinginterview.com/)).

# Don'ts and Do's

![DOn't gif](https://1.bp.blogspot.com/-ytjMGtoyVnc/XYdpPLlerCI/AAAAAAAABY8/xs8b0iDBAtUufu4EhQm4L58Io2sUxiHLgCLcBGAsYHQ/s1600/externalFile.gif)

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:__
1. Don't search for solutions until trying to solve for a couple of hours
2. Don't just solve easy problems
3. Don't start by thinking of a solution in terms of Run time complexity or Space complexity

__Do's:__
0. Learn about popular data structures and algorithms 😬
1. Follow the BUD principle
2. Test your code against weird and edge cases 🤪
3. Identify patterns and note them
4. Try to simulate the problem in a real-world scenario and observe how you solve it (Surprisingly helps! but rarely)
5. Participate in many competitions


# Summary
I'm too lazy to summarize so click [here for the first post](https://dev.to/13point5/single-number-1agd). 
Have fun programming 👾