Before joining NTT DATA, most of my software development experience had been closer to application development.
I enjoyed building things that I could see and interact with. APIs, web applications, interfaces, and features. My time at NTT DATA introduced me to a different side of software engineering.
From March to September 2025, I worked as a Data Engineer Intern, spending much of my time working with databases, stored procedures, SQL queries, and reporting pipelines.
It was a different kind of engineering from what I was used to, and that was exactly what made it interesting.
Looking Beyond the Application
One of the first things I learned was that a lot of the work behind an application isn’t visible from the application itself.
A user might see a report, a dashboard, or a number on a screen.
Behind that number could be a collection of database tables, stored procedures, transformations, and queries working together to produce the final result.
Working with those systems changed the way I thought about software. I started looking beyond the interface and asking where the data came from, how it was transformed, and what happened before it reached the application.
Sometimes the most important part of a feature isn’t the code that displays the result. It’s the data pipeline underneath it.
Moving Between Databases
One of the main projects I worked on was migrating more than 100 stored procedures from SQL Server to PostgreSQL.
On paper, migration sounds like moving code from one place to another. In practice, it requires understanding what that code is actually doing.
Different database systems have different behaviors, syntax, and capabilities. A stored procedure that works in one environment doesn’t necessarily translate directly into another.
That meant I couldn’t treat the migration as a simple search-and-replace exercise. I had to understand the logic behind the procedures, consider compatibility, and make sure the resulting implementation continued to produce consistent data.
This was probably one of the most useful lessons from the experience, before changing something, understand why it exists.
When working with an existing system, there is usually context behind the code. Understanding that context makes it much easier to change the system without accidentally changing what it means.
The Difference a Query Can Make
Another part of my work involved optimizing complex SQL queries and reporting pipelines.
One of the results was reducing execution time from around 60 seconds to 20 seconds.
Database performance can sometimes feel less intuitive than application performance. There isn’t always an obvious piece of code that needs to be changed. You have to think about how data is accessed, how tables are joined, how much information is being processed, and how the database executes the query.
That process taught me to slow down and investigate before trying to optimize. Instead of asking, “How can I make this faster?” I learned to ask, “Why is this taking this long in the first place?”
That small change in thinking made optimization feel less like guessing and more like problem solving.
Learning From Systems I Didn’t Build
Another thing I appreciated about the experience was working with systems that existed before I arrived.
As a developer, it’s easy to become comfortable when you’re building something from scratch. You already know why the architecture looks the way it does because you designed it.
Existing systems are different. There are conventions you didn’t choose, decisions you didn’t make, and code written by people you may never meet. Working with those systems taught me to become more comfortable reading before writing.
Sometimes the best way to contribute isn’t to immediately change something. It’s to understand the system well enough that the change you eventually make fits naturally into it.
That mindset has stayed with me in the projects I’ve worked on since then.
Finding Another Side of Engineering
My experience at NTT DATA also helped me understand that I enjoy working across different layers of software.
Before that experience, I mostly thought of databases as something that applications interacted with.
After spending months working directly with SQL and data pipelines, I started seeing databases as an important part of the system itself.
That perspective became useful later when I worked on backend services and automation systems. Thinking about data structures, queries, and system boundaries became something I could carry with me into other areas of engineering.
Looking back, the experience connected two parts of my interests that I hadn’t fully connected before, building applications and understanding the systems underneath them.
Looking Back
NTT DATA wasn’t just an opportunity to learn SQL or work with PostgreSQL.
It taught me to be more curious about what happens underneath the software.
I learned that a database migration is as much about understanding existing behavior as it is about changing technology. I learned that performance improvements often start with asking better questions. And I learned that working on software you didn’t build can teach you a lot about engineering judgment.
Those lessons became another piece of my journey as an engineer.
Since then, I’ve continued exploring different parts of software development, from fullstack applications to backend services, automation, and cloud infrastructure.