I was casually talking with one of my seniors when I found out that his younger brother—who is also my junior—had just started his first year of Computer Science.

My first reaction was basically:

Great. Computer Science, first year. And he already has an elder brother from the same field.

That’s a massive advantage.

It reminded me of all the free gyaan I had always imagined giving to my own younger sibling if they ever chose CS. Unfortunately for me, my sister liked biology too much, and the others aren’t eligible for this lecture yet.

So I started typing something for my senior’s younger brother.

And then, as usual, I couldn’t stop.

What started as a few pieces of advice became DSA, projects, AI, college, placements, referrals, GATE, hackathons, networking, low-level programming, career bets and basically everything I wish someone had sat me down and explained when I entered engineering.

At that point I thought: why send this to just one person?

So this is for him, but also for every student who has just entered Computer Science and is looking at four years ahead wondering:

What the hell am I actually supposed to do with these four years?

I graduated in 2025.

My placement journey wasn’t particularly glamorous. I screwed up parts of it, graduated into a much worse hiring market than the one I entered college expecting, spent some time around a coaching environment partly because I wanted access to a stronger referral network, watched the job market mess with my mental state, and eventually landed my current opportunity with some help from referrals.

Today I work at a startup where I’m exposed to AI, agentic workflows, software engineering and enterprise systems, including work around large US businesses.

That doesn’t make me an expert.

And another disclaimer before somebody assumes otherwise: I don’t earn one of those ₹20–50 LPA packages that dominate your LinkedIn feed.

I earn a normal salary that lets me support my needs, save for the future and contribute to my family.

That’s enough credibility for what this article is supposed to be.

I’m not selling you a dream.

I’m simply sharing what I would tell my younger brother.

Take whatever makes sense.

Reject whatever doesn’t.

And don’t blindly follow anyone’s roadmap—not even mine.

Don’t Let AI Make You a Worse Programmer

This will probably be the most controversial thing I say here.

If you’re just starting programming, don’t become dependent on AI before you’ve developed some basic programming ability yourself.

I’m not saying don’t use ChatGPT, Claude, Copilot or whatever comes next.

I use AI all the time now.

The difference is that there is a huge gap between:

using AI to multiply your ability

and

using AI because you don’t have the ability yet.

When you’re beginning, spend some time doing things the hard way.

Write code yourself.

Get stuck.

Read documentation.

Google weird errors.

Spend two hours debugging something that turns out to be a missing bracket.

Try to understand why your solution works instead of only caring that it works.

It feels inefficient.

It isn’t.

You’re building the mental model that will later allow you to use AI properly.

At work today, AI can generate a surprising amount of code for me. But the useful skill isn’t pressing Enter after writing a prompt.

The useful skill is being able to look at what it generated and ask:

Why this approach?

Why not something simpler?

What’s the trade-off?

What breaks at scale?

Is this query terrible?

Does this architecture even make sense?

Did the model just confidently invent something?

If you don’t understand the underlying system, you cannot have that conversation.

Then AI isn’t your assistant.

You’re its assistant.

Don’t let that happen.

Should First-Year CS Students Learn DSA? Yes, but Don’t Worship It

If possible, get reasonably comfortable with Data Structures and Algorithms during your first year.

Not because your entire career is LeetCode.

And not because you need to become some competitive programming monster solving five questions before breakfast.

DSA gives you something more useful than interview preparation:

it teaches you how to think about code.

Arrays, strings, hash maps, stacks, queues, recursion, trees, graphs, time complexity, space complexity and common problem-solving patterns eventually start becoming part of your intuition.

I realised later that my DSA preparation also made debugging easier.

When AI writes code now, I’m much more comfortable tracing what it’s doing, figuring out where the logic is wrong and modifying it instead of treating generated code like magic.

There is another part I wish I had handled better:

don’t completely stop practising once you’ve learned the basics.

Programming ability behaves a little like a sport.

You don’t have to grind DSA every day for four years.

But once you’ve built the muscle, keep it alive.

Maybe you solve a couple of problems every week.

Later, maybe every few weeks.

Whatever works.

College has an amazing ability to fill your schedule with things while somehow making you forget the things that actually matter.

Don’t let your fundamentals disappear.

Pick One Tech Stack and Stop Running Behind Everything

This industry is designed to make students feel behind.

Every week there’s a new JavaScript framework.

Every month somebody declares another language dead.

Every few months a new AI tool appears and suddenly half of Twitter behaves like nobody needs programmers anymore.

Ignore most of the noise.

Pick one useful stack.

Learn it properly.

