Hackathon project submission and judging
A project submission form should collect the demo, the code, what the team built during the event and how it works, then score each submission on the judging criteria. Judges start from a ranked list with reasons instead of fifty open tabs.
8 questions · about 5 min · edit anything after
Updated · by Ansorjon Juraev, founder
The questions, and why they're asked
In this order: the name first, the substance next, contact details and links last.
- 1
Project name
In the chat: “What's your project called?”
Short and first: teams are proud of the name.
- 2
What does it do?
In the chat: “In a few sentences, what does it do and who is it for?”
The judges' first question. The chat asks once for the user if it's missing.
- 3
What did you build during the event?
In the chat: “What did you build during the event itself, and what existed before?”
Most rules require new work. Asking directly is fairer than guessing from the repo.
- 4
How does it work?
In the chat: “How does it work under the hood? Stack, hardest part, anything clever.”
Lets technical judges see depth without cloning the repo.
- 5
Demo link
In the chat: “Link to a demo or video?”
The single most useful thing for judges.
- 6
Code repository
In the chat: “And the code repository?”
For checking what was built during the event.
- 7
Team members
In the chat: “Who's on the team? Names are enough.”
Needed for prizes; kept to names.
- 8
Email address
In the chat: “What's the best email to reach you?”
Asked near the end, once people are invested. The chat confirms it and catches typos like gmial.com.
Scoring rubric
Each response is scored once on these, with a reason for every score. The weights set the total; you can change them.
| Criterion | What scores well | Weight |
|---|---|---|
| Impact | A real problem for a clear user; useful beyond the event. | 30% |
| Technical depth | Hard parts solved well; more than gluing APIs together. | 30% |
| Execution | It works and the demo shows it; built during the event. | 25% |
| Creativity | A fresh idea or a surprising approach. | 15% |
Scores are advice for the people deciding. Nobody is accepted or rejected automatically.
Common mistakes
- Letting AI scores replace judges. Use them to order the list and spot what to look at, then decide as people.
- Not asking what was built during the event. It's the most common judging dispute.
A good answer and a weak one
For “How does it work under the hood? Stack, hardest part, anything clever.”
Good
“Next.js front end, a Python service running Whisper on the audio, then an LLM pass that turns transcripts into question–answer pairs. Hardest part was splitting long lectures without cutting sentences.”
Weak
“We used React and AI.”
Nothing a judge can weigh. The chat asks once for the hardest part.