DEV Community: Pulla Indira Keerthana

Is it really important to start DSA early?

Pulla Indira Keerthana — Fri, 03 Jul 2026 16:24:39 +0000

I Keep Restarting DSA. Am I the Only One?

I'm a Computer Science undergraduate, and I have a confession to make: I've started learning Data Structures and Algorithms more times than I can count.

Every time, the journey looks exactly the same. I begin with arrays, move on to strings, solve a handful of easy problems, get stuck, lose momentum, and eventually stop. A few weeks or months later, I convince myself that this time will be different. And somehow, I end up back at arrays and strings again.

It's become a cycle that I genuinely don't know how to break.

The frustrating part is that I don't actually dislike DSA. When I read a problem, I can usually understand what's being asked. Most of the time, I can even think of the right approach or explain the logic to someone else. But the moment I open the editor and start coding, everything seems to disappear. I miss edge cases, my implementation doesn't work the way I imagined, or I get stuck translating the idea in my head into actual code.

After looking at the solution, I often find myself thinking, "I knew the logic... so why couldn't I write it?" That's probably the most discouraging feeling I've experienced while learning programming.

What makes it even harder is looking around at everyone else online.

You open LinkedIn and see someone celebrating their 1,000th LeetCode problem. YouTube recommends videos promising to teach "Complete DSA in 30 Days." Reddit discussions revolve around Codeforces ratings, competitive programming, and how many questions you should solve before placements. Then you hear that some companies expect candidates to have competitive programming experience, and you start wondering if you've already fallen behind before you've even begun.

Honestly, one thing I've never fully understood is why competitive programming is considered so important for some companies. I understand that it develops problem-solving skills and algorithmic thinking, but sometimes it feels entirely different. Maybe I'm missing something, and I'd genuinely like to understand that perspective better.

Another challenge is the sheer number of resources available today. LeetCode, CodeChef, HackerEarth, Striver's A2Z Sheet, YouTube playlists, roadmaps, there are so many excellent resources that choosing one becomes overwhelming. Instead of feeling prepared, I often end up feeling stuck because I'm constantly wondering whether I'm following the "right" path.

Over time, I've started to realize that my biggest obstacle probably isn't DSA itself. It's the pressure I put on myself. I expect to solve problems without hints. I expect to write perfect code the first time. I expect to make steady progress without struggling. When those expectations aren't met, I convince myself that maybe I'm just not good enough and simply rely on AI.

But maybe that's not true.

Maybe understanding a solution and implementing it are two completely different skills. Maybe writing buggy code is part of learning how to write good code. Maybe revisiting arrays for the tenth time doesn't mean I've failed—it just means I'm still building a foundation.

I'm writing this because I have a feeling I'm not the only one who's experienced this.

If you've ever restarted DSA multiple times, understood the logic but struggled to implement it, or felt overwhelmed by the endless advice and resources online, I'd love to hear your story.

More importantly, if you managed to break out of that cycle, what changed?

I'm not looking for shortcuts anymore. I just want to stop restarting and keep moving forward, one problem at a time.

What Really Happens at Your First Hackathon?

Pulla Indira Keerthana — Thu, 25 Jun 2026 10:06:08 +0000

My First Hackathon Was Nothing Like I Expected

It was just one month into my college journey when an announcement came through about the internal selections for Hack4SDG, a hackathon that was going to take place at IIT Hyderabad.

At first, I almost skipped registering.

I didn't think I was ready. None of us really knew what a hackathon was like. But my friends and I paused for a moment and thought, "Why not? Let's just give it a try."

That one decision started everything.

We picked a problem statement, brainstormed ideas for a few days, came up with a possible solution, and prepared a presentation for the internal ideathon organized by our college.

The First Time I Spoke in Front of Everyone

I had never spoken in front of an audience before.
Seeing all the teams waiting for their turn made me even more nervous. Most of them were seniors, and they seemed far more experienced than us.
I couldn't focus.
My mind kept telling me that everyone knew more than I did.
Then suddenly I thought...

"I'm just explaining a solution that my team and I worked hard on."

As the team leader, I spoke last. I explained why it was important for people to understand the carbon footprints they leave behind and why awareness alone isn't enough unless we take action.

I wasn't confident because I was good at public speaking.
I was confident because I had done the research.
Once I started talking, everything else disappeared.

The Unexpected Excel Sheet

After the presentations, we honestly didn't expect much.
There were so many experienced seniors with amazing ideas that we assumed they would be selected.
While I was on my way home, I received an Excel sheet listing the selected teams. Our team's name was there. That's it.

We were going to IIT Hyderabad.
My friends and I couldn't believe it.

Reality Hit

