"The Fastest Way to Learn a Company's Tech? Contribute to Open Source" — AIEEV's Jinbeom Kim

A Story from AIEEV Dev Team's Jinbeom Kim

Contributing to open source does not automatically make you a better engineer. The skill only sticks once you reproduce the problem, trace the code's flow and the reasoning behind its design, and organize the process so someone else can follow it too.

Jinbeom Kim of the AIEEV Dev Team has lived out this process firsthand. On July 4th, he gave his first community talk at AWS Student Community Day 2026's Career track, titled "The Fastest Way for Junior Developers to Understand Their Company's Tech: Contributing to Open Source." From what first drew him to open source, to the questions junior developers face in the AI era, to the message he wanted this talk to carry, we sat down with Jinbeom to hear how he came to understand his company faster than anyone, just three months after joining.

👋 Hi Jinbeom, could you introduce yourself briefly?

Jinbeom speaking at AWS Community Day 2026

Hi, I'm Jinbeom Kim, and I work on development at AIEEV's Dev Team.

I earned my master's degree in computer science last year and joined AIEEV to start my career as a developer. I got lucky, the open source work I picked up through my day-to-day job kept snowballing, and this past July it led me to speak at AWS Student Community Day 2026's Career track on "The Fastest Way for Junior Developers to Understand Their Company's Tech: Contributing to Open Source."

How did this talk come about?

A post went up in an open source contributor group I was part of, looking for speakers. I'd always wanted to be a proactive developer in every sense, so I worked up the courage to apply, and to my surprise, I got picked. Joining AIEEV was actually what got me started on open source in the first place, so I shared the news with my team, and everyone cheered me on enthusiastically 😊

The (surprisingly?) enthusiastic support for Jinbeom's surprise announcement

This was your first time speaking at a developer community event. What did you focus on most while preparing?

Yes, this was truly my first time speaking at an event like this 😅 Between grad school conferences and my thesis defense, I didn't think presenting itself would rattle me, but this was a different kind of room than the academic talks I was used to, so figuring out how to share my experience and land the message clearly was what I thought about most. So I set one clear goal for this talk: say what I actually wanted to say, plainly. From what got me started in open source, to trading feedback with people I'd never met, to the technical skills I picked up along the way and the community culture I discovered, I tried to walk through my entire OSS contribution story from A to Z, in language other junior developers could relate to and enjoy.

🎤 Why Open Source Became His Talk Topic

How did you land on this topic?

The first thing that came to mind when choosing a topic was the process I went through early on to understand my company's technology. Looking back, digging into open source directly, finding problems, and contributing fixes was what helped me grow fastest as a developer. So for this talk, I wanted to share the idea that contributing to open source can be a great starting point for growth for junior developers like me.

When I first joined, I was assigned to research and development for the scheduling and operations structure of our distributed platform, which introduced me to the open source projects that make up our platform: scheduling, container orchestration, distributed computing. Onboarding helped me understand the company's technical architecture, but I felt that solving actual customer problems required understanding why we chose this particular technology and why we applied it to our service the way we did. So I set a goal: contribute directly to the open source projects the company uses, starting with small issues. Through that process, I realized that quickly picking up a new technology mattered less than understanding the context and background behind why it gets used, in order to define a problem accurately and find the right solution. Contributing to open source turned out to be a huge help in grasping that context.

The three months that led up to my first real contribution gave me a much deeper understanding of the company's technology and service architecture. At the same time, it reshaped how I, as a developer, look at technology and think about my career. So through this talk, I wanted to tell people wrestling with the same questions that the result might just be a few lines of contributed code, but the experience of wrestling with a problem and working it through is what really becomes the foundation for growing fast.

What specifically did you talk about?

Open source is genuinely something anyone can start, it's a very open activity, but personally, I found taking that first step really difficult. I felt the same way, and it was only through help from people around me, including colleagues, and through open source meetups and activities, that I gradually came to understand it and start contributing on my own. So I shared some of the lessons from my own trial and error to make that first step a bit easier for people standing at the same threshold.

