Dealing with DSA

As we were discussing a few good questions during a class, I figured out one thing. No matter how good you know the language, the major part is how to crack the logic. I often get close to the logic (or sometimes completely off), but hardly get it right without hints. And they are often the simplest approaches or the shortest answers. And I go like, So it was that simple!? At the end of the day, this is the most frustrating problem! Not able to crack a logic the right way, sometimes not even the brute force approach.

So reaching out to all the professionals here, How do you crack the logic? What goes on your mind while reading a problem? How to make the code even more optimized?

Imagine this-

You're trying to learn how to drive a car. You open YouTube, start watching driving tutorials. Or maybe that's too unrealistic. A more relatable version - You watch someone do it in front of you. You go like - "Haan Haan I get it. I'll do it now".

But the moment you sit in the driver's seat - the car stops, jerks, stalls. You panic! Where's the clutch, where's the brake? It's all so confusing.

That's exactly what was happening with me. Watched YouTube videos or my professor solving questions. Copied them and felt like now i know it all. But when it came to solve questions on my own - failed miserably!

It all changed when i got myself to solve more and watch less. I failed, but now i had a clearer idea of what worked, what mistakes i could learn from. Then when i watched…

While learning DSA, I’ve realized that how  you approach problems matters even more than just solving a lot of them. These are a few mindset shifts I’ve picked up — mostly from mistakes I kept repeating 😅

Here’s what I’ve learned not to do:

1. Rushing to code before understanding the problem - Now, I slow down. First read? Just to get the idea. Second read? To catch the hidden edge cases and constraints.

2. Skipping examples- Visualizing the example inputs (like 1→2→4 etc.) gives surprising clarity. It helps me see what’s really happening.

3. Avoiding brute force out of fear- I’ve started asking, “What’s the simplest, even dumbest, way to solve this?” It often unlocks the pattern I need later.

4. Trying to hold the whole problem in my head- I now break it into tiny, testable steps. Print/debug early. You don’t need to solve everything in one go.

The beginning always feels tough.

As someone who has started learning about data structures very recently (not even the algorithms yet), the concepts sometimes are confusing. And when it comes solving problems, it feels like a battlefield and I am fighting with swords but absolutely no training.

The major challenges i face:

• Building logics and then actual code

• Tons of errors and not able to understand the real problem

• Everyone's moving faster but I am stuck

Hi!

Thought I would share a resource I've been using to learn DSA, in python.

It's on youtube, so you can use it for free.

A common mistake what everyone does when getting into DSA , they directly dive into LeetCode without learning the prerequisites and sit with questions for hours together, failing to understand it.

When we were in school, we were all taught in a pattern, for example you were taught the A,B,C's , then words, and later on sentences.

It’s something you’ve atleast heard if you’re into technology. DSA this, DSA that, many people fear this, and many strive. But what is DSA? For those who uninitiated, it stands for Data Structures and Algorithms. Divided into two parts DS (Data Structures) which deal with data organisation (Arrays, Strings…) and Algorithms (step by step formulas to curate a solution).

All this information is fine, but what can you do about it? How do I learn it, and how do I master it. It’s not easy, but it’s not impossible.

Let’s elaborate on step 1:

The first step would be to concentrate on building a strong foundation. These include having a strong grasp over a programming language (C++ is the fastest and most common, with Python in the roster, but Java which is the most asked in interviews) through actually learning and building hands on projects (small as a simple hello…