The excitement lasted only until we realized something.

We had never participated in a hackathon before. We didn't know any tech stack well enough. We didn't know how people built complete solutions in just 24 hours. We had no experience.
But then again...

Everyone has to start somewhere.This was our starting point.

Walking Into IIT Hyderabad

The day we entered IIT Hyderabad felt magical.

Hundreds of students from different colleges had gathered with the same goal—to build something meaningful, learn new things, and meet like-minded people.

The hackathon had three evaluation rounds, one every eight hours.

We understood the problem statement, planned our work, and even used AI chatbots to help us move faster whenever we got stuck.

Everything seemed to be going well. Until the first evaluation.

Our First Reality Check

We demonstrated what we had built so far. Then we looked around.
Teams with experienced seniors had already developed polished solutions. Some had working hardware. Others already had almost complete applications. We were nowhere close.

For a few moments, it felt discouraging. But after talking as a team, we decided to stop comparing ourselves. This wasn't our competition. It was our first experience.

The Best Part of the Hackathon

Later that night, after dinner, we returned to the lab determined to make the most of the remaining hours.

That's when we met a group of seniors from another university who were building an IoT-based solution.

Instead of staying focused only on our own laptops, we walked over and started talking to them.

They explained their project.
They shared stories about their first hackathon.
They laughed about all the mistakes they had made.

Suddenly...

It felt relatable.

That's when I realized that hackathons aren't only about coding.
They're about conversations.
They're about meeting people who are just as curious as you are.

Some are beginners.
Some are experts.

But everyone started somewhere.

Winning Was Never the Best Part

By the end of the hackathon, we knew we weren't going to win.

And surprisingly...

We were okay with that.
We had learned more in 24 hours than we expected.
We had made friends.
We had built connections.
We had experienced our first real hackathon.

When the winners were announced, one of them was the IoT team we had spoken to the previous night. Instead of feeling disappointed, we were genuinely happy for them. We celebrated their win because, by then, it didn't feel like we were competing anymore.

It felt like we were all part of the same journey.

Looking Back

My first hackathon went nothing like I had imagined.

We didn't win. We weren't the most experienced team. Our solution wasn't perfect.

But I left IIT Hyderabad with something much more valuable than a certificate.

Confidence.

If you're thinking about participating in your first hackathon but keep telling yourself that you're not good enough, remember this:

You don't have to be the best person in the room. You just have to be willing to walk into it.

Whether you win or not, you'll come back with stories, friendships, lessons, and memories that stay with you long after the hackathon ends.

And for me, that was the real prize.

How Learning Git & GitHub Gave Direction to My Developer Journey

Pulla Indira Keerthana — Wed, 24 Jun 2026 17:51:45 +0000

The Git Cheat Sheet That Saved My First Year of College

When I joined college as a first-year student, I had no idea which direction I should take.

Should I focus on projects?

Should I start learning DSA?

Should I learn multiple programming languages?

Should I pick a tech stack first?

Everyone around me seemed to have a different answer. Some told me to build projects immediately, while others insisted that DSA was the only thing that mattered. A few suggested learning every new technology I came across.

The result? Confusion.

Looking back, I realize that this dilemma cost me a significant part of my first year. I spent more time wondering where to start than actually starting.

That's when I understood something important:

I didn't need to follow someone else's journey. I needed to create my own.

Before learning web development, DSA, or any framework, I decided to learn one thing that would stay useful throughout my entire journey:

Git & GitHub

Learning Git and GitHub turned out to be one of the best decisions I made as a beginner.

It helped me:

Track my projects
Manage hackathon submissions
Monitor my learning progress
Understand how real-world development works
Collaborate with others more effectively

However, learning Git wasn't easy.

I constantly forgot which command to use in different situations. Every time I opened the terminal, I found myself searching for commands again and again.

So I created something simple for myself—a Git Cheat Sheet.

Not a huge document filled with advanced commands.

Just the essential commands that a beginner needs while working on small projects and learning the Git workflow.

As I continued using it, I became more comfortable with Git, repositories, commits, branches, and project structures. Eventually, when I started teaching Git and GitHub to my friends, I shared the same cheat sheet with them.

To my surprise, they found it incredibly helpful.

That's when I realized another important lesson:

Learning becomes much easier when you have a clear starting point.

Most resources focus on the destination. They tell you what you should become, what technologies you should learn, and what achievements you should aim for.

But beginners often struggle with something much simpler:

"Where do I start?"

Once you know your starting point, you can build your own path, choose your own destination, and learn at your own pace.

This Git Cheat Sheet helped me and many of my friends understand Git without feeling overwhelmed.

I hope it helps you too.

Happy coding! 🚀