Hackathon Judge Report
Evaluate a hackathon project like a rigorous judge: criteria scoring, evidence checks, and structured feedback.
Add this plan to a project to track work and checks.Open workspace
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