Over the past year, I participated in several hackathons and ideathons. More than simply finishing projects, those experiences helped me understand what kinds of problems I naturally get absorbed in, what strengths I have, and what kind of collaboration I enjoy.
Numerical Relativity and Gravitational Wave Competition
The hackathon I was most deeply immersed in as a physics major was a numerical relativity competition about gravitational waves. The challenge was to analyze astronomical observation data and trace the origin of gravitational waves. It was my first proper encounter with the kinds of analysis tools and libraries used in real research environments.
More specifically, the task was to analyze data measured by gravitational wave detectors using a Python library called PyCBC. The competition was divided into three stages.
The first problem was a tutorial-level task for learning the PyCBC library. The second was to detect gravitational wave signals hidden among different kinds of noise. The final and most difficult problem was to estimate where the gravitational wave came from and what kind of collision produced it, such as a merger between black holes or neutron stars.
Gravitational waves can appear in many different forms. To compare the raw detector data with prepared simulation waveforms, we first had to transform the data into the frequency domain using FFT, or Fast Fourier Transform. Then we used matched filtering to compare the observed data against the simulated waveforms.
The content itself was extremely difficult. I stayed up through the night trying to analyze the data, but the results were not very satisfying. Both signal detection and localization had large errors, and our team could not clearly identify why.
I had practiced Git with the friend who joined the competition with me, but in the actual event, we were too busy debugging errors and interpreting library behavior to manage the code properly. PyCBC itself was complex, the official documentation was not very friendly, and even the mentors on site were not fully familiar with the library, so it was hard to get practical help.
That experience made me feel something very clearly: tools and equipment used in research are often much less user-friendly than expected. They may have the accurate functions researchers need, but accessibility and explanation are often lacking. I had felt something similar when using experimental equipment in physics labs, and this experience made my interest in physics, especially experimental physics, drop sharply.
It was a different kind of competition from what I had expected. Rather than theoretical physics or mathematical thinking, the key skills were computational numerical analysis and the ability to operate a complex research library. It gave me my first concrete sense of what it feels like to handle physics in practice.
Campus Ideathons: Startup Camp 2023, 2024, and 2025
I also participated twice in my university's overnight startup camp, in 2023 and 2024. It was closer to an ideathon than a traditional hackathon. We did not build a working product; instead, we formed a team, developed a startup idea, and presented it. Still, the chance to spend two days seriously discussing startup ideas with teammates was extremely valuable to me.
In 2024, our team won first place. The result was meaningful, but what stayed with me more was the experience of thinking seriously about how to define a problem and persuade others that a solution matters.
In 2025, I proposed Digging Music, the service I am still building. At first, I explained the idea only with words, but my teammates could not fully understand it. To me, the problem was already clear. But I had not shown why it mattered, why the solution was necessary, or how the product would actually work from another person's point of view.
So I designed the site and showed actual screens. Only then did the team finally understand what kind of service it was.
That was when I realized something important: even a good idea loses persuasive power when the way it is communicated is weak.
The reason I feel that a certain problem matters is often that I already have a lot of background knowledge and interest in it. I have always been interested in music, and I sometimes look up lyrics and interpretations. But for most people, that problem is unfamiliar. The solution is unfamiliar too. Sometimes they do not even understand what the service is supposed to do.
So I learned that I need to show ideas more visually, structure them in a way that is easy to understand, and think seriously about PR and communication. Since then, whenever I think of a product idea, I try to think not only about the idea itself, but also about how it should be shown and explained.
Bubble Hackathon
I also participated in No-Code-thon, a hackathon where teams built actual services using Bubble.io. I proposed the main idea, and within the team I was responsible for backend implementation and workflow design.
We built a mental health app. The structure was simple: the app would send short questions to users every day to help them reflect on their emotional state and well-being. Users could track their responses over time and gain insights into their mental health patterns.
What impressed me most about this hackathon was how quickly we could build something functional. With Bubble.io's visual development environment, we didn't need to write much code. Instead, we could focus on designing the user experience and the logic of the application. Within just a few hours, we had a working prototype that we could actually test and refine.
This experience taught me the value of rapid prototyping and iteration. Rather than spending weeks planning and building, we could get feedback quickly and adjust our approach. It also showed me that sometimes the best tool for a job is not the most technically sophisticated one, but the one that lets you move fastest and focus on what matters most—in this case, the user experience and the core functionality.
What I Learned
These three very different hackathon experiences taught me several important lessons:
First, I learned that the tools and methods we use matter enormously. Research tools can be powerful but unfriendly. No-code platforms can be limiting but liberating. The right tool depends on what you're trying to accomplish and how much friction you're willing to tolerate.
Second, I learned that communication and presentation are just as important as the idea itself. A brilliant idea that nobody understands is not useful. You need to be able to show people why a problem matters and how your solution addresses it.
Third, I learned that I enjoy building things with a focused team under time pressure. There's something energizing about working intensely toward a concrete goal with people who are equally committed. The constraints of a hackathon—limited time, limited resources—actually help clarify what matters and what doesn't.
Finally, I learned more about myself. I'm drawn to problems that feel meaningful and that I can understand deeply. I enjoy the process of turning an abstract idea into something concrete that people can interact with. And I value collaboration with people who bring different skills and perspectives to the table.
These hackathons were not just competitions or resume-builders. They were learning experiences that shaped how I think about problems, how I communicate ideas, and what kind of work I want to do.