Hackathon judging rubric and criteria: real examples

A judging rubric is the list of criteria, with a weight for each, that every judge scores a project against. At Hackathon Raptors each event publishes its rubric on the event page before registration opens. Judges score every criterion on a five-point scale, independently, and a project's result is the weighted average across the judges who reviewed it.

Below are the rubrics from twelve of our recent online hackathons, what they have in common, how a judge works with one, and a template you can reuse.

JUDGE WITH US

Judge with these rubrics

Judge an upcoming Hackathon Raptors event. Each panel is matched to its subject. Write to hello@raptors.dev with a short note on your background.

Write to us

What our judging criteria have in common

Does it work. In all twelve rubrics. Usually 25 to 40 per cent; at a performance event it is measured by machine rather than judged.

The event's own challenge. In ten of twelve, at 25 to 35 per cent: constraint mastery, behavioural equivalence, judging integrity, impact. This is what makes each event's rubric its own.

Innovation. In eight of twelve, usually 10 to 20 per cent. It rewards an approach the judges did not expect.

Code quality. A criterion of its own in half the rubrics, at 15 to 25 per cent, and part of technical execution in most of the rest: readable, idiomatic code a senior reviewer would accept.

Presentation and demo. In five of twelve, and never above 15 per cent. A good demo helps; it does not carry a project.

Rubrics from twelve recent hackathons

Agentware 2026

27 to 30 November 2026

Build an AI agent that does real work on its own and can be trusted to run unattended, then prove it knows when to stop. Six tracks, from inbox and calendar agents to browser and developer-workflow agents, plus a pack of hostile test inputs released at kickoff.

  • Autonomy, 30% How much of the job runs with no human in the loop, verified by the trace and the demo.
  • Usefulness, 25% Does it do a job someone would genuinely hand over?
  • Reliability, 20% What happens on bad input, a failed API call or an ambiguous instruction.
  • Engineering, 15% Architecture, tool design, scoped permissions and documentation.
  • Demo, 10% One real, unattended run shown from trigger to result.

Up to 4 bonus points for guardrails, live monitoring, a kill switch and an audit trail.

Event site

Code Olympics Winter Championship 2026

18 to 21 December 2026

A constraint programming championship in four disciplines: Sprint (300 lines, standard library only), Precision (with your own tests), Endurance and Freestyle.

  • Functionality, 30% It works, handles bad input and runs from the README.
  • Discipline Mastery, 30% Measured against the discipline: line budget, test coverage, delivered scope or originality.
  • Code Quality, 20% Readable structure, sensible names, comments that explain why.
  • Innovation, 20% An approach the judges did not expect.
Event site

Speed Demon 2026

30 October to 2 November 2026

A performance-engineering championship: four tracks, each with a dataset and a slow reference implementation to beat on one machine.

  • Efficiency coefficient, 65% Measured by machine: time, memory, source size and dependencies, each as a ratio against the published reference.
  • Judges' review, 35% Judges read the code, the write-up and the live runs on structured forms, without seeing the machine scores.
Event site

DOGFOOD 2026

26 to 29 September 2026

Build the self-hosted submission and judging platform that would then be used to judge you, from registration through scoring and certificates.

  • Tier Completion & Correctness, 40% How far up the feature ladder, verified by an acceptance suite rather than the README.
  • Judging Integrity, 25% Role isolation in the backend, a defensible normalisation method, a readable audit trail.
  • Adoptability & Operability, 20% One command to running, documentation a stranger can follow, a way in and out.
  • Code Quality & Innovation, 15% Idiomatic code, a defensible schema, a decision a judge would reuse.
Event site

Zero Dependency 2026

28 to 31 August 2026

Build genuinely useful software using only the language standard library: an empty dependency manifest, verifiable on sight.

  • Functionality & Usefulness, 35% Builds with one command, runs, and does something a real person wants.
  • Zero-Dependency Craft, 30% How well the usual imports were replaced, documented honestly.
  • Code Quality & Idiom, 25% Reads as idiomatic to a senior reviewer in that language.
  • Innovation, 10% Something surprising built with nothing but the standard library.
Event site

Port Mortem (Code Resurrection) 2026

31 July to 3 August 2026

