DEV Community

Cover image for What I Learned in Tech: From Student to Full-Time Software Developer - Part 2/3
Arnav Sharma
Arnav Sharma

Posted on

What I Learned in Tech: From Student to Full-Time Software Developer - Part 2/3

đź’Ľ From Code Labs to Code Reviews: My Internship at Scaler

After spending college building passion projects and winning a hackathon or two, I thought I was ready for the big leagues. But then came my internship at Scaler—and reality hit harder than a failed CI build on Friday evening.


🚀 Missed Part 1?
Check out Part 1 – My College Coding Chronicles to see how it all began.


🔍 First Lesson: Confidence ≠ Preparation

The internship kicked off with a 1-month training phase. We were given a choice between frontend and backend. Riding high on confidence and caffeine, I picked backend.

Then came the twist:

“You’ll be working with Ruby on Rails.”

Me: “Cool... wait, Ruby does... what now?”

And just like that, I was dropped into a massive monolithic Rails codebase, filled with more magic methods and callback chains than I’d ever seen. The SQL queries were longer than my resume, and folder names like concerns and services felt like riddles from the backend gods.

I had built full-stack MERN apps before, but this was the first time I stared at production code and thought:

“Oh… so this is what real-life dev work looks like.”

Nights were spent Googling before_action, strong_params, and praying to Stack Overflow when my params[:id] mysteriously vanished. It was rough. But also? Incredibly humbling.


🧱 Starting Small — Earning Trust One PR at a Time

After training, I joined the Topics Team. My initial tasks were humble:

  • Fixing sort logic
  • Tweaking query params
  • Adding tiny enhancements here and there

The real eye-opener? Code reviews.

My first PR worked—but my lead reminded me:

“It’s not about making it work. It’s about making it clean, scalable, and easy to maintain.”

Oof. That hit hard—but it stuck.

Eventually, I was trusted with my first major task: revamping a listing API to a new version. With ChatGPT’s help and a whole lot of trial-and-error, I made it work. But the real battle began during the PR review.

Every line was questioned:

  • “Why this method?”
  • “What about this edge case?”
  • “Will this hold if we scale to 10x users?”

That’s when I realized: building features is easy. Defending them? That’s where real engineering begins.


đź§© System Design & Cross-Team Chaos

A few months in, I got my biggest challenge yet:

Add MCQ-based questions to articles.

Not only did I need to design the feature from scratch, but half the ownership belonged to another team.

Suddenly, I was doing more than coding:

  • Aligning timelines
  • Managing handoffs
  • Writing design docs
  • Sending those awkward “Hey, any update on your PR?” Slack messages

That’s when I realized: software engineering isn’t just code—it’s communication, planning, and unblocking people (and yourself) daily.

By the end of that task, I had found my rhythm.

  • I was asking better questions
  • I started contributing in product meetings
  • I learned to push back on weird logic
  • And most importantly, I began owning features from design to deployment

đź§  What the Internship Taught Me

âś… Wins:

  • Pushed real features to production
  • Learned from seasoned mentors
  • Wrote cleaner, more scalable code
  • Gained confidence navigating large codebases

đźš§ Struggles:

  • Battled imposter syndrome almost daily
  • Debugged cryptic legacy code
  • Fought merge conflicts (the real boss level)
  • Survived CI/CD failures and naming conventions that felt like inside jokes

đź’ˇ The Big Takeaways

  • Clean code matters – Not just for aesthetics, but because real people rely on it.]
  • Collaboration beats solo hustle – You’re not coding in a vacuum.
  • Communication is everything – Being able to explain your why is as important as the how.

My internship didn’t just sharpen my coding skills—it transformed how I think about software, teamwork, and ownership.

So if you're a student stepping into your first real-world dev experience, here’s my advice:

Be curious. Ask dumb questions. Learn from every PR. And don’t panic when params[:id] returns nil.


đź§­ Ready for the final chapter?
Read Part 3 – My Full-Time Developer Journey: From Intern to Ownership to see how I handled layoffs, earned trust, and took full ownership of real-world products at scale.

Top comments (0)