Build with it.

If you choose web development, become comfortable building actual web applications.

If you like backend development, learn one backend ecosystem well.

If mobile development interests you, go there.

If you’re interested in data engineering, systems, ML or something else, same principle.

You don’t need seventeen technologies listed on your resume.

And especially if you aren’t studying at a college where highly specialised companies regularly recruit, chasing every new technology usually has terrible returns.

Strong fundamentals transfer.

Framework syntax doesn’t.

Also, don’t rush through your first stack.

There is value in initially doing things the painful way.

Configure the project yourself.

Understand the folder structure.

Write the API.

Connect the database.

Deploy something.

Break something.

Fix it.

Once you’re comfortable doing that, bring AI into the process.

That’s when AI becomes extremely powerful.

You’ve already developed the muscles.

Now you’re giving those muscles steroids.

Build Projects, but Don’t Stop at Tutorial Projects

“Build projects” is probably the most repeated advice in Computer Science.

It’s correct.

But incomplete.

Your first few projects will probably be terrible.

That’s fine.

Build them anyway.

Build something without AI first.

Then build something larger with AI.

Try something slightly outside your comfort zone.

But eventually, stop only creating projects from scratch.

One thing I strongly recommend is this:

Find a decent GitHub repository built using your stack.

Clone it.

Try to run it locally.

Understand it.

Setting up somebody else’s real project can sometimes teach you more than building your tenth CRUD application.

You start encountering decisions you never had to make yourself.

Why is the repository structured this way?

Why does this configuration exist?

Where does authentication happen?

How are database migrations handled?

Where are tests?

Why did they create this abstraction?

How do different services communicate?

You might spend an entire evening just getting the damn thing running.

That’s okay.

Then look through the issues.

Find something small.

A documentation improvement.

A tiny bug.

A test.

A minor feature.

Try contributing.

You don’t need to become a famous open-source developer.

The objective is to get comfortable entering a codebase you didn’t create.

Because that’s exactly what happens when you get a job.

Nobody hires you, opens an empty VS Code window and says:

“Congratulations. Build our company from scratch.”

You inherit systems.

Learning how to understand them is a skill.

Learn in Public Without Becoming a LinkedIn Influencer

Create a LinkedIn account.

Use Twitter/X if you enjoy it.

Follow engineers who genuinely know things.

Follow people working in fields you’re interested in.

Read engineering blogs.

Watch how experienced developers think about problems.

And occasionally, share what you’re learning.

Not every post needs to begin with:

“I’m thrilled to announce…”

You don’t have to turn your life into content.

Just document useful things.

You spent six hours fixing something weird?

Write about what happened.

You finally understood database indexes?

Explain them simply.

Built something interesting?

Share it.

Read an interesting engineering paper?

Write down what you understood.

Writing forces you to organise your thoughts.

And eventually, there is a second benefit.

You leave behind evidence that you genuinely care about technology.

That’s much more interesting than a resume containing fifteen buzzwords.

Don’t Ignore Databases, SQL, Networking, Cloud, Memory and Caching

These subjects don’t always look exciting when you’re a student.

Then you start working.

Suddenly they’re everywhere.

At my current startup, writing code itself isn’t always the difficult part anymore.

AI can produce plenty of code.

The interesting discussions are increasingly around questions like:

Should this data be cached?

Where should we cache it?

How long should it live?

What happens when this service goes down?

Are we making too many database calls?

Is SQL enough here?

What are the consistency requirements?

How much memory does this approach consume?

Should this even be another microservice?

Why did Claude suggest this architecture?

And most importantly:

Why should we trust that suggestion?

This is where those supposedly boring subjects start becoming useful.

Learn databases.

Learn SQL properly.

Understand basic networking.

Understand memory.

Learn what caching actually does.

Understand APIs.

Learn enough cloud to deploy things yourself.

Eventually understand queues, distributed systems and system design.

You don’t need mastery in first year.

Just don’t develop the mindset that anything outside your favourite framework is irrelevant.

Frameworks change.

Fundamentals keep coming back wearing different clothes.

Start Applying Before You Feel Ready

One of the easiest traps to fall into is endlessly preparing to start. Which also trapped me.

“I’ll apply once I finish DSA.”

“I’ll apply after one more project.”

“I’ll apply next semester.”

“My resume isn’t ready yet.”

Apply anyway.

If your college announces something, apply.

If you see an internship, apply.

If a senior forwards an opening, apply.

If somebody’s company is hiring, ask.

If your brother’s friend’s company has a role, ask about it.

The hiring process itself is training.

