This is a 4 minute read. But if even one thing here clicks, it will change how you study for the next few years.
If you are in your 1st or 2nd year
Learn to solve problems. That is the whole job right now.
Not Codeforces rating. Not becoming a competitive programmer. The point of CP is to make you smart enough to think through hard problems without freezing up. It trains your brain to break things down, spot patterns, and write correct code under pressure. That skill is exactly what companies test you on in technical rounds, and it is exactly what separates people who can think from people who can only copy.
Learn the fundamentals for real. Data structures and algorithms are not things you memorize for exams and forget. They are the vocabulary you will use for the rest of your career. If you do not understand why a hash map is O(1) or what a binary search tree actually does, you are building on sand.
Do not chase ranks. Solve problems because they make you better. Go deep, not fast.
If you are in your 3rd or 4th year
Shift your focus to Software Engineering. Real SWE. The kind that makes you different in a room full of people who also know how to code.
There is a version of a developer who knows MongoDB exists, and there is a version who knows when to use a primary-secondary-secondary (p-s-s) replica set, what happens when the primary goes down, how reads and writes behave under that configuration, and what the tradeoffs are. The first person follows instructions. The second person designs systems. You want to be the second person.
Learn High Level Design. System design is not magic, it is just thinking about problems at scale. How do you make a system fault tolerant? What happens when a node dies? How do you handle 10x traffic overnight? How does your architecture behave when one service is slow? These are the questions senior engineers ask in interviews, and more importantly, they are the questions that come up every week at a real job.
Learn Low Level Design too. This is where Software Engineering Principles live. SOLID, clean code, design patterns, not because you need to memorize factory or observer for an interview, but because building something complex and feeling it break teaches you why the patterns exist. Do not learn patterns first. Build something, feel the pain, then the pattern will make sense.
If you graduated and skipped the Problem Solving phase
It is not too late. Seriously.
Make it a ritual. One LeetCode problem every morning after breakfast. Not a hard one at first. Just one. Every day. It compounds faster than you think, and it keeps your logical muscles active while you are job hunting or starting your first role. The people who do this for six months straight show up to interviews completely different from the people who crammed for two weeks.
A few things I also want you to think about
Build something real. Not a tutorial project, not a YouTube follow along. Pick a problem you actually have or one you find interesting, and build a solution for it. You will hit problems no tutorial prepared you for, and figuring those out is where the real learning happens. Recruiters can tell the difference between someone who built something and someone who cloned a repo.
Read codebases. Good engineers read a lot of code that other people wrote. Pick an open source project related to something you care about and just read through it. How is it structured? Why did they make that decision? What would you have done differently? This builds taste. Taste matters.
The job market is hard right now. You probably already know this. The way you survive it is not by learning ten frameworks, it is by going deep enough in one area that you genuinely understand it. A person who really understands distributed systems will outlast ten people who have "microservices" in their Resume but cannot explain what happens when two services write to the same database row at the same time.
Write and communicate clearly. This sounds boring but it is not. The ability to explain a technical decision in a way a non technical person can follow is rare, and it matters enormously once you are in a team. Practice it.
Finally, do not compare your timeline to someone else's. Someone in your batch got a job at a good company. Good for them. Someone else is still figuring it out. That is fine too. The engineers I have seen grow the fastest are the ones who stay curious and stay consistent, not the ones who had the best start.
You have more time than you feel like you do. Use it well.
Feel free to share this around. And if you want to talk through anything specific, you know where to find me.
Top comments (2)
Thank you so much vaiya
Amazing