How hackathon judges score projects (with a sample rubric)

A clear way to score hackathon projects is a short rubric of four or five criteria, each with a weight, added up to a total. For AI projects, we suggest criteria that cover whether the thing works, whether the model use is meaningful, how well it solves a real problem, and how clearly the team presents it. Below is a sample rubric you can copy, adapt for your own event, or use to check your project before you submit.

This is a sample written for this article, not the rubric of any event. If you are entering an event, read the judging criteria it publishes.

What should a rubric for an AI project look at?

A useful rubric turns a few plain questions into scores:

• Does it work? Can a judge see it run on real input, not a mock-up?
• Is the AI doing real work? Is the model central to the result, or a thin layer on top?
• Does it matter? Is there a clear user and a clear problem?
• Is it well made? Is the build sensible for the time available?
• Is it easy to understand? Do the demo and write-up make the value obvious in a few minutes?

We would treat clarity as more than a bonus. If a judge cannot follow the demo, the other criteria are hard to score at all.

What does a sample rubric look like?

Here is a weighted rubric you can adapt. Each criterion is scored from 1 to 5, multiplied by its weight, and summed for a total out of 100.

Criterion	Weight	What it measures
Working demo	25%	The core flow runs end to end on real input
Use of AI	25%	The model is essential and used thoughtfully
Impact and usefulness	20%	A real user, a real problem, a plausible path to use
Technical execution	15%	Sound build choices, handles obvious failure cases
Presentation	15%	The demo, video and write-up are clear and honest

To turn a score into points: (score ÷ 5) × weight. For example, a 4 on Working demo gives 20 of 25 points.

If your event has a sponsor or partner theme, you could add a criterion for it or fold it into Use of AI. Adjust the weights so they still add up to 100.

What could each score level mean?

A rubric works best when every judge agrees on what a 1 and a 5 look like. These sample descriptions are written for AI projects.

Score	Working demo	Use of AI	Impact	Technical execution	Presentation
5	Runs live on new input the judge suggests	Model is central; instructions, tools or data are well designed; limits are handled	Clear user, painful problem, could be used next week	Clean structure, sensible choices, errors handled	Value is clear within the first minute; honest about limits
4	Runs live on the team's own real examples	Model is central, design is solid with minor gaps	Clear user and problem, path to use is plausible	Mostly solid, a few rough edges	Clear and well paced
3	Runs, but only on prepared input or with help	Model is useful but could be swapped for simpler logic	Problem is real but vague, or user is unclear	Works, but fragile	Understandable with some effort
2	Partly works; key steps are mocked	Model is a thin wrapper with little design	Problem is weak or assumed	Hard to follow, many shortcuts	Confusing or overclaims
1	Does not run, or only slides	AI is mentioned but not really used	No clear problem	Little working code	Missing or unclear

How can organizers keep scores fair across judges?

Different people score differently. Some are generous, some are strict. These habits can narrow the gap:

1. Calibrate before judging. Have every judge score the same two or three sample projects, then discuss differences until the score levels mean the same thing to everyone.
2. Use the level descriptions. Ask judges to point to the description that matches, not to score by feel.
3. Have more than one judge see each project. Average their scores, and discuss any project where judges differ by two or more points on a criterion.
4. Check panels against each other. If you split judges into panels and one panel scores higher across the board, compare the projects each panel ranked first before you combine results.
5. Write a short reason. One sentence per score helps with tie-breaks and with feedback to teams.
6. Agree on tie-breaks in advance. For example, the higher Working demo score wins.

Write the rubric down and share it with teams before building starts. Teams can then aim at the same target the judges are using, and there are fewer surprises at the end.

How can you use the rubric as a participant?

Score your own project against it a few hours before the deadline. Be strict. Then fix the lowest weighted score first. Often that means making the demo run on real input, or making it obvious where the model does the work. A short, honest note on limits is cheap to add and can make the presentation clearer than an extra feature would.

You can also use it earlier. When your team is choosing between ideas, ask how each one would score on Working demo and Use of AI. An idea that is hard to show running is a risky pick, however good it sounds.

Where to go next

Copy the rubric, adjust the weights to your event's goals, and run a short calibration round before judging starts. If you are building rather than organizing, test your project against it, then join an event at starfieldlabs.ai/events. If you want to run your own event, organisers can host a hackathon on Starfield Labs.