A hackathon is one of the few competition items where the entry does not exist until the clock starts. Teams get a time-boxed building window — often 12, 24 or 36 hours — to design, build and demo a working prototype from scratch, then present it to a panel that never watched the work happen. That changes what a fair judging sheet has to measure. There is no rehearsed performance to score and no finished craft object to inspect at leisure; there is a short live demo, a pitch, and a prototype that may still be held together with duct tape. Getting the rubric and the time-boxing right is what keeps a college tech fest’s hackathon track from turning into a popularity contest.
Why hackathon judging is a different shape
Every other build-and-present item on a school or college arts/tech fest — working models, science-fair exhibits, poster making — gives judges a finished object to walk past at their own pace. A hackathon gives them a live demo slot and nothing else: if the app crashes during the five minutes in front of the panel, that is what gets scored, not what worked an hour earlier. Three properties follow from that:
- The clock is part of the rules, not just the schedule. A fixed build window (commonly 12/24/36 hours) has to be published and enforced the same way a sports clock is — late submissions are a disqualification category, not a judging deduction.
- Team composition and division of labour matter. Hackathons are almost always Team items; the registration list should capture who built what, since a panel sometimes asks each member a question during the demo.
- The demo is scored live, once, with no replay. Unlike a pre-recorded short film or podcast entry, there is no second viewing — so judges need a structured scoresheet in hand before the first team walks up, not a blank page to fill in afterward.
Related reading: if your fest also runs a robotics competition or a coding competition, the same judging panel often covers all three tracks in one day — worth aligning score sheets so judges aren’t relearning a new format each time.
A 100-mark hackathon rubric
Most school and college hackathon tracks score across five weighted criteria. Publish the weights before the event so teams know what to optimise for.
| Criterion | Marks | What it checks |
|---|---|---|
| Problem fit & originality | 20 | Is the problem real and is the approach more than a copy of an existing product? |
| Technical execution | 25 | Does the prototype actually run? How much of it is real code/hardware versus a mockup? |
| Design & usability | 15 | Can a stranger understand and use it without the team explaining every click? |
| Presentation & demo | 20 | Clarity of the pitch, and whether the live demo actually shows the claimed features working. |
| Teamwork & use of time | 20 | Evidence the whole team contributed and the build window was used, not just the last two hours. |
Print this as a one-page score sheet per judge per team, with a blank line for a short comment next to each criterion — comments are what let an organiser defend a close result later.
Settle these before the build window opens
- Exact build window start and end time, and whether it is continuous or has a mandatory break/overnight pause
- Team size limits and whether solo entries are allowed
- What counts as “built during the event” — pre-written boilerplate/starter code allowed, but a finished prior project is not
- Allowed tech stack restrictions, if any (e.g. a themed track requiring a specific API or hardware kit)
- Demo slot length and whether a slide deck is required alongside the live demo
- Internet/resource access rules during the build window
Common disqualifications
| Issue | Why it’s a hard stop |
|---|---|
| Submission after the build-window deadline | The clock is the rule, not a suggestion — late builds break fairness to teams that stopped on time |
| Bringing a pre-built project and re-skinning it | Defeats the entire point of a time-boxed build |
| No live demo possible (app won’t run at all) | A hackathon scores a working prototype, not a slide deck of intentions |
| Team size over the published limit | Keeps the build-time-per-member comparison fair across teams |
Judging day: independent scoring, same demo slot for every judge
Unlike a short film or podcast entry that each judge can watch on their own schedule, a hackathon demo happens once, live, in front of whichever judges are in the room. Two practices keep this fair: rotate judges so every team gets a comparable mix of panel members across the day, and have each judge mark their own sheet independently before any panel discussion — talking it through first anchors everyone to whoever speaks first. If the fest runs multiple demo rooms in parallel to keep to schedule, use the same rubric and weights in every room so a team’s score depends on their build, not which room they were assigned.
Breaking a tie
- Higher technical execution score
- Higher problem fit & originality score
- Higher presentation & demo score
- Panel re-vote after a short live Q&A with the tied teams
Setting this up on eTalenter
Add Hackathon as a Team competition item and assign it to the relevant age group/division under Assign Competitions to Groups. Build the five-criterion rubric once under Judging Criteria so every judge scores on the same weighted sheet, and enter results through multi-judge scoring so each panel member’s marks are captured separately and averaged rather than argued into a single number on paper. If your fest runs demo rooms in parallel, each room is simply a separate judging round feeding the same leaderboard.
Want to see the score sheet and live leaderboard before deciding how to run your own track? Open the live demo and log in as a demo coordinator or judge — no sign-up needed. Questions while you’re setting it up: WhatsApp us at +91 96056 56508 or email support@etalenter.com.
FAQ
Can a hackathon be judged as an individual item instead of a team item?
Yes, if your fest allows solo entries, but most college hackathons require teams of 2–4 so the teamwork criterion means something.
What if a team’s prototype crashes during the live demo?
Score what the panel actually saw working. A pre-recorded backup demo video is a common fallback rule to publish in advance — decide whether it’s allowed before the event, not mid-demo.
Do all judges need to see every team?
Not necessarily if you run parallel demo rooms, but every team should see the same number of judges and the same rubric so scores are comparable.
Should pitch slides count separately from the rubric above?
No — fold presentation quality into the “Presentation & demo” criterion rather than adding a sixth category; it keeps the sheet quick to fill during a tight demo slot.
How long should a demo slot be?
Five to seven minutes (demo plus Q&A) is typical for a school/college-scale hackathon track with 10–20 teams judged in a single day.
Was this guide useful?
