Hackathon judges: who to invite and how the jury works.

It depends on how many submissions arrive and how much time each judge can give. Pick judges with different backgrounds, and technical judges for a technical event. Then three practical rules: size the jury to the number of submissions, keep a reserve judge or two, and pick an odd number to cut down on ties.

An example line-up by format, to adapt to your own numbers:

• Whoever decides what comes next. The hiring manager, the executive with the budget, the problem owner. If nobody on the jury can decide, the prize stays a promise.
• People who know the subject. One or two judges who can tell a feasible proposal from one that only looks feasible.
• People with time, before people with a name. The time a judge can give matters more than their profile. A well-known name who reads three submissions out of thirty causes more problems than they solve.
• An executive, for internal events. An executive on the jury shows colleagues that the company takes the results seriously, and it boosts sign-ups.
• A partner. Offer a jury seat to hesitant partners: they get visibility, you get a promotion channel. See how to promote a hackathon.

Keep mentors who coached a team during the event off the jury: they already know one submission better than the rest.

Early, and with a precise commitment. Confirm the judges before sign-ups open, so you can feature them in your promotion, and block their calendars straight away. Confirm mentors at least three weeks before the event. Put hours in the invitation, not "a bit of your time": the calculation is further down, under "How much time does each judge need?"

Judge invitation letter (copy and fill in):

Subject: Judging [event name], [dates]: about [hours] hours

Hi [name],
On [dates] we are running [event name], a [format] for [participants].
The problem: [one sentence].
We'd like you on the jury because [role or expertise].

What we are asking:
- a criteria briefing on [date], [length];
- scoring [number] submissions between [date] and [date];
- the awards on [date], [place or link].

You will get the brief, criteria and scoring sheet by [date].
If you know anyone taking part, please tell us first.
In return: [visibility, logo, a prize category, time with the teams].

Can you let us know by [date]?
[signature]

Hold a meeting on the criteria before judging, so that everyone applies them the same way. One hour covers six points:

1. The problem, explained by its owner: what the company or university actually needs.
2. Criteria, weights and scale, read together on the sheet.
3. Calibration on a practice submission, before scoring: each judge scores the same submission alone, then you compare. The steps are in the judging criteria guide. Time each judge: that is your own minutes-per-submission figure.
4. Conflicts of interest, declared in writing.
5. The tie-break rule, already in your rules.
6. Dates: when to score, when to discuss, when results go out. Send reminders: among other commitments, judging slips to the bottom of the list.

If there is a final presentation, give every team the same outline along with the brief. The jury can then compare demos point by point, on the same elements. The six points:

1. Problem: what the team understood, and for whom.
2. Approach: what they chose to do and why, with the option they dropped.
3. What it actually does: a demo of what works today, not of what it will do.
4. Evidence: data, tests or feedback that back the proposal.
5. Limits: what is missing and what they could not check.
6. Next step: what it takes to move forward, and who does it.

Same time for everyone, with a visible timer. Ask teams to upload their submission on MARA before the demo: the jury looks at the submitted work first, then the presentation. Official answers, on timing or format for example, go out only in announcements and in the challenge Q&A, which everyone can see.

Minutes per submission depend on the work: a ten-page plan takes longer than a short demo. Use the minutes you timed during calibration. The formula:

hours per judge = submissions they read × minutes per submission ÷ 60

For large events, assign each submission to several judges rather than every judge to everything. Example with values to replace, the same as in the judging criteria guide: 100 submissions, 5 judges, 8 minutes each, 20 finalists.

With two rounds each judge works about 8 hours instead of 13, and every submission is still read by at least two people. Add the briefing and the final discussion. State in your rules how many finalists go through and how they are picked, for example the average of the two first-round scores.

A judge declares a conflict when they are close to someone taking part:

• relative, partner or close friend;
• direct colleague or line manager, in an internal hackathon;
• thesis supervisor or tutor, in a university hackathon;
• mentor of that team during the event.

The declaration comes before anyone sees the submissions. A judge with a conflict does not score that submission: a reserve judge does, or the average of the others counts. The rules template already bars judges and their families from taking part.

For ties, set the rule in advance, for example the higher score on the most heavily weighted criterion, then the head judge's casting vote. An odd number of judges makes ties rarer.

A published rubric is not enough: people who worked for days want to know how they were scored and to see proof that their work was read.

• One comment per score. Two lines written while scoring become the team's feedback.
• A results date announced in advance, and kept.
• The same message to everyone, at the same time. People who did not make it should hear when the winners do.

One sheet per submission. Use the criteria and weights from your rules.

Judge: [name] · Submission: [team or code] · Conflict of interest: [no / yes, not scoring] · Date: [date]

Question for the team at the final: [optional] · Put forward as a finalist: [yes / no]

On MARA the criteria are part of the challenge. MARA AI proposes them with the brief, rules, deliverables and timeline, and you edit them. Once published, they are fixed and the same for everyone. Your people evaluate: MARA gives no scores, does not rank anyone and does not recommend who to pick.

Submissions arrive in one place. Judges enter the challenge workspace, see the submissions and update the statuses in the participant list. If you need to, you can export everything to Excel or ZIP. Announcements let you share dates and results with everyone at once. You can send individual notes to people who submitted. Everyone who submits gets a verifiable certificate and a portfolio of their work, winners or not. The full H-ACK story is here. The whole process is in the guide to organizing a hackathon. Back to the home page.

• H-FARM College, "Beyond the CV: MARA, the platform born from the challenges of H-FARM College" (H-ACK figures). college.h-farm.com