Port a real, widely used library into another language and prove the rewrite behaves exactly like the original.

  • Functionality & Reliability, 40% Passes the original test suite unmodified, with test files hash-verified.
  • Behavioral Equivalence, 30% Differential fuzzing, property tests and honest performance numbers.
  • Code Quality, 20% Idiomatic in the target language; escape hatches kept in check.
  • Innovation, 10% Bold language pairs, upstream bugs found, decisions worth adopting.
Event site

AI Slop Scan 2026

29 May to 1 June 2026

Build detection and filtering tools that make AI-generated noise visible and fixable, across eight tracks from code review to academia.

  • Detection Accuracy, 30% Catches what a human would miss without flagging clean content.
  • Practical Usefulness, 25% Fits a real workflow.
  • Technical Execution, 20% Works on real data, beyond cherry-picked demos.
  • Innovation, 15% A detection signal that is hard to fake.
  • Presentation & Demo, 10% Shown working on real content.
Event site

Code Olympics 2026

29 May to 1 June 2026

Each team draws a combination of constraints, line budget, domain and language, and builds a working program inside all of them.

  • Functionality & Reliability, 30% Does what it claims and handles edge cases.
  • Constraint Mastery, 25% Creative solutions within all imposed limits.
  • Language Adaptation, 20% Idiomatic use of the assigned language.
  • Code Quality, 15% Readable, maintainable structure.
  • Innovation, 10% Unexpected achievements within the constraints.
Event site

DX-Ray 2026

27 to 30 March 2026

Build diagnostic tools that reveal hidden friction in developer workflows: slow CI, flaky tests, stale docs, onboarding bottlenecks.

  • Problem Diagnosis, 25% Clearly identifies and visualises a real developer-experience problem.
  • Solution Impact, 25% Actionable insight that leads to measurable improvement.
  • Technical Execution, 20% Code quality, architecture and reliability.
  • User Experience, 15% A developer would actually use it.
  • Presentation & Demo, 15% Clear demo and honest limits.
Event site

MINDCODE 2026

27 February to 2 March 2026

Build software that improves mental health and wellbeing, across six tracks from pattern finding in personal data to community tools.

  • Impact & Vision, 35% Solves a real problem someone would use.
  • Execution, 25% It works, however it was built.
  • Innovation, 20% Fresh thinking and creative problem-solving.
  • User Experience, 15% Intuitive, accessible, designed for the user.
  • Presentation, 5% A clear story and a good demo.
Event site

sudo make world 2026

27 February to 2 March 2026

Build open-source tools that make the world better, across education, climate, health, civic and developer tools.

  • Impact, 35% A real problem, clear beneficiaries, a sustainable solution.
  • Technical Execution, 25% Architecture, working code, security considerations.
  • Innovation, 20% A novel approach and creative use of technology.
  • Usability, 15% Real people can use it; design and accessibility.
  • Presentation, 5% Clear communication, demo and README.
Event site

System Collapse 2026

30 January to 2 February 2026

Build things that use instability as a mechanic: feedback loops, entropy, adaptive rules, emergent behaviour and collapse.

  • Technical Execution, 40%
  • System Design, 30%
  • Creativity & Expression, 30%
Event site

How a judge works with a rubric

  1. Read the rubric and the brief before the batch arrives, so the weights are in your head and not on a second screen.
  2. Run what runs. Clone the repository, follow the README, and score what you saw, not what the README claims.
  3. Score each criterion on its own, on the five-point scale, and do not look at other judges' scores.
  4. Write feedback a team can act on. The written comments matter as much as the number.

A hackathon judging rubric template

Four criteria cover most events. Weights sum to 100, and every criterion is scored on the same five-point scale.

  • Does it work, 35% Builds from the README, runs, handles bad input, does what it claims.
  • Fit to the challenge, 30% How well it answers this event's specific brief or constraint.
  • Code quality, 20% Readable, idiomatic structure a senior reviewer would accept.
  • Innovation, 15% An approach the judges did not expect, or a known problem solved better.

Scale. 1: missing or does not work; 2: partly there, major gaps; 3: meets the brief; 4: clearly above the brief; 5: exceptional, a judge would reuse it.

Judge with these rubrics

Judge an upcoming Hackathon Raptors event. Each panel is matched to its subject. Write to hello@raptors.dev with a short note on your background.

Write to hello@raptors.devHow judges are selected