When I joined UBS for a 6-month internship, I thought I knew my stuff. I’d done a few projects, written some production code—but real engineering? That was still to come.
Over the next six months, I worked on the Strategic Proposal Tool, a large-scale internal platform that helps financial advisors create investment proposals for HNIs and UHNIs. This is the story of what I built, what broke, and what I’ll never forget.
🏗 The Context: Internship + Stack
Before this internship, I had:
- A basic Node.js internship at a small startup, working on their ecommerce platform.
- A summer internship with the same UBS team, working on a different application migrating it from Java 8 to Java 17, also implementing some new features.
This 6-month stint gave me the opportunity to move beyond beginner-level projects and contribute to core systems.
Tech stack I worked with:
- Java (Spring Boot)
- React
- PostgreSQL
- GitLab CI/CD
- Azure Kubernetes
🔧 Projects I Worked On
1. Admin Banners
Dynamic notifications (like outages or feature rollouts) for FAs logging into the system. I worked on backend logic for role-based visibility and real-time display rules. Also worked on admin API to manage the banners.
2. Morningstar API Integration
Integrated Morningstar’s external API to fetch live investment instrument data, including mapping, error handling, and security.
3. Backend from Scratch
We were building a new system—not just patching legacy code. I helped define DB schemas, API flows, and adapted as requirements evolved over time.
⚠️ From 33 Seconds to 2.75: One Bug That Taught Me Backend Maturity
During load testing, a metrics API I had built performed well under development conditions, but under load it hit 33 seconds—far exceeding the acceptable limit of 5 seconds.
I traced it to redundant queries, missing indexes, and a few architectural changes introduced after my initial implementation.
Fixes I applied:
- Introduced hashing to reduce repeated computation
- Indexed key DB columns
- Consolidated data retrieval across endpoints
Final result? We brought it down to 2.75 seconds.
That one bug forced me to revisit how I thought about system design, clean code, and performance tradeoffs. Here’s what it taught me technically…
🧠 Key Technical Takeaways
- Read the System First: Understanding flows end-to-end made my development faster and more accurate.
- Feign Clients: For cleaner internal HTTP service calls use feign clients as it abstracts the HTTP call implementation.
-
Three-Layer Architecture:
-
Facade Layer: handles interactions with the UI -
Business Layer: core business logic, interacts with other business services -
Data Layer: isolated DB schema responsibilities
-
🤝 Communication Is Everything
I learned quickly that technical skills aren’t enough.
- Clear communication avoids bugs introduced through assumptions.
- Stakeholder questioning uncovers edge cases you won’t find in GitLab tickets.
- Agile workflows sometimes deliver magic, other times just fragments—know when to speak up and when to flex.
😓 One Mistake I Won’t Repeat
That performance bug? I wish I’d spent more time analyzing how the system worked and profiling early.
Now, I start by:
- Reading similar flows
- Understanding performance implications
- Testing early, not late
💬 Advice to Backend Interns
- Learn your fundamentals: Auth flows, backend layering, and microservices communication.
- Explore beyond your GitLab board: Use quiet sprints to pair with seniors, refactor small pieces, or research upcoming stack changes.
- Don’t code blind: Read the existing APIs and logic. Learn how the system breathes before you change it.
💬 Over to You
Internships are bridges—between theory and practice, between coding and designing.
They’re also one of the fastest ways to level up as an engineer—if you’re curious and intentional.
What was your biggest lesson from your first real backend project?
I’d love to hear it 👇
Top comments (0)