Hackathon Schedule Template, Demo Slots and Judging
Event guides9 min readUpdated
Plan a hackathon schedule backwards from the closing ceremony. Judging is the part that runs late, and Major League Hacking's organiser guide says it "usually takes around 2 - 3 hours, depending on the number of submissions and judges" (MLH Hackathon Organizer Guide: Judging Plan). So fix the closing time, reserve those hours before it, set the submission deadline before that, and only then fill in the hacking time, meals and workshops.
The same guide recommends expo-style ("science fair") judging, where judges walk to teams' tables, rather than having teams come to judges in a room, mainly because room judging is harder to make fair. Expo judging also suits a tight schedule, because many judges work at once.
How many judges do you need?
MLH gives a formula: judges needed = (projects × judges per project × minutes per project) ÷ minutes of judging time, rounded up. It recommends each project be seen 3 times and plans for 4 minutes per project: 2 minutes for the demo, 1 for questions and scoring, and 1 for the judge to walk to the next table. Its worked example is 175 projects, 3 rounds, 4 minutes each and 120 minutes of judging, which needs 18 judges.
For the template below, with 60 projects and a 90-minute judging window: 60 × 3 × 4 = 720 judge-minutes, divided by 90 = 8 judges. If you can only find 6, either extend judging to 120 minutes or drop to 2 views per project for the first round.
A 24-hour hackathon schedule template
Inputs, all of which you should change to fit your event:
- Doors open Saturday 09:00; closing ceremony ends Sunday 15:00
- 24 hours of hacking, Saturday 11:00 to Sunday 11:00
- 60 teams submitting projects
- Expo judging: 3 judges per project, 4 minutes per project, 90-minute window, 8 judges
- 6 finalists present on stage at about 7 minutes each (42 minutes), plus 3 minutes for the host's introduction
- Meals provided on site
| Day and time | Block | Length | Notes |
|---|---|---|---|
| Sat 09:00 | Check-in and breakfast | 60 min | Wi-Fi details and code of conduct at the desk |
| Sat 10:00 | Opening ceremony | 40 min | Welcome, rules, judging criteria, deadline, sponsor intros |
| Sat 10:40 | Team formation | 20 min | Help solo hackers find a team |
| Sat 11:00 | Hacking starts | Put the deadline on every screen | |
| Sat 12:30 | Lunch | 60 min | Hacking continues |
| Sat 14:00 | Sponsor expo and workshops | 2 to 3 h | MLH suggests a 2 to 3 hour window for the expo |
| Sat 18:30 | Dinner | 60 min | |
| Sat 21:00 | Optional activity or mini-event | 30 min | A break from screens |
| Sun 00:00 | Midnight snack | ||
| Sun 07:30 | Breakfast | 60 min | Remind teams how to submit |
| Sun 11:00 | Submission deadline, hacking ends | Form closes; no exceptions without a stated rule | |
| Sun 11:00 | Buffer: judge briefing, tables set up, late upload problems | 30 min | Judges get their table assignments |
| Sun 11:30 | Expo judging | 90 min | Each project seen by 3 judges |
| Sun 13:00 | Judges deliberate; hackers have lunch | 30 min | Pick 6 finalists |
| Sun 13:30 | Finalist demos on stage | 45 min | 6 teams × 7 min = 42, plus 3 min host introduction |
| Sun 14:15 | Final deliberation and checks | 15 min | Host runs a sponsor thank-you or a raffle |
| Sun 14:30 | Closing ceremony and prizes | 30 min | |
| Sun 15:00 | End |
From the deadline to the end of the closing is four hours. Shrink it only by shrinking judging, never by squeezing the buffer after the deadline: that half hour is where upload failures, missing videos and judge no-shows get fixed. MLH also says to block out enough time for each judging phase "with some buffer time in between" (MLH: Detailed Run of Show).
For a longer event, MLH suggests first deciding between a 2-day and a 3-day format; the shape above stretches by adding more hacking time and a second night.
How long should a hackathon demo be?
Short, and the same for every team. Two sizes cover most events:
- Expo round: MLH plans 2 minutes of demo plus 1 minute of questions and scoring per judge visit, and recommends that hackers submit "2 minute videos", which should be "a demo of their hack, not a presentation" (not needed for expo judging itself, but useful in final deliberations).
- Finalist round on stage: MLH says to plan about 7 minutes per team, 3 to 5 minutes presenting and about 2 minutes to set up the next group.
The stage round is where minutes leak, almost always in the changeover. Cut it down by:
- Collecting finalists' slides or videos onto one presentation machine during deliberation.
- Testing every finalist's laptop on the stage display before the round if they must demo live.
- Keeping the next team on deck at the side of the stage, laptop open.
- Telling teams their slot length the moment they're named finalists, then once more when they're on deck.
For timekeeping conventions in strict-slot formats, including how to stop a pitch fairly when time is up, see timekeeping for debates, pitches and open mics.
A judging flow that holds to time
- Publish criteria at the opening ceremony, not on Sunday morning.
- Assign tables to judges in advance so each project gets its three views. MLH advises that judges shouldn't keep seeing the same set of teams, so mix the assignments.
- Brief judges for 10 minutes in the buffer: criteria, scoring form, a strict 3 minutes at each table (MLH's 4-minute plan includes a minute to walk), where to go if a team isn't there.
- Keep one person on the clock. Call "two minutes left in judging" across the room, and close scoring on time.
- Rank, don't average. MLH suggests stack ranking: each judge names their top 3 projects, worth 3, 2 and 1 points, and the panel reviews the top 3 to 5 before deciding.
- Check winners before announcing. MLH recommends a cheating check on all winners before they are announced. Build it into the deliberation time, not after it.
Deadline reminders that actually land
Announce the deadline as a clock time with the time zone, and repeat it at a predictable rhythm through the venue's screens, the event chat and the PA:
- T−6 hours: "Submissions close at 11:00 Sunday. Start your demo video before breakfast."
- T−2 hours: "Two hours left. Make sure one person on your team has started the submission."
- T−1 hour: "One hour. Submit a draft now; you can edit it until 11:00."
- T−15 minutes: "Fifteen minutes. If you have upload trouble, come to the help desk now."
- T−0: "Hacking is over. Hands off keyboards, and well done."
Decide before the event what happens to a team with a genuine upload failure at 10:59, write it in the rules, and apply it to everyone.
Questions from the audience
If the closing includes a sponsor talk or a fireside chat, collect audience questions with a link instead of a roaming microphone. It's quieter, and a moderator can pick the best questions while the speaker is still talking. The details are in how to run a live audience Q&A.
For the finalist round, StageClock lets you build each team as segments, for example "Team 1 demo" (4:00, Auto-advance), "Judges' questions" (1:00) and "Changeover" (2:00), with the countdown on a Stage Display the presenters can see. The +30s and −1m buttons handle a slow changeover, and the Audience Q&A link collects questions you approve before they reach the Speaker Monitor. You'll need a Google account to sign in, and building your own segments needs a paid plan beyond the demo event; check the pricing page.
The broader logic of slot design, chairs and buffers is in the conference timing guide, and if your closing ceremony slips anyway, when an event runs late covers where to take the time back.
Frequently asked questions
Can we run a virtual hackathon on the same schedule?
Mostly. Swap expo judging for submitted demo videos that judges watch on their own schedule, and keep a live finalist round. Allow more buffer after the deadline, because upload problems are harder to fix remotely, and state every time with its time zone.
Should judges also be mentors?
They can, but don't schedule anyone to mentor in the last hours of hacking if they're judging straight after. They need the buffer to be briefed and to read their table list.
Key takeaways
- Plan backwards from the closing: judging usually takes 2 to 3 hours, and the deadline goes before that with a buffer of at least 30 minutes.
- Work out judges with the formula: projects × views × minutes per project ÷ judging minutes. 60 projects, 3 views, 4 minutes and 90 minutes needs 8 judges.
- Use expo-style judging for the first round and a short, identical slot for every finalist on stage, about 7 minutes including changeover.
- Most stage-round overruns come from changeovers, so preload slides and keep the next team on deck.
- Repeat the deadline as a clock time at fixed intervals, and decide the late-upload rule before the event.