How to Win a Hackathon: Notes From the Judging Table

Katherine Druckman

At the JetBrains x Codex Hackathon, I spent two days watching teams build and then pitch their projects. The thing that decided most of the winners wasn’t just the previous twenty-four hours of work. It was the few minutes they spent presenting it. A strong project with a confusing demo loses to a simpler project that the judges understand.

So, I asked a handful of the judges what separates a hackathon pitch that wins from one that gets forgotten by the next presentation. Their answers lined up almost perfectly. Here’s what they told me, plus a few things I’ve picked up judging these myself.

Start with the problem

Every judge said a version of this, which tells you how often people get it wrong.

Here’s how Jono Bacon, CEO of the developer engagement firm Stateshift, put it: “Say what the problem is that you’re solving. You need to get your audience of judges sharing your frustration with the problem that you see in the world.” If the people watching don’t feel the problem, nothing you built in response to it will land.

Avi Press, founder and CEO of Scarf, said the same and added the part people skip: “Always be very clear about what problem you’re solving and what your submission does to address that problem. Sounds obvious, but often people skip it.” They often do so because they’re excited about the tech and assume the problem is self-evident. It isn’t.

Bonnie Xu from OpenAI framed it as a choice you make before you write any code: “My advice is to not start with ‘what’s the coolest new tool I can use?’ but with ‘what’s something I can build now that I probably couldn’t have built before?'” The best projects, she said, come from something specific – a workflow you’ve personally found annoying or slower than it should be. Build from the annoyance rather than the tool.

Do the homework before you write a line of code

Jan-Niklas Wortmann, a Developer Advocate at JetBrains, made the point that the work starts before the hacking does: “Read the rules before. Don’t start writing anything before you really understand the problem space, the objectives of the hackathon, and what the judges are probably looking out for.” Carefully read the prompts or problem statements. Figure out who’s judging and what they care about. If you can talk to them before you build, do it.

Colin Lowenberg from Nebius had a practical version of the same idea: don’t start cold. “There’s always a better starting point than a blank GitHub.” If you don’t have experience with something you need, ask a mentor or a sponsor for a repo to start from.

And give yourself the best odds against the clock. Jan-Niklas again: “Use tools that you’re already familiar with and work with people that you’re already familiar with.” Meeting new people is part of why hackathons are fun and worth going to, and plenty of strong teams come together on the day of. The point is just to limit how many unknowns you’re carrying at once. Stacking a new framework, a new teammate, and a new problem domain all at once is a lot to absorb in a weekend, so lean on what you already know where you can.

Scope down to one thing

This is where a lot of teams miss. They try to build five features and end up shipping none of them cleanly.

The best projects do one thing really well rather than five things halfway. Beware of scope creep and feature-itis. Trying to do too much feels like you’re being ambitious, but what you’re actually doing is guaranteeing that nothing in your demo works end to end.

Colin tied scope directly to the demo: “Your demo should be the focus. It should show what your app does in one flow. If it’s too long, cut down on your features.” If the demo runs long, that’s not a pacing problem. It’s a scope problem, and the fix is to cut.

Bonnie put the upside plainly: one clear “oh, this is possible now” moment is much stronger than a tour of every feature. Show what used to be frustrating, show the new version, and make the contrast obvious.

Make the demo the whole pitch

You might only have a few minutes, and the demo is what people remember. Treat it that way.

Jono’s rule: You have to be able to show something working within about 90 seconds. Take the problem you described and show the solution, fast.

Avi gets specific about the demo itself: “Put the judge in the shoes of the user and walk them through what happens.” Even if what you have isn’t polished or fully working, show what using it actually looks like. And be straightforward about it. “Be very direct about what works, what doesn’t, how it works, and how it could be extended.” Judges can tell when you’re talking around a feature that doesn’t exist yet. Being honest about it reads as confidence.

Colin had a checklist for not stalling out in front of the judges: “Mock everything you can and make sure all your forms are filled and your back and forth flows with the user are smooth.” Pre-fill the data. Mock the slow API call. Remove every place the demo could stall.

And don’t over-engineer the thing underneath. As Jan-Niklas put it, shipping a good demo matters more than having the most reliable, highest-quality code. A hackathon rewards the working demo, not the clean architecture nobody sees.

Rehearse like you’ve already won

Colin’s advice is to start from the finish: “I want you to visualize yourself winning the hackathon and work backwards from there.” Picture the demo that wins, then build toward exactly that. Make the presentation smooth and ready. You may only have a few minutes, so every second of it should earn its place.

Run it out loud at least once before you present, and be sure to time it. The pitch is part of the product, and the teams that practice it look like they practiced it.

Relax and have fun

Enthusiasm does more work than people expect.

Judges will sense your enthusiasm, so try to remember what got you excited to build this in the first place. That’s the part we actually want to see. A team clearly enjoying its own project is more convincing than a team grinding through a script.

Jan-Niklas said the same thing about the weekend as a whole: the time crunch and the pressure are part of the experience, and subjecting yourself to them is its own kind of learning. Enjoy the journey. Have fun. Build.

Success mostly comes down to three things: leading with the problem, showing one thing working, and letting it be obvious that you care.