Three Months as a Backend Intern: What I Shipped and What I'd Do Differently

The jump into a production codebase

In mid-2023 I joined Shangrila Microsystem in Kathmandu as a Backend Developer Intern for three months. It was my first time inside a real production codebase rather than a project I'd started from an empty folder — and the difference is bigger than it sounds. The code was already there, other people depended on it, and "I'll just rewrite it" was not an option.

Here's what I actually worked on, and what I'd approach differently now.

What I shipped

My work was backend-focused, mostly in PHP and Laravel:

• RESTful APIs to serve data to the front end — designing endpoints, validating input, and returning consistent response shapes the client could rely on.
• Database work — designing schemas and optimising SQL queries. One slow listing page came down noticeably once the underlying query was rewritten and the right columns were indexed.
• Authentication and authorisation — implementing the access-control layer that decided which users could reach which resources before a feature went to production.

None of these were huge features on their own, but they were real, reviewed, and merged into something people used.

The lessons that didn't come from a lecture

Code review is where you actually improve. My first pull requests came back with comments — naming, structure, edge cases I'd missed. That feedback loop taught me more in three months than I'd expected, because it was specific to code I'd written and someone more experienced had to read.

Slow queries are a design problem, not a mystery. University taught me normalisation in the abstract. Watching a page hang because of an unindexed join taught me why it matters. The fix was rarely clever — it was usually a missing index or a query doing work it didn't need to.

Security is a default, not a final step. Bolting auth on at the end is how you ship holes. Deciding who can access what as you design the endpoint is far less painful than retrofitting it.

Asking precise questions saves everyone time. "It doesn't work" wastes a senior developer's afternoon. "This endpoint returns a 500 when the payload is missing user_id — should it validate or default?" gets you an answer in two minutes.

What I'd do differently

Looking back with a bit more experience:

• Write tests as I go. I leaned on manual checking. A few focused tests around the API contracts would have caught regressions earlier and made me less nervous about changes.
• Read the existing code before adding to it. I was quick to start writing. Time spent understanding the patterns already in the codebase would have saved me rework and review rounds.
• Document the why, not just the what. A one-line comment on a non-obvious decision is worth more than a paragraph restating what the code already says.

Where it left me

The internship was the bridge between knowing the concepts and applying them under real constraints — a shared codebase, a team's standards, and production users on the other end. It confirmed that backend work, where the data and logic live, is the part I enjoy most. The habits I picked up there — reviewing carefully, treating performance and security as design concerns, and asking good questions — are the ones I've carried into every project since.