Career4 min read
3 Internships, 3 Different Worlds
Web development → IoT → Data engineering. Each one broke my assumptions about what "real engineering" looks like. Here's what I actually learned from refusing to specialize too early and why the pinball path was the best decision I could have made.
- Published
- Author
- Aditya Patel
- Length
- 886 words
I've had three internships across three years, and none of them were in the same field. Web development at a startup. IoT engineering at a tech company. Data engineering at a fintech firm. If you mapped my career trajectory on a graph, it would look less like a straight line and more like a pinball machine.
People told me this was a problem. That I should "pick a lane." That employers want a consistent narrative.
I think they were wrong. Here's what I actually learned from refusing to specialize too early.
Internship 1: The Marketplace (Web Dev at Appuno)
My first internship was at Appuno IT Solutions in 2022, building features for an investor marketplace platform. ASP.NET MVC, C#, SQL Server, Bootstrap. Classic full-stack web development.
I arrived knowing how to write code. I left knowing how to build software. Those are very different things.
The biggest lesson wasn't technical it was understanding that the codebase I was working in wasn't mine. It belonged to a team, to a product, to users who would encounter my work without ever knowing my name. I learned to read someone else's code before writing my own. I learned that a clean API is an act of kindness to the next developer. I learned that "it works on my machine" is the beginning of a problem, not the end of one.
The technical skills (REST APIs, role-based access control, responsive layouts) were valuable. But the meta-skill — thinking about code as a shared artifact was transformational.
Internship 2: The Hardware (IoT at Intuz)
In 2023, I interned at Intuz Solution, building a Smart Home Energy Management System. Arduino, Raspberry Pi, sensor integration, real-time dashboards. Completely different from web dev.
The first time a sensor reading came back wrong, I assumed it was a software bug. I spent two hours debugging my code before someone pointed out that the wire connecting the sensor to the Arduino was loose.
That moment rewired my brain. In software, when something doesn't work, the problem is always in the code. In hardware, the problem might be the code, the wiring, the power supply, electromagnetic interference, a faulty component, or the fact that you soldered something at the wrong angle. The debugging space is enormous.
Working with hardware taught me to question my assumptions about where bugs live. That skill transferred directly to debugging distributed systems later because in distributed systems, the problem is also rarely where you think it is.
The SHEMS project also taught me about real-time constraints. In web development, a 200ms response time is fast. In an IoT system reading energy data, a 200ms delay means your dashboard is showing stale information. Latency isn't just a number it changes what your system is capable of.
Internship 3: The Pipeline (Data Engineering at Intellect Design Arena)
My third internship, in 2025, was at Intellect Design Arena, building an ETL pipeline for AMFI mutual fund regulatory data. Apache Airflow, Python, PostgreSQL, Power BI.
No user interface. No hardware. Just data flowing from point A to point B, being transformed along the way, and arriving at point C in a format that stakeholders could actually use.
It sounds boring. It was the most satisfying internship I've had.
The reason is that data engineering forces you to think about reliability. A web app can crash and you restart it. An IoT sensor can glitch and you recalibrate. But if your ETL pipeline silently corrupts data, every analysis built on top of that data is wrong and nobody knows until someone makes a bad decision based on a bad dashboard.
I built data validation checks at every stage. I set up Airflow alerts for anomalous row counts. I wrote idempotent transformations so that rerunning a failed task wouldn't duplicate data. These aren't glamorous problems, but they're the problems that determine whether your organization can trust its own numbers.
The Thread That Connects Them
Web development taught me to think about users. IoT taught me to think about physical constraints. Data engineering taught me to think about trust.
But the deeper lesson the one that only became clear in hindsight is that every engineering discipline is fundamentally about managing complexity in the face of uncertainty. The web app might get unexpected traffic. The sensor might fail. The data source might change format without warning. The specifics differ, but the mindset is the same: design for failure, test your assumptions, and never trust that things will "just work."
If I'd done three data engineering internships, I'd be a better data engineer today. But I don't think I'd be as good an engineer. Breadth gave me mental models that depth alone wouldn't have.
Advice for Other Students
If you're early in your career and feeling pressure to specialize, here's my take: specialize eventually, but not yet. Try the thing that seems unrelated to your goals. Build the project that doesn't fit neatly on your resume. The connections between fields are invisible until you've stood in multiple fields.
The student who's done web dev, IoT, and data engineering sees system design differently than the student who's only done one. Not better. Differently. And "different" is often what a team actually needs.
My pinball career path wasn't a lack of direction. It was the most useful exploration I could have done.
Continue reading