From hackathon loser to hackathon jury: the loop is complete
· 5 min read · by Rahul Dhileep Kumar
I've lost hackathons, won a couple, organised one, and on 8 and 9 October I sat on a hackathon jury. What judging 20 to 30 teams felt like, the mistakes I recognised, and one fix every hackathon organiser should make.
Cover photo: Mirea Mazzei on Unsplash
On 8 and 9 October, I was on a hackathon jury.
Me. The guy who used to be on the other side, sweating.
The hackathon was at VISTAS. It was run by the Department of Computing Sciences and the Vels Innovation Council. More than 80 teams took part. Over the two days, I evaluated somewhere between 20 and 30 of them.
Somewhere in the middle of all that, I realised something. I've now sat in every seat a hackathon has.
Every seat at the hackathon table
Let me count them.
Participant. A hackathon is meant to be rapid, collaborative building over a short stretch. Rapid, yes. Collaborative, mostly. Calm, never. I've been the nervous one pitching at the end of it.
Loser. I've lost hackathons. It stings. Then, annoyingly, it teaches you something.
Winner. I've also won a couple. Master of Purple Fabric AI at the Intellect Design Arena hackathon. First place at HackAtom, the Russian Embassy hackathon. Both in 2026, both still slightly surprising. They live on my about page, where I can look at them.
Organiser. I organised Smart India Hackathon at my college. It's the biggest hackathon we run. Smart India Hackathon is a national event built around real-world problems. Organising one teaches you how much invisible work goes into two days of "fun".
Jury. And now, this. So yes, I guess the loop is complete.
Photo: fran innocenti on Unsplash
What being a hackathon jury is actually like
I expected judging to be relaxing. You sit. They present. You nod wisely.
It is not relaxing. It's exhausting.
You have to stay unbiased. Team twenty deserves the same judge as team one.
You have to stay focused through every single pitch. Even the fifth version of the same idea.
And you can't show any stress. Not a sigh, not a yawn, not a glance at your phone. The students are nervous enough already. They read every flicker on your face. I know, because I used to do the reading.
So you hold a polite, interested face for two whole days. It's basically acting. Nobody warned me there'd be acting.
Watching my own mistakes, live
Here's the uncomfortable part.
The mistakes I saw were my mistakes. The exact ones I made as a participant.
Over-engineering. Teams built huge systems for a two-day problem. I did that too. The demo always pays the price.
Drifting from the problem statement. Some teams started on the given problem. Then they wandered somewhere more exciting. The judge is still holding the original problem statement.
Trying to impress instead of showing. Lots of big words. Not enough working product. I recognised that one instantly. I used to be fluent in it.
I turned all of this into a practical guide. It's called how to win a hackathon, according to a tired judge. Send it to anyone with a hackathon this month.
Photo: Werner Pfennig on Pexels
Why judges lose focus after the fifth team
Most teams in my group had the same or similar problem statements. That happens when teams are grouped by theme.
It means the fifth explanation of a problem lands differently than the first. After that, attention slips. I felt it, even while trying hard not to.
Psychologists have names for things like this. Decision fatigue describes decisions getting worse after a long run of them. To be fair, the evidence for it is mixed.
Order effects are better documented. A Carnegie Mellon study found later performers got higher marks in Eurovision and figure skating. A 2017 study of song contests found something similar. Expert judges were swayed by a randomly assigned running number.
Hackathons aren't song contests. Although some pitches did have a chorus. The lesson still carries over: judges are human, and humans drift.
A note for hackathon organisers: mix up the topics
This is the one thing I'd change as an organiser.
Don't give one jury a stack of teams with the same topic. Give each jury a mix of problem statements.
The same topic ten times in a row flattens everything. The judge loses interest. Small differences start looking huge, or invisible. The evaluation stops being as fair as it should be.
A few other things I'd suggest:
- Mix themes in every jury group. Variety keeps judges sharp.
- Shuffle the running order. Don't let the same kind of team always land last.
- Give judges a short rubric. Four or five criteria, scored as they go.
- Build in breaks. Ten minutes between batches does more than coffee.
- Brief teams on timing. A firm pitch limit helps everyone, judges included.
None of this is expensive. It just needs someone to think about the judge's day. Usually nobody does.
What I'd tell my participant self
If I could go back to the nervous kid with the laptop:
- Read the problem statement twice. Build for that.
- Pick boring tools you already know.
- Make one flow work perfectly.
- Say hello to the judge like a human.
- Stop talking when the demo's done.
He wouldn't listen. He'd still over-engineer it. But it's nice to finally know the answers.
Learning by doing it badly first is basically my whole method. Bio-maths to computer science explains how that started. And exams, the office and a 1 a.m. gate shows how it's going.
FAQ
What does a hackathon jury do?
A hackathon jury evaluates team projects, usually against set criteria. That means watching demos, asking questions and scoring fairly. It also means staying sharp through a very long day.
Is being a hackathon judge hard?
More than it looks. You're making careful judgements back to back, for hours. And you're doing it with a calm face, for students who are very nervous.
What's the biggest mistake hackathon teams make?
From the jury side, building too much and showing too little. One working flow beats an ambitious system that won't load.
Thanks for having me
Thanks to the Department of Computing Sciences and the Vels Innovation Council for inviting me. And to every team that pitched. Especially the ones who reminded me of my own old mistakes.
I build products at TrackMy Tech. If you're organising a hackathon and want a judge, book a call. I'll bring my polite, interested face.