My First Hackathon Experience

I never planned to attend a hackathon. It wasn’t even on my radar. But sometimes, life throws you into situations that push you out of your comfort zone—and this was one of those moments.

It all started at an event I attended with my wife. She was one of the panelists, and as I waited outside while the setup was happening, I noticed a vibrant purple poster about a hackathon. Something clicked. I thought to myself, “I’ve never done one before. Why not?” I’d seen others participate in hackathons, but I never actively sought out the opportunity myself. The date was two and a half weeks away, so I added it to my reminders app, unsure if I’d actually go through with it.

A few days passed, and after some back-and-forth in my mind, I decided to register. The hackathon was a 24-hour event starting Friday at 5 PM and ending Saturday evening. I joined the Discord server and started mentally preparing for what lay ahead. Honestly, I wasn’t confident—I’m not a professional web developer. Sure, I build websites and applications in my free time, dabble with databases, and explore different technologies, but I knew there were gaps in my knowledge. Still, I figured this could be an opportunity to learn something new, meet people, and challenge myself.

Pre-Hackathon Jitters

As the event approached, nerves crept in. I didn’t have a team, and while the organizers promised to pair solo participants with others, it felt daunting to walk into an unfamiliar environment alone. Initially, I asked a co-worker if he’d join me; he considered it but ultimately couldn’t due to personal commitments. So there I was—back to square one—heading into the hackathon solo.

I’m usually not someone who gets nervous about big events or public speaking, but this felt different. The idea of spending 24 hours surrounded by people who likely had more experience in software development made me uneasy. Would I make a fool of myself? Would my skills be enough? My wife encouraged me to go for it anyway.

On the day of the hackathon, it was raining—a fitting backdrop for my mood. A helpful tip from someone on Discord calmed me: “Find a room with a whiteboard and bring energy drinks.” Armed with Red Bulls and Celsius drinks from home (plus knowledge of where the whiteboards were), I headed out.

The Orientation

When I arrived at the venue—a building where I used to take college classes—the nerves hit again. People began filing into the giant hall in groups: college students with their friends, high schoolers chatting excitedly. Meanwhile, I sat alone in the third row on an aisle seat, watching everyone else settle in.

The orientation brought an unexpected twist: each team had to create something based on the theme Yin and Yang. The idea was to design something where two opposite functionalities coexist and complement each other—a fascinating challenge.

After the orientation ended, solo participants were asked to step outside to be paired up with teams. A small group of us nervously gathered near the organizer—clearly all first-timers like me. Eventually, we were matched into teams of four after some reshuffling when assigned teams didn’t show up.

Our team needed a name. Inspired by my current fascination with American history (and Thomas Jefferson), we called ourselves The Jeffersons. With introductions out of the way—most teammates were college freshmen—we set off to find our workspace for the next 23 hours.

Brainstorming: Yin Meets Yang

Once settled into our room, we started discussing our skills. One teammate had experience in robotics and C++. Another two knew Python but were still beginners. As for me? Python is my bread-and-butter, but I also dabble in front-end technologies like Next.js, databases like PostgreSQL, Docker containers, and Kubernetes clusters.

The brainstorming began: What could we build that embodied Yin and Yang? After tossing around ideas, we landed on something quirky—a twist on Tinder called Dates and Debates. Instead of matching people based on shared interests (like Tinder), our app would pair individuals who disagreed on topics so they could debate their differences—a playful take on opposites coexisting.

We debated whether to build a mobile app or web app before deciding on a mobile-first web application as our MVP (minimum viable product). It was simpler than developing native apps for iOS or Android and allowed us to focus on functionality over complexity.

Designing First: Figma Saves the Day

One thing many engineers overlook is design—it’s tempting to dive straight into coding without thinking through user experience or workflows. But design is what users interact with first; it sets the tone for everything else.

I introduced my teammates to Figma—a collaborative design tool widely used by companies like Uber—and we began sketching out our app’s screens together. None of us were design experts, but we worked through templates and iterated based on feedback from each other.

This phase wasn’t just about creating mockups; it was also about learning how to communicate ideas effectively across varying technical backgrounds. By midnight, we had finalized our designs and were ready to start coding.

The Grind: 16 Hours Straight

From midnight until 2 PM the next day was pure engineering mode for me. While my teammates provided feedback and tested features as they came together, I handled most of the front-end development and database setup using Next.js and PostgreSQL. Debugging involved heavy reliance on Cursor AI—a tool that helped identify errors and suggest fixes—but even with AI assistance, coding wasn’t straightforward.

Fueled by three Red Bulls and two Celsius drinks (do the math—it’s a lot of caffeine), I pushed through without naps or extended breaks—just quick trips for water or bathroom breaks. It was exhausting yet exhilarating—the longest coding sprint of my life.

Presentation & Results

After finishing development around 2 PM Saturday afternoon, we prepared for our final presentation—an essential part of any hackathon submission. Presenting isn’t just about showcasing your product; it’s about explaining your idea clearly: what problem you’re solving, how your solution works technically, and what you’d improve in future iterations.

Despite solid mock trials during practice runs, our presenter stumbled during the actual judging session—missing key points that cost us valuable marks in communication criteria. While our innovation scored high on technical execution, other teams had stronger presentations or more compelling ideas overall.

Out of 36 teams participating in the hackathon, The Jeffersons placed fifth—not bad for a team that met just hours before starting! While disappointing not to win any prizes, it felt rewarding knowing how far we’d come together under challenging circumstances.

Reflections

Looking back on this experience, here’s my takeaway: Hackathons aren’t just about building cool projects—they’re about testing your limits mentally and physically while collaborating with strangers toward a shared goal. You learn new skills (technical and interpersonal), face obstacles head-on without quitting—and walk away knowing you gave it your all.

Would I do another hackathon? Absolutely—in a heartbeat!