You learn how resumes are filtered.

You experience online assessments.

You understand interview pressure.

You discover which topics you thought you knew but actually didn’t.

You learn how companies evaluate people.

Worst case, they reject you.

That was already the outcome before you applied.

College Placements Are Not Always Fair — Don’t Be Naive About It

I’m going to say something uncomfortable here.

College placement systems aren’t always perfect meritocracies.

During my placement journey, I saw situations where students who genuinely knew their stuff lost opportunities while people who were gaming assessments moved ahead.

That is frustrating.

Especially when you know you’re capable of being somewhere near the top, yet an imperfect online assessment puts you near the bottom.

It hurts even more when somebody who has barely written code gets through.

But don’t misunderstand my point.

I’m not telling you to cheat.

I’m telling you not to be naive about how imperfect systems work.

Use every legitimate advantage available to you.

Previous interview experiences.

Seniors.

Alumni.

Referrals.

Mock interviews.

Placement groups.

Company-specific preparation.

Faculty guidance.

Information about interview patterns.

Networking.

The world isn’t going to award extra points because you deliberately made things harder for yourself.

Play competitively without becoming dishonest.

One OA isn’t your entire career anyway.

Your Elder Sibling or Senior in Tech Is an Unfair Advantage — Use It

This is especially important because this entire article started with my senior’s younger brother.

If your elder brother, sister, cousin or a close senior already works in technology, you have something incredibly valuable:

compressed experience.

Ask questions.

Ask stupid questions.

Ask things you think you “should already know.”

Ask them what mistakes they made.

Ask how their placements worked.

Ask which companies are hiring.

Ask what technologies their team actually uses.

Ask them to destroy your resume.

Ask them to conduct a mock interview.

Ask what they would learn if they were starting college again.

I’ve seen sibling pairs where the younger one is strangely hesitant to ask the older one questions.

Maybe they think they’ll be made fun of.

They probably will make fun of you.

That’s what elder brothers are for.

Ask anyway.

Your sibling might have four or five years of experience that you can access through a twenty-minute conversation.

That’s absurd leverage.

And their network matters too.

Their friends have jobs now.

Those friends work at different companies.

Those companies hire interns and freshers.

Somebody may know somebody who can refer you.

Be respectful, obviously.

But don’t be unnecessarily shy.

You don’t get an award for discovering everything alone.

And this applies to my advice too.

Don’t blindly follow some random YouTuber.

Don’t blindly follow your senior.

Don’t blindly follow me.

Understand yourself.

Take input from people who know you.

Then make your own decision.

Don’t Ignore College Exams — but Don’t Make CGPA Your Entire Personality

College has its own game.

Different universities and autonomous colleges work differently, so I’m not going to pretend my exact experience applies everywhere.

But stay informed.

Talk to seniors.

Understand your exam pattern.

Know which subjects usually create trouble.

Understand how internal marking works.

Pay attention to what faculty emphasise.

If professors themselves highlight important areas or provide likely topics, use that information.

That’s not cheating.

That’s preparation.

At the same time, don’t become so obsessed with optimising every internal mark that four years disappear and the only thing you’ve built is a high pointer.

CGPA matters.

Especially because some companies use cut-offs.

But there is a difference between caring about academics and allowing academics to consume your entire engineering experience.

Try to leave college with both:

a respectable academic record and actual engineering ability.

Make Real Friends and Build Real Connections

Networking sounds disgusting when you’re 18 because people make it sound transactional.

It doesn’t have to be.

Some of the most useful connections you make in college will simply be people you genuinely enjoyed building things with.

Your network can be classmates.

Seniors.

Juniors.

Hackathon teammates.

Club members.

People from completely different colleges.

Someone you randomly met at an event.

The important thing is finding people who help you grow instead of constantly becoming blockers.

Go to hackathons.

Spend some nights building stupid things.

Try corporate-sponsored competitions.

Join technical clubs if they’re actually doing something useful.

I didn’t get to participate in hackathons as extensively as I wish I had.

But the ones I attended taught me something valuable:

how to build something that works when you don’t have enough time.

College assignments often teach you how to finish an assignment.

Hackathons can teach you how to ship.

That difference mattered later in my own career.

Most of my earlier projects were around Data Science and Machine Learning.

My current startup’s work is closer to agentic workflows and enterprise revenue-management problems.

That isn’t a perfect match.

But during the interview process I built a prototype in roughly one night to demonstrate that I could understand the problem and make something work.

That helped me land the role.

Your old projects don’t need to perfectly match your future job.

Sometimes the important signal is simply:

