In this reflection, I want to share insights from my coding journey, along with some of my practices and statistics.I'm happy with my efforts, even though I haven't met all my initial expectations. While I've relied on study plans and daily challenges for many problems, I'm pleased with the progress I've made.
Goal
My goal*(short term)* is to Build MERN Projects, Diversify Knowledge (especially in MERN), contribute to Open Source, go through some well recognised
Dev Educators course(like harkirat, hitesh choudary, etc)
Deepen Understanding. I'm doing my best to get at a good level to Built projects. By good level I mean in choosing Projects, writing Quality Code and mastering
the usual suspects data structures, and most relevant algorithms for striking problems.
EXPECTATIONS
When I first started out with coding challenges, I was blown away by a classmate who had solved hundreds of problems. It seemed impossible! These problems took me forever,
so how could anyone do so many? I pictured this person as a coding genius, some kind of programming superstar. I started dreaming about what it would be like to solve that many
problems myself. What kind of coder would I become? What cool stuff could I build? How fast would I be able to solve problems, and how much better would I be at projects?
Once I hit 200 solved problems (in my imagination!), I had big expectations.
- I thought I'd breeze through easy LeetCode questions in no time.
- I figured I could handle most medium-level problems pretty quickly, too, and always find the best way to solve them.
- Even the really hard ones, I thought I could at least come up with a rough solution after some thinking.
- I also kind of assumed all the coding tricks and algorithms I'd learned would just be there in my brain, ready to go.
- I thought if I'd seen a problem before, I'd remember exactly how to solve it the second time around. (Turns out, that's not always true – some problems are still tough even if you've
seen them before!). Mostly, I expected to get a lot faster at solving problems, like way faster than I was before. - I had hoped to be competitive in contests by now, finishing them comfortably within the time limit. While I've definitely improved, I'm not quite there yet. It feels like I'm still at the
beginning of my journey, even after all this time.
Solved Problems
easy - 91
medium - 102
hard - 7
Time spent per question
Easy problems (~ 1h - 2h)
solving 30m to 1h
solutions 30m - 1h
Medium problems (~3h30)
solving 2h00
solutions 1h30
Hard Problems (If I can solve them ~7h)
solving +5h
solutions +2h
But the recommended time was from 15 to 45 minutes.
15 to easy
30 to medium
45 to hard.
CONTEST
My first contest was 384 (virtual).
It was very important to me, because I was thinking that I was doing great on code problems, but not even close.I only made one question on time.I only did the easy question.
for the next medium question I took more time than the full contest.
Actually I didnt solved it at all. (I'll solve it later). I took a lot of time to get the program compiling had a lot of troubles debuging.
The most valuable lessons from the contest were:
- I'm too slow
- I cannot debug my code very well without IDE
- I need to keep doing this contest exercises because they are a cool random source of exercises
- there are very well prepared people! I need to practice more!
IMPROVED SOLVING TIME PER QUESTION
I've improved the time per questions, it's not perfect though.
I do easy questions much quicker , as well as medium and hard questions.
But there is always a black swan, and I cannot do all the easy questions in 25 minutes, maybe 70%.
For medium questions the percentage is lower, maybe 25% I can do in half an hr.
Hard questions I do them in about 4,6hrs, 3hrs, some in 2hr or less. With a good number of trials in between.
I generally don't repeate questions but When I do I get ridiculously faster.
That's actually the only situation so far where I can do Hard questions in 1hr or less.
LIMITING TIME
I've started implementing time limits for coding questions: 30 minutes for easy, 45-60 minutes for medium, and 90 minutes for hard. I can always go over these limits if I feel
close to a solution. This is a change from how I used to approach things. Initially, I wouldn't stop until I'd solved the problem. But now, I'm confident that I can figure most things
out eventually, even if it takes some effort. This gives me the freedom to take strategic shortcuts, knowing I can rely on my logical and critical thinking skills. The most important
thing is to make sure I'm actually learning and not just memorizing solutions.
Revisiting Questions
Earlier I used to do a question once and never visited again.But later i found this philosophy to be fatal. In the begining I did not care about my solution that whether it is and optimal
or not, just submitting the code matters to me at that time. I considered watching soltion as a cheating and didn't even watch the solutions (first 40-50 questions) if my solution beats
100% I just moved. I battled for 1h30 to come um with a weak non optimized solution. that was the moment I realized that I needed to review my previous questions, specially If I didn't
implemented an optimal solution and still I have not completly resolve it till today.
A strategy for reviewing questions.
Spaced repetition is a technique where you revisit a problem or topic at specific intervals, like every 10 questions you solve. It helps you become more familiar with the logic and
concepts behind the problem, rather than just memorizing the code. So, even if you can't solve the problem right away, by revisiting it regularly, you can improve your understanding
and ability to solve it over time. I use this technique personally and is really helpful.
Solving Problem's Process
My process might be quite inefficient, but as a beginner these worked upon me:
- Manual Problem Solving
- Note it down (the thought process and actions).
- Find Patterns.
- Manual Verification.
- Code Translation.
- Test Case Execution (Dry run).
- Debug Failed Test Cases.
Sometimes, even easy questions leave me stuck, even after I've looked at the solution. I try to understand it step by step, write it down, and then try to solve it myself
before going back to platforms like LeetCode.
Despite studying solutions, certain problems still present a challenge in grasping their inner workings.
It feels like I have understood the problem but the second time when I come back to it, I get the logic but I am unable to code it. I am like again stuck.
I'm worried that I might be memorizing solutions instead of really understanding them.
I'm not trying to speed through this process, but I am dedicated to solving at least one problem every day.
ACCEPTING TEMPORARY DEFEAT
I've learned to be okay with not solving a problem immediately. As I mentioned before, I used to keep at it until I found a solution, no matter how long it took – sometimes
half an hour, sometimes even four or more. This was exhausting and drained my energy, often affecting my performance the next day. A key lesson I've learned is that it's
okay to walk away from a problem.
I've accepted that I won't always solve everything right away. Some problems might take days of effort, and some I might not solve at all, even if I feel like I'm close.
Regex patterns, strong passwords, and dividing chocolate were examples of problems that stumped me. But not solving a problem today doesn't mean I've failed completely.
I can always come back to it later. I had to swallow my pride for the bigger picture. And it's made a difference. I feel better both personally and professionally. This ties in directly
with the importance of rest. Accepting temporary defeat can give you the mental break you need to come back stronger.
We should never forget that this is about the journey and not so much about the end goal, the path we go throught to be what we want to be is what make us stronger.
Please Feel Free To Feedback Me
Hope you enjoyed the read.
If you have advice for me, please I'm all ears!
