# How to win a hackathon, according to a tired judge

> How to win a hackathon, from the other side of the table. I judged 20 to 30 teams in two days. Here's what hackathon judges actually notice, a pitch structure that works, and the mistakes that quietly cost you points.

- Author: Rahul Dhileep Kumar (https://www.rahuldk.in/)
- Published: 2026-10-09
- Reading time: 6 min read
- Tags: student life, startups, product
- Canonical: https://www.rahuldk.in/blog/how-to-win-a-hackathon-judges

![A student demos a project on a laptop to a visitor across an exhibition table at a campus tech event](https://www.rahuldk.in/posts/how-to-win-a-hackathon-judges/cover.webp)

*Cover photo: [Evan Marvell](https://unsplash.com/@evan_marvell) on [Unsplash](https://unsplash.com/photos/two-men-at-a-table-with-a-laptop-uzBZnacIKgQ)*

On 8 and 9 October, I sat on the other side of the table.

I was on the jury of a hackathon at VISTAS.
It was run by the Department of Computing Sciences and the Vels Innovation Council.
More than 80 teams turned up.
Over two days, I evaluated somewhere between 20 and 30 of them.

I've been a hackathon participant.
I've lost hackathons.
I've won a couple too, which my [about page](https://www.rahuldk.in/about) mentions with suspicious frequency.

Now I've judged one.
The personal story of that loop is in [from hackathon loser to hackathon jury](https://www.rahuldk.in/blog/from-hackathon-loser-to-hackathon-jury).

This post is the practical bit.
How to win a hackathon, from someone who just spent two days scoring them.

## What hackathon judges actually see

Here's the part nobody tells participants.

Your judge isn't seeing your project in isolation.
They're seeing it as team number seven.
Or team number fourteen.

Most teams in a judge's group share the same or similar problem statements.
So the judge has already heard your problem explained.
Several times.
Usually in the same words.

Around the fifth team, focus starts slipping.
Not because judges don't care.
Because judges are human.

There's research on this, sort of.
[Decision fatigue](https://en.wikipedia.org/wiki/Decision_fatigue) describes decisions getting worse after a long run of them.
The evidence for it is honestly mixed, so don't build a religion on it.
But anyone who has judged fifteen pitches in a row will nod politely.

Running order matters too.
A [Carnegie Mellon study](https://www.sciencedaily.com/releases/2005/03/050308102138.htm) found later performers got higher marks.
That was Eurovision and figure skating, not hackathons.
You can't choose your slot anyway.
So the only thing you control is how fast you earn the judge's attention.

![A smiling student presents in front of a projected slide while a room of fellow students listens](https://www.rahuldk.in/posts/how-to-win-a-hackathon-judges/student-presenting-to-classmates.webp)

*Photo: [Herlambang Tinasih Gusti](https://unsplash.com/@tinasihgusti) on [Unsplash](https://unsplash.com/photos/a-man-standing-in-front-of-a-group-of-people-3kc_75Rdgyk)*

## The first 30 seconds of your hackathon pitch

Start like a person, not a slide deck.

Give the judge a firm handshake.
Ask them how their day is going.
They'll appreciate it.
It's probably been a long one.

Then introduce yourself and your team.
Clearly.
Confidently.
Names, and who built what.

Then say three things, fast:

1. **The problem statement** you picked, in one line.
2. **The scope** you chose to tackle within it.
3. **Your solution**, in one sentence a tired person can repeat.

That's it.
You now have the judge's attention, and you've spent maybe thirty seconds.

An [elevator pitch](https://en.wikipedia.org/wiki/Elevator_pitch) usually runs thirty seconds to two minutes.
Your opening should sit at the short end.

## Show the prototype early

The demo is the hackathon.
Everything else is decoration.

Plenty of hackathon rulebooks say this out loud.
The [UH CodeRED rules](https://github.com/UHCodeRED/rules), for example, strongly encourage a demo.
They say pitches and presentations are discouraged.
They even say teams aren't judged on the quality of their pitch.

Not every hackathon works that way.
But almost every judge prefers seeing a thing work to hearing about it.

So get to the prototype quickly.
Show the main flow, end to end.
One happy path that works beats five half-loaded features.

If something breaks, say so and move on.
Judges have seen broken demos before.
I've broken [production](https://www.rahuldk.in/blog/the-night-i-broke-production), so I'm in no position to judge that part.

![Four college students crowd around a laptop on a podium as they get their project demo ready](https://www.rahuldk.in/posts/how-to-win-a-hackathon-judges/student-team-preparing-laptop-demo.webp)

*Photo: [Shibraj Deb](https://www.pexels.com/@shibraj-deb-429139665) on [Pexels](https://www.pexels.com/photo/men-looking-in-laptop-16070143/)*

## How to win a hackathon: stay on the problem statement

This one hurt to watch, because I used to do it.

Teams drift.
They start on the given problem statement.
Then they bolt on a chatbot, a dashboard and a dream.
By the end, the judge can't find the original problem.

Your score is usually tied to the problem you were given.
Solving a different, cooler problem rarely earns bonus points.
It mostly earns confused faces.

Before you build anything, write the problem statement on a sticky note.
Every feature must point back to it.
If it doesn't, it waits for version two.
I run my own life off sticky notes, as [my desk setup post](https://www.rahuldk.in/blog/three-monitors-one-monster-can) proves.

## Don't over-engineer your hackathon project

The second classic mistake: building a cathedral in two days.

Microservices.
Three databases.
A custom login system nobody asked for.
And a demo that loads forever.

Judges don't score your architecture diagram.
They score what they can see working.

Pick the boring stack you already know.
Build the smallest thing that proves your idea.
Spend the saved hours polishing the one flow you'll demo.

When I started building [Track My Academy](https://www.trackmyacademy.com), the first night ended with a landing page.
Not an architecture.
A landing page I actually liked.
Small, finished things build momentum.

## What the jury doesn't want to hear

Some things quietly drain your score.

- **Facts the judge already knows.** They've read the problem statement. Probably several times today.
- **Statistics read off a slide.** Especially ones an AI tool produced five minutes earlier.
- **A tour of everything you made with AI.** Use AI tools, absolutely. Just don't make them the pitch.
- **Trying to impress instead of explain.** Big words, no working product. Judges spot it instantly.

On AI: I'm a fan.
I once chased free AI trials across [dozens of email accounts](https://www.rahuldk.in/blog/dozens-of-email-accounts-and-zero-shame).
But the judge is scoring your thinking, not your prompt history.

![An evaluator holds a pen over a blue clipboard, ready to write down scores](https://www.rahuldk.in/posts/how-to-win-a-hackathon-judges/judge-scoring-on-clipboard.webp)

*Photo: [Phil Hearing](https://unsplash.com/@philhearing) on [Unsplash](https://unsplash.com/photos/hand-holding-pen-over-a-blue-clipboard-eXcF6L9pEug)*

## A simple hackathon pitch structure

If you want a template, steal this one.

1. **Hello (10 seconds).** Handshake, how's your day, team intro.
2. **Problem and scope (20 seconds).** One line each. No essays.
3. **Solution (15 seconds).** One sentence, plain words.
4. **Demo (most of your time).** One flow, start to finish, working.
5. **How you built it (30 seconds).** Your stack, and one hard thing you solved.
6. **What's next (10 seconds).** One honest line. Then stop talking.

Then let the judge ask questions.
Answer them directly.
"I don't know yet" is a perfectly good answer.
Making something up is not.

## Hackathon tips for the questions round

Questions are where good teams pull ahead.

Listen to the whole question.
Answer the question that was asked, not the one you rehearsed.
Let the person who built that part answer it.
Keep answers to a few sentences.

If a judge points out a flaw, agree if it's true.
Then say how you'd fix it.
That shows judgement, which is exactly what they're measuring.

## FAQ

### How do hackathon judges score projects?

It depends on the event, so read the rules first.
Common criteria are technical difficulty, design, completion and impact.
Most judges weigh what they see working more than what they hear.

### How long should a hackathon pitch be?

As short as the rules allow.
Aim for under a minute before the demo starts.
Then let the working prototype do the talking.

### Do you need a perfect product to win a hackathon?

No.
You need one flow that clearly works and clearly fits the problem statement.
Polish that, and be honest about the rest.

## Go build something

If you're heading into a hackathon, good luck.
Keep it short, keep it focused, and show the thing.

I build products at [TrackMy Tech](https://www.trackmytech.in), and I'm always happy to talk shop.
[Book a call](https://calendar.rahuldk.in) if you want a second opinion on your idea.
Or read about [the app that arrived from 2006](https://www.rahuldk.in/blog/the-app-that-arrived-from-2006), my favourite cautionary tale.

---

Written by Rahul Dhileep Kumar, product engineer and founder (Track My Academy, TrackMy Tech). More posts: https://www.rahuldk.in/blog