Can this person learn quickly and build?

A Risky Career Bet: Learn Something Closer to the Machine

Now we reach the speculative part.

Do not treat this section as guaranteed career advice.

This is simply one of my current bets.

Once you’ve learned enough of a job-ready stack that you can realistically apply for internships and jobs, I think spending some free time learning lower-level systems could be valuable.

C.

C++.

Rust.

Operating systems.

Networking.

Compilers.

Embedded systems.

Performance engineering.

Robotics.

Software interacting with hardware.

You don’t need to do all of them.

Pick whatever genuinely interests you.

Why do I think this might matter?

Because software engineering is changing very quickly.

When I entered college, the market looked very different from the one I graduated into in 2025.

Hiring was stronger.

Freshers were being hired in much larger numbers.

By the time my batch graduated, simply knowing how to make another basic CRUD application wasn’t enough to make someone particularly interesting.

Now AI is changing the equation again.

I think AI will significantly reduce the amount of human effort required to build many categories of ordinary consumer and business software.

Does that mean software developers disappear in five years?

I don’t know.

Ten years?

Still don’t know.

Anyone giving you an exact timeline is guessing.

But I do think fewer people may eventually be able to build what previously required much larger teams.

That makes me interested in areas where software meets harder constraints: infrastructure, hardware, robotics, networking, performance, security, complex enterprise systems and other areas where understanding what’s happening underneath the abstraction matters.

Again:

This is a bet.

Don’t abandon employability today because of somebody’s prediction about 2035.

Build your foundation.

Get job-ready.

Then use some free time to make asymmetric bets on the future.

Four years is a long time in technology.

You have no idea what the industry will look like when you graduate.

Neither do I.

Should You Choose Data Science or Machine Learning?

I spent a lot of my college time around Data Science and ML, so I’m definitely not against it.

But today I would tell a first-year student to choose it consciously.

Don’t pick ML because “AI is the future.”

Serious Machine Learning involves much more than importing a Python library or calling an API.

Mathematics matters.

Statistics matters.

Data matters.

Experimentation matters.

Understanding models matters.

And depending on the market, entry-level opportunities can be narrower than students expect.

If you genuinely enjoy it, go for it.

Risky bets are completely fine.

Just know you’re making one.

Thinking About GATE? Don’t Wait Until Final Year to Think About It

I never seriously gave GATE myself, so I’m not going to pretend I have first-hand authority here.

But I once considered preparing for it during a period when my job situation wasn’t going particularly well.

I spoke with a senior who had cracked a double-digit GATE rank and later went on to MIT in the US and interned at Netflix.

His advice stuck with me.

If GATE is genuinely part of your plan, first and second year are extremely valuable.

You have time.

You can build the theoretical foundations properly.

And you potentially get multiple serious attempts.

Starting from almost zero in final year and expecting yourself to reach an IIT-level score within a few months is a very different challenge.

Especially if you spent the previous three years preparing exclusively for software jobs.

His broader point was also sensible:

If you’re going to put yourself through something as theoretically demanding as GATE specifically for M.Tech, aim for an outcome good enough to justify that effort.

So you don’t have to start coaching on Day 1.

But if GATE is somewhere in your long-term plan, understand what the exam requires early.

Don’t discover the syllabus when college is almost over.

What Resources Should a First-Year CS Student Use?

You probably need far fewer resources than YouTube wants you to believe.

The internet has created a strange problem.

People now have:

twenty playlists,

seven Udemy courses,

four roadmaps,

three Discord servers,

fifty bookmarked articles,

and zero finished projects.

Pick something and finish it.

For web development, I personally like Hitesh Choudhary and Chai aur Code. His structured cohorts can also make sense for someone who learns better with that kind of environment.

freeCodeCamp is still ridiculously useful for a huge range of technologies.

Beyond that, documentation becomes increasingly important.

And once you understand the basics, AI itself becomes one of the best learning partners available—as long as you keep questioning it instead of blindly copying it.

For most technologies you do not need twenty courses.

You need one good starting point, documentation, projects, curiosity and enough stubbornness to keep going when things break.

Referrals Are Not Cheating

This deserves its own section because students sometimes develop a weird pride around this.

Suppose your brother’s friend works at a company where there’s an opening.

Ask.

Suppose a senior works somewhere you’re interested in.

Talk to them.

Suppose somebody can refer you.

Take the referral.

Some people behave like getting a referral somehow makes the achievement less legitimate.

It doesn’t.

A referral can get your resume looked at.

It cannot make you competent after you’re hired.

