My First Datathon

At the beginning of this year, I made a decision that I wanted to do more for my career.

I wanted to do more than just finish courses and collect certificates. I wanted to actually build things, meet new people, try new experiences, and learn by doing.

And somehow, that decision led me to my first datathon.

One day, a friend from university told me that she had joined a datathon through Women in Data. I immediately asked her to send me the link because I wanted to join too.

Of course, part of me was already thinking: this could be really good for my CV and portfolio. :)

But honestly, when I registered, winning wasn't really on my mind.

I joined because I wanted to learn, meet new people, work with real-world data, and experience what it is like to work on a data problem outside of a course or university assignment.

Then I joined a team of four girls.

And things became a little more serious.

We didn't really work like we were “just participating”

During our first meetings, I noticed something.

Everyone was taking the project seriously.

We were discussing ideas, dividing tasks, questioning our results, and thinking about what would make our project stronger.

At some point, my mindset changed from:

“This will be a nice experience.”

to:

“Okay. If we're doing this, I actually want us to do it well.”

I decided that I wanted to put real effort into the competition.

And I also wanted to be involved in as many parts of the project as possible.

I wanted to be involved in as many parts of the project as possible. I felt like this was a good chance to learn things I wouldn’t really learn from a normal course or assignment.

Starting with the data

My first tasks were around collecting and preparing the data.

I prepared our Google Colab environment and worked with data coming from BigQuery.

Then came cleaning.

And merging.

And checking.

And then checking again.

Our datasets came from different sources, which sounds simple until you actually try to combine them.

Country names and identifiers were not always represented in the same way, so we had to standardize things like country information and make sure codes such as ISO3 and M49 were correctly aligned before merging the datasets.

At this stage, I was mostly focused on preparing the data and making sure it was clean enough for the analysis.

Working on this part made me understand how much the cleaning stage can affect everything that comes after it. A small problem in a merge or country code could easily change the final results.

Then we found a problem

After the data preparation was finished, two of my teammates worked on the analysis. One of them then continued with the robustness checks to make sure our results were reliable.

And this is where things became interesting.

After testing our results, we realized that something wasn't completely right.

There was a problem with our analysis.

Of course, finding that out after doing a lot of work is not exactly the moment you hope for :)

But I decided to take responsibility for reviewing the analysis.

I went back through the work, checked what might be missing, reviewed the logic and helped make the necessary corrections.

At the time, it was stressful.

Looking back, though, this was probably one of the most useful parts of the whole datathon for me.

Because real data projects don't always go:

clean data → analyze → beautiful result → done.

Sometimes you analyze something, test it, realize there is a problem, go backwards, fix it, and try again.

And I think learning to question a result instead of immediately trusting it is an important part of becoming a better analyst.

We had the analysis. Now what?

Once we were happy with our analysis, we started thinking about the actual solutions.

We didn't want to simply show some graphs and finish with:

“Here are our findings.”

We wanted to think about what could realistically be done about the problem.

That part forced us to think differently.

Instead of only asking:

What does the data say?

we also had to ask:

So what? What could someone actually do with this information?

That was something I really enjoyed.

“Why don't we make a website?”

At some point, oOne of my teammates suggested including a website as part of our solution.

And naturally my reaction was basically:

I can do that.

Since I already had experience with front-end development, I decided to quickly build the website using HTML and CSS.

It wasn't the most complicated website I had ever built, but that wasn't the point.

The website was there to support the project and help us communicate our work better.

And I liked being able to bring another part of my background into a data project.

It reminded me that the skills we learn don't always have to live separately.

Sometimes my web development experience can support my data work.

And then came Amina

After that, we had another problem:

How do we present all of this?

We had the analysis. We had the findings. We had our solutions.

But we didn't want our final presentation to feel like someone was simply reading numbers from slides.

One of my teammates suggested that we use storytelling.

I loved the idea.

So I started thinking about how we could turn the data into a story that people could actually connect with.

That's when I came up with Amina.

Amina became a character through whom we could tell the story behind the numbers.

Instead of only saying:

“This percentage of women experience X…”

we could show how these different problems could affect the life of one person.

The team liked the idea, so we built the presentation around her story.

One teammate organized the presentation and divided the speaking parts between us.

We all recorded our voices.

And then there was one final job left.

Editing the video.

Obviously, I volunteered for that too :)

I've always enjoyed creative work.

Video editing, visual design, figuring out how things should flow, those are things I genuinely enjoy.

So I decided to edit our final presentation video and prepare it for submission.

At that point, I realized how many different things I had touched during one project.

I had worked on:

data collection → BigQuery → Google Colab → cleaning → merging → reviewing the analysis → website development → storytelling → video editing

And somewhere along the way I also learned how to use Jira to organize our work as a team.

This was exactly why I had wanted to join a datathon in the first place.

By that point, the datathon had become much more than something I could add to my CV. I was enjoying seeing how every part of the project connected together, from the raw data to the final presentation.

And then we placed third

The funny part is that I joined mainly for the experience.

But after all the meetings, fixing problems, discussing ideas, recording voices, changing things at the last minute and working seriously as a team...

we finished in third place.

And yes, I was very happy about that.

But I think what I'm most glad about is how involved I was in the entire journey.

I didn't only work on one small technical task and disappear.

I got to see how a project develops from a collection of datasets into an actual story and final product.

What I took from the experience

Before this datathon, I thought mostly about the technical side of data projects.

Clean the data. Analyze it. Visualize it.

Afterward, I started seeing the bigger picture.

Technical skills matter, obviously.

But you also need to communicate.

You need to question your own results.

You need to explain why your analysis matters.

You need to work with people who don't always think exactly like you.

Sometimes you need creativity.

And sometimes you need to admit that something isn't working and go back and fix it.

I also learned new tools such as BigQuery and Jira, became more comfortable dealing with messy real-world datasets, and got experience thinking about actual solutions rather than simply producing charts.

But probably my favorite part was discovering that I don't have to choose between my technical and creative sides.

I enjoyed the data work.

But I also enjoyed building the website, creating Amina's story and editing the final video.

And somehow all of those things worked together.

The team

I also can't talk about this experience without talking about my team.

I was lucky to work with an amazing group of girls.

Everyone brought something different to the project, and there were many moments where someone else's idea completely changed the direction we were going in.

The website wasn't originally my idea.

The storytelling approach wasn't originally my idea either.

But one person suggested something, another person built on it, someone else improved it, and slowly the project became something that none of us would probably have created alone.

That might actually be one of the biggest things I learned from the experience.

A good team doesn't mean everyone does the same thing.

It means everyone brings something different.

And I'm really glad this was the team I had for my first datathon.

When I decided at the beginning of the year that I wanted to do more for my career, this was exactly the kind of experience I meant.

I joined thinking it would give me something useful for my CV and portfolio.

It did.

But it gave me much more than that.

And this blog is partly about documenting experiences like this, the projects, the mistakes, the things I'm learning, and hopefully the progress I make along the way.

So I guess this is a good place to start.

My first datathon. And definitely not my last.