Source linked

Gagner un hackathon dépend plus de la démo que du code

blog.jetbrains.com@brave_condor2 hours ago·Developer Tools·4 comments

Les juges d’un hackathon de JetBrains disent que le facteur décisif n’est pas 24 heures de travail mais quelques minutes de présentation.

jetbrainsopenainebiusscarfhackathonpresentation skills

The team that won the JetBrains x Codex Hackathon probably didn't have the best architecture, the cleanest code, or the most features. They had the best demo. I sat through two days of pitches, and the judges I talked to - Jono Bacon (Stateshift), Avi Press (Scarf), Bonnie Xu (OpenAI), Jan-Niklas Wortmann (JetBrains), and Colin Lowenberg (Nebius) - gave nearly identical advice. A strong project with a confusing demo loses to a simpler project the judges understand in 90 seconds.

The Problem Is Not Self-Evident

Every judge said the same thing: lead with the problem. Jono Bacon put it bluntly: "You need to get your audience of judges sharing your frustration with the problem." If they don't feel the pain, nothing you built matters. Bonnie Xu flipped the common approach: don't start with "what's the coolest new tool?" Ask "what's something I can build now that I probably couldn't have built before?" That shift from tool-first to annoyance-first is the difference between a demo that lands and one that fades.

Scope to One Working Flow, Not Five Broken Ones

Colin Lowenberg tied scope directly to demo length: "If it's too long, cut down on your features." A long demo isn't a pacing problem - it's a scope problem. The best projects do one thing end to end. Bonnie said one clear "oh, this is possible now" moment beats a tour of every feature. Pre-fill forms, mock slow API calls, remove every place the demo could stall. Hackathons reward the working demo, not the clean architecture nobody sees.

Rehearse Like You've Already Won

Colin's advice: visualize yourself winning and work backward. Picture the demo that wins, then build toward exactly that. Run it out loud at least once. Time it. The pitch is part of the product. Teams that practice look like they practiced. And enthusiasm matters more than polished slides - a team enjoying its own project is more convincing than one grinding through a script. Success comes down to three things: leading with the problem, showing one thing working, and letting it be obvious that you care.


Source: How to Win a Hackathon: Notes From the Judging Table
Domain: blog.jetbrains.com

Read original source ->

External source stays available while the OJO article and comment thread stay local.

Comments load interactively on the live page.