Hackathon Judging Criteria

Requirements come before taste

Devpost says participants should check eligibility rules, build requirements, required tools, URLs, and demo submission limits before building. A good idea can still lose if the repo is private, the demo is missing, or the team used the wrong required tool.

Karen Bajza-Terlouw told Devpost she checks whether the submission fulfills the requirements first. Warren Marusiak said it is hard to give full points if the project does not nail the prompt. Treat the prompt like a contract.

Most rubrics score the same proof

Devpost lists common criteria such as technological implementation, ease of use, demonstration, potential impact, idea quality, and design. Different events rename the buckets, but the judge is usually asking the same question: does this work, matter, and explain itself fast.

HackAI 2025 judged technical implementation, innovation and creativity, usefulness and impact, execution, clarity of explanation, and relevance to track. AI ATL 2025 used technology, completion, design, and learning criteria. Those are build priorities, not decoration.

The judging format changes the strategy

MLH recommends science-fair style judging where every team gets a chance to demo in the first round after submissions are due. It also recommends each project be seen by 3 judges, with 4 minutes per judge per project as a planning assumption.

That format rewards a short repeatable explanation. You cannot count on one perfect stage moment. You need a compact pitch, a reliable demo path, and a project page that still works after the judge walks away.

Weighted rubrics are not top-pick rooms

HackHQ's sample weighted rubric gives innovation and creativity 30 percent, technical implementation 25 percent, business value and impact 25 percent, and presentation 20 percent. In that room, one weak bucket can pull the whole score down.

HackHQ also recommends rubric scoring for fewer than 50 submissions and top-pick judging when there are 50+ submissions and speed matters. In a top-pick room, memorability matters more. Your one-sentence proof needs to survive judge discussion.

Sponsor tracks are separate games

DevNetwork AI + ML Hackathon 2025 used progress, concept, and feasibility for Round 1 judging. AI ATL 2025 had sponsor tracks from Google Cloud, PrizePicks, Microsoft for Startups, Drive Capital, Solana, Gemini API, Vultr, Snowflake, ElevenLabs, MongoDB, and .Tech.

If you enter a sponsor track, prove the sponsor-specific requirement plainly. A great generic app can lose to a smaller build that shows the required API, dataset, chain, or platform in the main demo path.

Use judge math to choose scope

MLH says its 2026 season saw an average submission rate of 1 project per 4 checked-in hackers. It also gives a judge-count example: 175 projects, 3 rounds, 4 minutes per project, and 2 hours of judging requires 18 judges.

That math explains why subtle features disappear. Judges do not have time to inspect your whole repo. Make the winning evidence visible in the demo, project description, screenshots, and first page of the README.

Sample weighted judging sheet

Source: HackHQ's sample weighted rubric assigns innovation and creativity 30 percent, technical implementation 25 percent, business value and impact 25 percent, and presentation 20 percent. Use this sheet only when the event has no custom weights.

Pass or fail gate: eligibility, allowed tools, required links, demo length, repo visibility, AI credit where rules require it, and sponsor-track requirement. Source: Devpost's judging criteria guide names eligibility, required tools, URLs, and demo limits as baseline requirements.

Weighted score: innovation 30, technical 25, impact 25, presentation 20. Score each 1 to 5, multiply by the weight, then total out of 100. A 4 out of 5 in innovation becomes 24 points.

Team use: choose features by the sheet before building. If a new feature cannot raise a weighted bucket or clear the pass or fail gate, cut it before it steals demo time.

FAQ