From My First Bug to a Full-Time Role at IBM

While I was doing my Bachelor’s at Dundalk Institute of Technology, in my third year, we had two options to choose from: either a work placement or an Erasmus semester abroad.

I chose the work placement because I wanted to gain practical knowledge from the industry and apply what I had learned during the previous couple of years.

I started applying for internships in the summer of 2024. And I will be honest, my inbox was full of emails saying things like “Unfortunately…” or “We are going forward with other candidates.”

But during September, I started getting a few interview calls, and one of them was from IBM.

Getting into IBM

As part of the IBM application, I had to complete two HackerRank questions. I remember making it just in time because I was stuck on the second question for almost 40 minutes.

At that time, I wasn’t very good at data structures. We were only going to properly learn them in third year. But I did have a good understanding of the projects I had worked on.

During the interview, I was asked questions about my projects, what I had learned from them, and some of the challenges I had faced. There were also some basic questions about APIs, the REST paradigm, Linux fundamentals, and the project I would be working on during my third year.

And that’s it.

I came out of the interview feeling pretty good. I was told I would hear some good news in a couple of days.

And boom.

I got an email from IBM saying that I had been successful and would be joining in January for an 8-month paid internship as a Software Developer Intern.

I was obviously very happy.

But the real learning was about to begin.

Starting my internship

When I started my internship, I was assigned to a product called IBM API Connect.

IBM API Connect is used by large enterprises to manage the lifecycle of their APIs. The product itself was huge and was divided into smaller subsystems such as Manager, Analytics, Gateway and Developer Portal.

Each subsystem was handled by a specific team, with teams spread across India, the US, the UK and Ireland.

I was placed in the Developer Portal team, which worked on the customer-facing portal used to publish and share APIs with developers.

My team consisted of two other interns and five experienced software developers. We had daily stand-ups and followed Agile Scrum practices, working in two-week sprints.

Our team was also quite new. The previous team had moved onto another product, so they had to hand over their knowledge to us within two months.

And I will be honest, it was scary.

The first few weeks

I experienced imposter syndrome first-hand.

Every single day I was hearing new words:

“The cluster stopped working.”

“The pipeline isn’t running.”

“Check the logs.”

And then there were technologies I had never even heard of before:

Docker.

Kubernetes.

Bash scripting.

Drupal.

All of these sounded like buzzwords to me.

During my third week, I was assigned a small bug.

It wasn’t anything major, but solving it gave me a lot of confidence. It was something I had taken ownership of, fixed, and eventually pushed to the GitHub repository.

For the first time, I thought:

Okay, maybe I can actually do this.

That small bug ended up being an important moment in my internship.

Learning as I went

One thing I really liked about IBM was that we weren’t expected to know everything.

We weren’t expected to know every technology or understand the entire product from day one. Our team was given courses on the technologies we were using, and as the months passed, we slowly became more familiar with the product.

Those scary buzzwords started becoming normal.

I started getting familiar with the codebase, and whenever I had questions, I asked my teammates. They were always willing to help me understand things.

I learnt how Drupal modules were written and ended up writing a couple of them myself.

I also got the opportunity to publish technical blogs on the IBM Developer website, where I wrote about keeping browser tabs in sync and a new onboarding tool for admin users.

You can read them here.

But my internship wasn’t only about writing code.

I participated in team playback meetings where, every alternate sprint, team members presented the features they had developed or shared key learnings with the rest of the team.

These sessions helped me understand what others were working on and also gave me more confidence in presenting my own work.

We also had bug bash sessions, where the entire team would spend a few hours testing recent features and looking for bugs.

I found this really useful and later carried the same practice into my final year project.

Later, I took on the role of Security Focal, where I helped triage security vulnerabilities in our codebase. This was where I started understanding different aspects of software security and got introduced to concepts such as SAST and DAST.

Things I learnt along the way

During my internship, I also participated in two hackathons.

The first was Agridrone, where my team proposed an AI-assisted drone monitoring system for agricultural farms.

The second was the Watson Challenge, where my team proposed the idea of an automatic package manager.

I also took part in a five-day Developer Academy workshop, where I learnt about cloud fundamentals, Test Driven Development and automation using CI/CD pipelines.

There were so many things I learnt during this time that I didn’t even know existed before.

I learnt about Playwright test cases and how the entire system could be mocked to thoroughly test functionality on the UI.

I saw how Jenkins pipelines could automate different steps of the development process and flag problems early.

I started understanding containers and microservices and how they can make systems more resilient.

I also learnt more about API definitions and the different stages of an API’s lifecycle.

All of these things slowly started connecting together.

The work I did

As I became more comfortable with the codebase, I started taking on bigger pieces of work.

Some of the major things I worked on were:

• Automatic session logout: handling inactive sessions across multiple browser tabs.
• JSON-based data migration: replacing PHP serialization with a JSON-based approach.
• Audit logging improvements: adding unique ID identifiers.
• Admin onboarding module: developing functionality for the admin users.

Apart from these, I also worked on bug fixing, package upgrades and many smaller issues across the product.

This was probably one of the biggest changes I noticed in myself.

I wasn’t just learning technologies anymore.

I was actually contributing to a real product.

The people

Of course, an internship isn’t only about the technical skills you gain.

The people around you make a huge difference.

Regular feedback from my manager and encouragement from my team helped me keep pushing whenever I felt stuck or unsure.

One thing I really liked about IBM was how easy it was to approach people in higher positions.

Whenever I got stuck on an issue, I could reach out to our architect, explain the problem and have a conversation about it.

It showed me that even in a large company, you can still learn directly from people with years of experience.

And outside of work, I had a great time too.

I made some really good friends. We had lunch together, played badminton, and spent time together outside work.

I also took part in a 5K marathon and played hurling for the first time.

These things weren’t directly related to software development, but they became some of my favourite memories from the internship.

From intern to part-time developer

Towards the end of my internship, our manager offered us interns the opportunity to continue working part-time during our final year of college.

I decided to take the opportunity, which extended my time working with IBM until April 2026.

Balancing college and part-time work wasn’t always easy. There were assignments, projects, exams and deadlines at college while also having work responsibilities.

But looking back, I’m really glad I did it.

It gave me even more experience working on a real product while finishing my degree.

Looking back

Looking back now, I would call it a really good experience.

It was rough at the start.

I went from barely understanding what Kubernetes or Docker were to working with them as part of a real software.

Even now, I don’t have in-depth knowledge of every repository or every part of IBM API Connect.

And I don’t think I’m supposed to.

What I learnt is something much more important.

I learnt what to do when I get stuck.

I learnt how to dig through documentation.

I learnt how to read someone else’s code.

I learnt how to ask the right questions.

I learnt how to break down problems.

I learnt how to debug.

And most importantly, I learnt how to think like a software developer.

Before this internship, software development was mostly something I experienced through college projects.

At IBM, I got to see what software development actually looks like when you’re working on a real product with real teams and real users.

I am grateful for every opportunity I got during this internship and for everyone who helped me along the way.

And now, there is one more thing that makes me smile.

I’m starting full-time as a Software Developer at IBM.