Hackathon judging criteria: three ready-to-use rubrics.

• Teams know where to spend their time. If feasibility is worth 25%, nobody submits an idea without numbers.
• Submissions become comparable. Everyone answers the same questions.
• Judges use the same yardstick. Without written criteria, each judge rewards what they know best.
• Disputes close fast. You can show the sheet and the comments to any team that asks.
• In hiring, it is about fairness. Different candidates must be assessed on the same items.

Publish the criteria with the brief and include them in your rules. If a team asks mid-event how it will be judged, the answer should already be written down and identical for everyone.

For marketing, product, strategy or service hackathons where the deliverable is a presentation or a plan.

For hackathons where teams ship a working prototype: software, data, hardware.

When the goal is to meet people to hire, you assess how each person works. If the challenge runs in teams, ask for a short note on individual contribution. Reviewers should read the submission before they look at the CV, so the work is judged on its own. More on the hiring challenge page.

A peer-reviewed study by the University of Tartu and Carnegie Mellon (Nolte, Chounta and Herbsleb, 2020) found that skill diversity within the team is linked to projects continuing over time. So if you want the winning idea to move forward, favor teams with different skills and give weight to feasibility and fit with company strategy, as well as to presentation.

In the business rubric, for example, raise feasibility from 25% to 35% and take 5 points each off originality and presentation. Next steps: after the hackathon.

Copy the block, paste it into Excel or Google Sheets and split text to columns on the comma. Add one column per judge.

rubric,criterion,weight
business,Problem understanding,20
business,Customer value,25
business,Feasibility,25
business,Originality,15
business,Presentation,15
tech,It works,30
tech,Fit with the brief,25
tech,Technical quality,20
tech,Demo and documentation,15
tech,Originality,10
hiring,Problem analysis,25
hiring,Quality of work,30
hiring,Reasoning,20
hiring,Communication,15
hiring,Following the brief,10

A short scale with written descriptors narrows the gap between judges. Use the same words for every criterion.

The math: the score divided by 5 is multiplied by the weight. A 4 on a criterion weighted 25 is worth 20 points. Add the criteria for each judge's total out of 100. The team's result is the average of the judges' totals.

Even with the same scale, two judges can read "good" differently. Calibrate before scoring:

1. Pick a practice submission: from a past edition, with the team's permission, or one you write. Never from the current event.
2. Each judge scores it alone on the sheet.
3. Compare scores with the jury, criterion by criterion.
4. Where two scores are two points or more apart, the judges explain why. If needed, rewrite the descriptor with the jury.
5. Note how many minutes each judge took: that is the figure you need to estimate jury time.

• Vague criteria. "Impact" alone says nothing. Write impact on whom and on what: "impact on delivery times to customers".
• Too many criteria. Past five, each item weighs little and final scores look alike.
• Equal weights everywhere. If everything is 20%, you have not decided what matters most. Weights are your priorities.
• Criteria the brief never asked for. If the brief says nothing about costs, do not judge financial feasibility.
• Unwritten criteria. A judge may reward something that is not on the sheet, for example a team saying it was its first time with a technology. What is not on the sheet should not count; a comment on every score exposes it.
• Presentation outweighing substance. In a tech hackathon or a hiring challenge, the best speaker should not beat the best work.
• Hidden weights. Teams that do not know the weights work blind and dispute the result.

It depends on your AI rule: banned, allowed with disclosure, or allowed freely. The criteria stay the same; what you ask teams changes.

• Allowed with disclosure. Ask for a short note: which tools, for what, what the team checked. In the hiring rubric it falls under "Reasoning". During the pitch, judges can ask how the project was built.
• Allowed freely. Judge the result like any other. A generic language-model demo that does not answer the brief already scores low on "Fit with the brief".
• Banned. State in the rules what happens if the ban is broken and who decides.

Do not add an "AI use" criterion unless the brief asks for it.

It depends on three numbers only you know: how many submissions arrive, how many judges read each one and how many minutes one review takes. You measure the third during calibration. For large events, run two rounds: two judges per submission, then the whole jury on the finalists.

jury hours = submissions × judges per submission × minutes per submission ÷ 60

Example, with values to replace with your own: 100 submissions, 5 judges, 8 minutes per submission, 20 finalists.

In this example, two rounds bring each judge down to about 8 hours instead of 13.

Running the jury takes eight steps, from the sheet to the result:

1. Send brief, criteria and sheet before the event. Judges should know them before they see a single project.
2. Use one sheet for everyone, with criteria, weights and scale already filled in.
3. Have each judge score alone, then open the discussion. Discuss first and the loudest judge sets the tone.
4. Ask for one comment per score. Two lines are enough. They feed team feedback and settle disputes.
5. Have judges declare conflicts of interest. A judge who knows a team member well does not score that team.
6. Set the tie-break rule in advance. For example, the higher score on the most heavily weighted criterion wins; if it is still tied, the head judge decides.
7. Keep the sheets. You need them for feedback and for the next edition.
8. Share results with reasons. Along with the ranking, send each team its scores per criterion and the comments. Teams that lost learn where to improve.

Who to invite is covered in the guide to hackathon judges.

In the MARA builder, evaluation criteria are part of the challenge. MARA AI proposes them with the brief, rules, deliverables and timeline. You edit them, and nothing goes live until you approve. Once the challenge is published, the criteria are fixed and the same for everyone.

Your people evaluate. MARA calculates no scores, does not rank anyone and does not recommend who to pick: your jury decides scores and ranking, with its own sheet. Judges enter the challenge workspace, see the submissions and update the statuses in the participant list. If you need to, you can export everything to Excel or ZIP.

For the full process, read the step-by-step guide to organizing a hackathon. Still choosing a problem? Start from the hackathon themes.