Judging is the moment where all the work teams have done gets evaluated. A good judging process feels fair, energising, and constructive — even for teams that don't win. A bad one feels arbitrary, rushed, or biased. This chapter helps you design rubrics, choose judging formats, and run a process that participants trust.

A rubric is simply the scoring framework judges use to evaluate projects. Without one, judges default to gut feel — which leads to inconsistent results, implicit bias, and unhappy participants.

Most hackathon rubrics include some combination of these:

Innovation & creativity — Is the idea novel? Does it approach the problem in an interesting way? Or is it a rehash of something that already exists? Score higher for creative problem framing, not just flashy features.

Technical execution — Does the prototype actually work? How well was it built given the time constraints? Is the code clean, the demo functional, the architecture sound? Remember the 25% rule: teams achieve about a quarter of their ambitions. Judge what they built, not what they planned.

Impact & viability — Does this solve a real problem? Could it actually be used by real people? Is there a path from hackathon prototype to something meaningful? For business-focused events, this might include market potential and business model.

Presentation & communication — Can the team explain what they built, why it matters, and how it works? A great project with a terrible demo is harder to evaluate than a good project with a clear story.

A simple 20-point scale works well:

Each criterion scored 1–5:

Adapt the rubric to your objective:

Keep the total criteria to 4–6. More than that and judges spend too long per project, scores become inconsistent, and the rubric becomes overwhelming.

Teams present to all judges in sequence. Each team gets 2–5 minutes to present plus 1–2 minutes of Q&A.

Pros: Every judge sees every project. Judges can ask questions. Presentations create energy.
​ Cons: Time-consuming with many teams. Presentation skill matters a lot (which may or may not align with your event's goals). Later presenters may be disadvantaged as judges get tired.

Teams set up at their tables/stations. Judges rotate through, spending 3–5 minutes at each booth.

Pros: More efficient for larger groups. Teams demo naturally (on their own screens). Multiple judging conversations happen simultaneously.
​ Cons: Judges don't all see every project, so you need to coordinate which judges visit which teams. On-site teams may have an advantage over online teams (for hybrid events).

Teams submit demo videos (2–5 minutes). Judges watch and score on their own time.

Pros: Eliminates format bias (online teams aren't disadvantaged). Judges can review at their own pace. Videos can be re-watched for careful evaluation.
​ Cons: Less interactive — judges can't ask clarifying questions. Video quality varies. Some teams are better at video production than building.

Stage 1: All teams are scored (often asynchronously). Top teams become finalists.
Stage 2: Finalists present live (in person or via video call) to all judges.

Pros: Efficient for large events. Finalists get proper attention. Creates a natural dramatic arc.
​ Cons: Non-finalists may feel dismissed. Requires more time and coordination.

This is worth repeating from Chapter 11 because it's that important. Schedule a briefing session and cover:

The rubric in detail. Walk through each criterion. What does a "3" look like vs. a "5"? Use examples if possible. Judges who've calibrated together produce more consistent scores.

The context. Remind judges of the event's objective, the challenges, and what teams have been working on. Share the participant profile — are these mostly students? Professionals? First-timers?

Judging etiquette:

Format-specific guidance:

Rushing the judging. If judges feel pressured to score quickly, quality drops. Build enough time into your schedule.

Inconsistent scoring. Without a rubric briefing, one judge's "3" is another's "5". Calibration matters.

Presentation bias. A team with a polished presenter can overshadow a team with better technical work. Your rubric should balance this.

Format bias (hybrid events). On-site teams with face-to-face judge interactions tend to score higher than remote teams — unless you use asynchronous judging to level the field.

Not celebrating non-winners. The closing ceremony should acknowledge every team's effort, not just the winners. Applause for each project, shoutouts for creative approaches, and a general message of "you all built something real this weekend" goes a long way.

Key takeaways: