Hackathon Judge Report
Evaluate a hackathon project like a rigorous judge: criteria scoring, evidence checks, and structured feedback.
The route
5 steps to Done
- 01
Set up the rubric
Fix the criteria and standards before seeing any project.
Preview prompt + verify gate ▾ Hide ▴
Set up my judging rubric. I will paste the competition's criteria below. Produce: each criterion with its weight and a 1-10 scale anchored with concrete descriptions (what a 3, 6, and 9 look like - observable behaviors, not adjectives); the functionality-verification checklist applied to every project (core action works, data persists, no dead buttons on the main path); and the report template (scores, evidence, strengths, issues, potential). Lock it before judging starts. CRITERIA: [paste here]
- ✓ Each criterion has anchored scale points
- ✓ The verification checklist is universal
- ✓ The template is fixed before judging
- 02
Use the project hands-on
Judge the product, not the pitch - use it like a real user.
Preview prompt + verify gate ▾ Hide ▴
Evaluate the project hands-on: follow the submission's own instructions for the fastest path; complete the claimed core action yourself; test persistence (do a thing, refresh); click every visible control on the main screens (note dead/fake ones); try one invalid input and one wrong-path action; note load speed and mobile if claimed. Record what you observed neutrally - facts before scores.
- ✓ The core action was performed personally
- ✓ Persistence was refresh-tested
- ✓ Dead/fake controls are listed
- 03
Score with evidence
Apply the rubric with receipts for every number.
Preview prompt + verify gate ▾ Hide ▴
Score the project: for each criterion, assign the score per the anchors and write the evidence line justifying it (what was observed that matches the anchor); apply the functionality findings honestly (a dead core path caps relevant scores - state the cap rule); compute the weighted total; flag any score given without direct observation and resolve it by re-checking.
- ✓ Every score cites an observation
- ✓ Functionality caps applied where earned
- ✓ No unobserved scores remain
- 04
Write actionable feedback
Feedback the team can use beats generic praise.
Preview prompt + verify gate ▾ Hide ▴
Write the feedback sections: 3 genuine strengths (specific - name the feature/decision and why it works); 3 priority issues (specific - what is broken/weak, how it was found, and the concrete fix); the potential note (what this could become and the single highest-leverage next step); and one line on the fastest way to improve their score against the criteria. No filler compliments, no vague criticisms.
- ✓ Strengths name specifics
- ✓ Issues include reproduction and a fix
- ✓ The next step is single and concrete
- 05
Calibrate across projects
Consistency is fairness - normalize before finalizing.
Preview prompt + verify gate ▾ Hide ▴
Calibrate the final results (when judging multiple projects): re-read the first projects' scores after finishing the last (early-judging drift is real); compare same-score projects for genuine equivalence per criterion; verify the cap rules were applied uniformly; adjust with noted reasons where inconsistent; produce the final ranked table with each project's scorecard and one-line summary.
- ✓ Early projects were re-checked after the last
- ✓ Equal scores mean equivalent evidence
- ✓ Adjustments carry noted reasons