What I Learned When Theory Met the Real World

By Lucca Gamballi, Associate Data Scientist · August 2026

Theory in my backpack and a piece of advice from Mom

My name is Lucca Gamballi and, in April 2025, I started my Data Science internship at Wildlife Studios. I studied Electrical Engineering at the University of São Paulo and, like a lot of people reading this, I showed up to my first job with the classic university toolkit: plenty of theory, a few personal projects, and the habit of trying to solve everything on my own. This article is about what happened when that toolkit met the real world. The projects I worked on, what I learned technically, and above all what it is like to work in an environment far less controlled than a classroom.

I found out about Wildlife thanks to my mother. I was in my final semester, just back in Brazil from a dual-degree program, and I still had to complete my university internship requirement in order to graduate. One day, while I was telling my mom about it, she mentioned she had seen a job posting on LinkedIn at a gaming company that sounded exactly like me. You don't turn down advice from your mother, so I applied, and it could not have gone better.

“Pick a game and play it”

My onboarding wasn't a SQL course or a stack of documentation. It was: pick a game, play it (and play a lot), understand it, and then answer a question that genuinely caught your interest.

I'll admit that my stomach dropped a little at first. I was expecting something simpler, like documenting a process or tidying up a dataset. What I got instead was a real question inside a completely open-ended problem, with room to explore and propose improvements to one of the company's products. To get there, I first had to understand the product itself: how the game works, how it monetizes, where it sits in the market. Only then did I move on to the data, to how much players spend, how much they win, how they progress.

That order was no accident, and it was my first big lesson. Understanding the context of a problem is worth as much as the technical knowledge to solve it. At university, the context arrives pre-packaged in the problem statement and in months of lectures on whatever the exam covers. At work, building that context is half the job. From that very first project, it was clear that nothing I would be doing there was intern busywork to fill the time. Everything had a reason, and someone was waiting on the answer.

The projects university doesn't prepare you for

After onboarding, the projects kept getting heavier, and each one taught me something no course ever had.

One country field and a cascade

In the first one, the company switched the provider that identifies which country each player comes from. It sounds like a detail, until you follow the cascade. A player's country feeds the install and revenue metrics, which feed the forecasting models, which feed investment decisions. My job was to validate that nothing broke along the way, and in the process I discovered that a good share of the players who “changed countries” in the update were actually people using a VPN. The lesson is that the most valuable projects aren't always the most glamorous ones. Validating a migration won't get you a pretty model for your portfolio, but it's what keeps all the pretty models trustworthy.

Learning Airflow on the fly

Next came an automation task: a piece of R code that had to be edited by hand with every update, which I turned into an automated Python pipeline using Apache Airflow. It was my first contact with the tool, learned under pressure, on the fly. The first pipeline cost me a lot of sweat. The second one, on a different project, came far more easily. That's how it works, and today I know that “figuring it out on the fly” is a skill you can train.

The bridge between cohorts and the calendar

In my final stretch, I worked on rebuilding one layer of the company's revenue models. There is a subtle problem there that only shows up in practice. The models forecast how much each cohort of player installs will earn over time, but the company sees revenue day by day, on the calendar. They are two views of the same money that don't line up naturally, and the bridge between them had gone without maintenance. In the end, rebuilding that bridge turned it into an internal “product,” and left me with the feeling that there's a small brick of mine in the wall around here.

The three lessons that aren't technical

The technical side was intense: first contact with Airflow and with R, SQL used for real, Git every single day, ENORMOUS tables. But if I had to sum up the internship in lessons, the three biggest ones aren't technical.

Ask for help early. This is, by far, the most important lesson I'm taking with me. At university, I was used to solving everything on my own, and in group projects I would do more than my share. At work, I learned that asking early isn't a sign of weakness. It's respect for everyone's time, including your own. Asking for help sooner saved me a lot of hours of work. A lot.

Context and defining the problem are fundamental. Understanding why a problem exists, who depends on the answer, and what changes because of it is worth as much as knowing the technique to solve it. At university, that comes for free, built up over the course of a semester. At work, it's the first thing you have to build.

Work isn't a solo activity. I pictured working with data as something solitary: me, a notebook, and a bunch of queries. I was very wrong. The discussions with the team, the support from colleagues, the sense of belonging. All of that doesn't just make the day-to-day better, it makes the work better.

High standards with a purpose, and a team that has your back

What struck me most about Wildlife was the combination of two things I didn't think went together: a genuinely high bar and a genuinely welcoming environment.

At first the high bar is intimidating, but it makes sense, because it always came with a purpose, and I could always see why something was worth doing. And the welcome was there from my very first day: people who treat their own work with real care, who give their best and pull the best out of their colleagues, and who don't hoard what they know.

The clearest sign of my own growth wasn't technical. It was noticing, little by little, that the team's discussions had become easier to follow. That I was taking more initiative and had stopped putting off the things that scared me. That I was starting to help other people the same way I had been helped. It's obvious to me that I'm not the same person I was when I started.

A few months ago, I was the intern who didn't know what a DAG was and thought that working with data was a solitary job. Today, I look back and see how far I've come.