Ray is the open source project used most heavily inside our company, so I built the talk around my experience with it. Early on, I wanted to understand exactly how the metrics collected from each distributed node, including what shows up on Ray's dashboard, actually got generated. But Ray is such a large project that just reading the code left me unsure where to even start. Then I found an issue where some cluster metrics weren't being collected properly under the newer Autoscaler, and I thought: if I solve this myself, I can get a much more hands-on grasp of the structure I'd been curious about. So I took it on. As I traced the problem, I identified the difference in how the old and new Autoscaler communicated cluster state, and fixed the dashboard so it could collect metrics correctly under the new approach, then submitted a PR. Compared to just reading and studying code, following one real problem all the way through, tracking where the data was generated and where it traveled, gave me a much faster grasp of the project's overall structure.

So rather than simply explaining "how to contribute to open source," I centered the talk on how I actually went about finding problems, tracing code, and contributing hands-on to understand technology that once felt completely out of reach. Even the parts that seemed obvious in hindsight, I only really understood once I ran into them myself, and I learned plenty from the trial and error along the way.

Part of the slide deck covering the OSS contribution process

Why do you think contributing to open source is the best way to understand technology?

With open source contributions, attention usually goes to whether the code ultimately got merged. Of course, having your proposed approach land in the codebase is the best outcome, but personally, I think the process matters just as much as the result. To really understand a problem, you first have to reproduce the behavior, look into the code's flow and the reasoning behind its design, then organize the problem and the solution so someone else can follow it. Even tracing a single small issue naturally pushes you to examine the technology from multiple angles. Along the way, you also build the habit of narrowing down root causes and explaining your own judgment with evidence. So I think contributing to open source is both a way to understand technology and a way to learn how to solve problems systematically.

A snippet from the review exchange during the actual contribution process

Of course, everyone learns differently, so I can't say open source contribution is the best learning method for absolutely everyone. But static learning has never quite clicked for me personally, and for anyone who wants to understand a technology deeply in a short time, I think getting your hands dirty directly is the best option out there.

💻 The Talk, and What Came After

What was the atmosphere like on the day of the talk?

About 60 to 70 people showed up for my session. It was my first time at AWS Student Community Day, and there were far more people than I expected, so the nerves hit hard the moment I walked into the room. Still, I could feel everyone's enthusiasm throughout the event, and that pushed me to prepare calmly, wanting to live up to the moment. Also, just as a side note, to keep the talk from feeling dry and stiff, I worked in a few developer-style jokes as part of that "relatable language" I mentioned earlier, and they landed better than I expected 😎. Once the jokes hit and the audience laughed, I found myself talking naturally, almost like chatting with a friend.

Jinbeom presenting at AWS Student Community Day

Did this talk lead you to any new resolutions?

It made me want to share good experiences with more people. Honestly, I'm someone who rarely even posts on social media, so I tend to be cautious about putting my experiences or thoughts out there. But after the talk, some people asked for my LinkedIn directly, and others thanked me, saying the talk genuinely helped them. Mintae Kim from Woowa Brothers, who spoke right before me, told me that "in the AI era, there's no single right answer, so a culture of sharing experiences and exchanging feedback matters a lot." After finishing my own talk, I really understood what he meant. My way of studying might turn out to be exactly the right answer for someone else.

Lastly, what kind of developer do you want to grow into?

I want to be a developer who shares as much as he grows. Even before I joined, everyone on my team was already contributing steadily to open source projects like Ceph, Redis, and Ray. Even now, whenever we find a problem in the open source tools we use at work, we dig into the root cause ourselves, fix it, and bring what we learn back to improving AirCloud. As a company, we have a culture of giving each other feedback on this whole process, and it goes beyond just passing along knowledge. We talk about why we solved a given problem and what we learned from it, and that's how a culture of growth has taken root here. I want to share the trial and error and the lessons I've picked up with as many people as possible, and grow into a proactive developer who can offer up real possibilities in the AI era.

.

.

.

Want more stories from AIEEV? 👉 Visit our blog

Want to grow together with AIEEV? 👉 Check out our open roles