October 11, 2025

On Hackathons

How it began

I began to develop an interest in hackathons and competitive programming starting in late high school. At the time, my family didn't really have enough money to get by without me constantly working part time, so I would compete in algorithm-based competitions for both college applications and a form of income since I quickly began gaining traction and winning multiple state and regional level events.

As with everything I usually do, I gradually grew tired of solving repetitive algorithms and distinct assigned tasks and wanted something more freeform and creative. I started attending 4-8 hour "Programming Project" competitions which completely invigorated me. Everyone around me seemed so ambitious and passionate about the projects they'd built, everything from a Chrome dinosaur game replica with a wallaby as a replacement, to an AP Chem interactive virtual lab. From then on I knew I wanted to compete at more hackathons and see what people would come up with.

Succeeding in hackathons?

After winning five international level hackathons spanning thousands of competitors and placing in sponsor prizes and runner-up categories at dozens of others, I became the first Northeastern student ranked in the MLH Top 50. I consider myself one of the most successful and most consistent hackers still competing, and that is an honor I attribute mainly to the friends who joined me throughout my hackathon journey. I genuinely could not have accomplished anything without their support.

As a result, many people ask me for assistance with hackathons, ideation, and judging. For the rest of this blog I'll be giving insight into the hackathon "meta" and how to win large-scale hackathons with 1000+ hackers. I'll cover this in order of most to least important: the idea, pitching and judging, project structure, and lastly team dynamics.

Ideation

Many tech influencers and LinkedIn officers will likely tell you something along the lines of:

#include <iostream>
using namespace std;

int main() {
  cout << "Solve a real problem!" << endl;
  cout << "Add a billion AI Agents!" << endl;
  cout << "Pump out dashboards!" << endl;
  cout << "IMPORT <sponsor_api_key>" << endl;
}

Unfortunately, they are correct. This is typically the most effective tactic to win any prize at a smaller scale hackathon.

However, if you actually want to win 1st place in track or general at the most competitive hackathons in the world, or if you want to build something with actual long-term impact and scale, this won't cut it.

So how do we start? Throughout my hackathon experience, my teams and I have come up with ideas from as long as 4 months before, up to 14 hours into a hackathon. As a result, I've found the best way to get an idea is through the intersection of three main components: Problem, Solution, and Technicality, plus an additional component I call the X-Factor.

      PROBLEM           SOLUTION
          \                 /
           \               /
          +-------+-------+
          | WINNING IDEA  |
          +-------+-------+
           /               \
          /                 \
   TECHNICALITY         X-FACTOR

The Problem

Defining the problem is mainly about deciding whether or not your idea is actually something worth solving. Judges at top hackathons have seen hundreds of projects. They can smell a forced problem statement from across the room. The problem needs to be real. Not "wouldn't it be cool if" but "this genuinely affects people and here's why."

When we built Sustainable AF at BostonHacks 2023, the problem was clear from the get-go: climate-aware individuals want to make sustainable choices but have no practical way to evaluate the environmental impact of their purchases, travel, and how it affects their ETAs. That's a real pain point. We knew the same applied to solar panel installation, and took into consideration how costly consultation was from both a financial and temporal standpoint.

The Solution

Your solution needs to be specific and scoped. This is where most teams lose. They define a vague problem, then propose an equally vague solution. Even with a well-defined problem, the solution can fall flat if it's not structured properly. "We're going to fix climate change with a weather and air quality API app" is not a solution. "We built an interactive solar heat map that shows you exactly how much energy your roof can generate and for how much" is.

With Maritime, the solution was dead simple: point your camera at ocean waste, get an instant CNN classification, and see live microplastic concentration data for your location. One sentence, focused, precise, effective. That's what you're aiming for.

Technicality

This is where your engineering prowess comes into play. Most of the people I've seen struggle at hackathons don't necessarily have a skill issue but rather can't communicate the technical depth of their project. Technicality isn't about using the most buzzwords, though for smaller scale hackathons it can be. It's about choosing the right stack for the problem, executing it well, and communicating functionality. Judges can tell the difference between a team that understood their architecture and a team that copy-pasted a tutorial. You need to be ready to explain why you chose a particular language if it's a bit unorthodox, or why you reached for a specific algorithm.

For OracleNet, we used Graph Neural Networks to model cascading economic, geopolitical, and social impacts from billions of news articles. That sounds fancy, but it was the natural choice for our group's skillset. You're modeling a network of dependencies, so a graph-based approach is the obvious architecture. Every technical decision should have a reason.

The X-Factor

This is one of the most talked about yet most overlooked aspects of winning hackathon projects. The X-Factor is more than just a novelty like "we used Lean to make a video game." It's about timing, location, and a flashy demo. Why should judges care about this problem right now? Fire tracking when competing in California during wildfire season. Ocean microplastics when a documentary just went viral. Smart grid optimization when energy costs are spiking. Alternatively, fluid 3D realtime graphics that blow the judges away, or having the project be so interactive that the judges feel like they helped build it. If your project solves a problem that's currently in the cultural conversation, you have a massive edge.

Pitching & Judging

Once you have a winning idea, you need to sell it. I've seen technically superior projects lose to teams with half the engineering but twice the storytelling. Here's the structure that has never failed me:

  • Lead with the problem. Make them feel it.
  • Show the solution. Demo first, explain second.
  • Explain the technicality. Briefly, confidently.
  • End with the X-Factor. Why this matters right now.

Judges don't remember feature lists. They remember stories and narratives. When we presented Griddy at HackMIT 2025, we didn't lead with "we found an environmentally friendly way to reduce electricity costs." We led with "how do you make it literally economically unfavorable to use any alternative but green energy?" Then we showed it in action. The power grid and fertilizer batteries were the how, not the what, and the how in itself was a unique X-Factor.

Also, and I cannot stress this enough: if your demo doesn't work live, none of the above matters. Speaking from painful firsthand experience. Spend the last two hours before judging just testing. Then test again. Then one more time, preferably in multiple locations as well. And of course, try your best to record a demo video.

Project Structure

Planning your project structure is about scope and resource management. You have 24-48 hours. You are building a proof of concept that works flawlessly for a 3-minute demo, with backups.

Here's what I do: in the first hour, whiteboard the entire system at a high level. Every API call, every component, every data flow. Assign ownership. Whatever you think you can build in 24 hours, you can realistically build about 60% of it. Scope ruthlessly and maintain focus. Don't make sprawling features that muddy your main idea's core premise. Ship the thing that works.

Your Team

None of this works without the right team. My best projects came from teams where everyone knew their role and trusted each other.

The most important thing isn't individual skill. It's complementary skill sets and mutual trust. You need someone with a knack for design who can make the frontend and UI feel polished and intentional, not just functional. You need someone with a high vertical in pitching who can walk into judging, command the room, and tell a story that makes judges actually care about your project. Last but definitely not least, you need someone technical enough to be the backbone of the more ambitious aspects of the build, the person who can architect the system, debug under pressure at 4 in the morning, and push the project's technical depth beyond what a basic tutorial could give you. If one person can cover two of those roles, even better. You've won the lottery.

Conclusion

I hope this post serves those who are beginning to get more ambitious with their hackathon projects and are as passionate about the hackathon space as I am. I'm grateful for every person I've stayed up for nights on end with over stale Red Bull, questionable WiFi, and one shared stick of deodorant. Hackathons gave me some of the best friendships, wildest stories, and sharpest engineering instincts I have today. If you're reading this right before a hackathon, good luck. Scope small, maintain focus, demo hard, tell a story, and most importantly, have a positive impact. Make people say "how did you even make this?"