Nobody cares five years later whether you discovered the job opening by randomly refreshing LinkedIn or because your senior told you about it.

They care whether you became capable.

Whether your team can rely on you.

Whether you can solve problems.

Whether you can support yourself.

Whether you can support your family.

Be shameless about asking for opportunities, not shameless about demanding them.

There’s a difference.

Respect people’s time.

Don’t message strangers with:

“Hi sir referral please.”

Build relationships.

Show that you’ve put in effort.

Make it easy for somebody to help you.

Then ask.

The Market You Graduate Into May Be Completely Different

This is probably the most important thing I learned from my own batch.

When we started engineering, we saw the market from the perspective of the seniors graduating at that time.

Things looked great.

Companies were hiring aggressively.

Freshers were receiving strong packages.

There was a sense that if you learned a standard development stack and did decent DSA, things would somehow work out.

Four years later, the situation was very different.

That’s the danger of designing your entire career around today’s market.

A first-year CS student entering college now will graduate several years from now.

Think about how much software changed between 2020 and 2025.

Now imagine predicting the next four years perfectly.

You can’t.

That’s why fundamentals matter.

That’s why learning how to learn matters.

That’s why I care so much about understanding systems instead of memorising frameworks.

Your goal shouldn’t be becoming the perfect candidate for today’s job description.

Your goal should be becoming somebody who can still adapt when that job description changes.

If I Were Starting Computer Science Again

If somebody somehow sent me back to first year, I wouldn’t try to learn everything.

I’d learn programming properly.

I’d build a decent DSA foundation early.

I’d choose one stack and go deep enough to become employable.

I’d build projects manually before becoming dependent on AI.

Then I’d use AI aggressively.

I’d read other people’s code.

I’d contribute to a few real repositories.

I’d learn SQL properly.

I’d pay more attention to databases, networking, operating systems, memory, cloud and caching.

I’d go to more hackathons.

I’d write more about what I learned.

I’d talk to more seniors.

I’d start applying earlier.

I’d ask for referrals without feeling awkward.

I’d keep college grades respectable without making CGPA my personality.

I’d build friendships with people who were genuinely curious and ambitious.

And after becoming job-ready, I’d spend some time exploring lower-level engineering or another slightly risky long-term bet.

Most importantly, I’d stop worrying about whether I was following the perfect roadmap.

There isn’t one.

One Last Thing for Anyone Lucky Enough to Have a Senior in the Same Field

This article exists because of one younger brother.

So I’ll end where it started.

If your sibling or senior has already gone through this journey, use them.

Please ask every fucking question.

Seriously.

Don’t sit quietly because you think the question is stupid.

Don’t think your elder brother will make fun of you.

He might.

Ask anyway.

Talk to his friends.

Connect with them on LinkedIn.

See where they work.

Understand what their companies hire for.

Ask what mistakes they made.

Ask what opportunities exist.

Learn from years of experience you didn’t personally have to suffer through.

That’s one of the biggest advantages you can have.

I didn’t enter engineering with much exposure to people from my own family already working in IT.

If you do have that exposure, don’t waste it.

But don’t become dependent on it either.

Use other people’s experience to accelerate your own thinking.

Then build your own capability.

Because ultimately, a referral might get you the interview.

A senior might tell you what to study.

AI might help you write the code.

A friend might tell you about the opportunity.

But eventually, you’re the one who has to sit in the chair and perform.

Final Thoughts

Computer Science is still an incredible field to enter.

But I don’t think the next four years will reward people who simply follow tutorials, memorise a tech stack and wait for campus placements to save them.

Build strong fundamentals.

Learn how computers actually work.

Become good at one useful thing.

Experiment with other things.

Use AI without surrendering your brain to it.

Apply before you feel completely ready.

Ask for help.

Give help when you’re eventually in a position to do so.

Make friends.

Go outside your classroom.

Build stupid projects.

Build serious projects.

Break production-like systems on your own laptop.

Stay curious about things you don’t understand.

Take a few calculated risks.

And enjoy college too.

You only get those four years once.

Technology will change.

Frameworks will change.

Hiring markets will change.

AI will change.

Your plans will definitely change.

The best thing you can build during your Computer Science degree isn’t one perfect project, one perfect resume or one perfect LeetCode streak.

It’s the ability to encounter something you don’t understand and confidently say:

“Give me some time. I’ll figure it out.”

If you leave college with that ability, you’ll be fine.

All the best for the journey.

And to the younger brother who accidentally caused me to write this entire thing:

Use your senior.

You have no idea how valuable that advantage is.