A one-day hackathon has three moments where someone has to decide something about people: who works with whom at 9:30, who presents when at 4:00, and which judge looks hardest at which team. Each of those decisions is small, and each one can sour the day if it looks rigged. This guide walks through a real-sized event, 26 people and three judges, using three tools in sequence, with the numbers worked out so you know what the draws can and can’t promise before you stand up and run them.
The event we’re planning
The setup is a common internal hackathon. Twenty-six people signed up: 12 developers, 6 designers, 5 people from product, and 3 who didn’t say what they do (a support lead, a finance analyst and someone from legal who wants to see what the fuss is about). There are three judges. Doors open at 9:00, teams form by 9:30, hacking runs until 4:00, demos start at 4:00 sharp, and the room is booked until 5:00.
Twenty-six people make six teams of four or five. Fewer teams means bigger groups where somebody ends up watching; more teams means groups of three that lose a person to a meeting and stall. Six is the number we’ll use throughout.
Step 1: balanced teams, not just random ones
A plain random split of 26 people into six teams will regularly produce a team with no designer, or a team with four developers and nobody who has written a product spec. With 6 designers and 6 teams the odds of a clean one-designer-per-team spread from a blind shuffle are poor, and the organiser who reruns the draw until it looks right has just stopped being random in front of everybody.
The Balanced Team Generator solves this with tags. Each person goes on their own line with a tag in square brackets:
Priya [dev]Tom [design]Grace [product]Lena(no tag)
Set Number of teams to 6 in Options and click Build balanced teams. The tool groups people by tag, shuffles each group, and deals them out round-robin. The detail that matters for an event like this is that the deal does not restart at Team 1 for each tag. It carries on from wherever the previous tag stopped. Here is what that produces with our list, in the order the tags first appear (dev, then design, then product, then the untagged):
| Team | Size | Dev | Design | Product | Untagged |
|---|---|---|---|---|---|
| 1 | 5 | 2 | 1 | 1 | 1 |
| 2 | 5 | 2 | 1 | 1 | 1 |
| 3 | 4 | 2 | 1 | 1 | 0 |
| 4 | 4 | 2 | 1 | 1 | 0 |
| 5 | 4 | 2 | 1 | 1 | 0 |
| 6 | 4 | 2 | 1 | 0 | 1 |
Twelve developers divide evenly, two per team. Six designers divide evenly, one each. Five product people across six teams can’t, so one team goes without, and it is Team 6, because the deal had reached Team 1 again when product started. The three untagged people are dealt last and land on Teams 6, 1 and 2, which is what tops Team 6 back up to four. Team sizes never differ by more than one.
Three practical points before you press the button:
- Tags are matched exactly.
[Dev]and[dev]are two different tags, and so are[design]and[designer]. If you collect sign-ups from a form, tidy the tag column before pasting, or you’ll get a “balanced” split of two separate developer groups. - Decide the shortfall deliberately. Which team misses out on a product person depends on tag order, which is the order the tags first appear in your list. If you would rather the team without a product person get a designer’s attention instead, that is a conversation to have before the draw, not after.
- Type a seed. The Options panel has a Seed field. Write something like
hack-oct-2026on the whiteboard, type it in, and the same list always produces the same six teams. When someone asks at lunch whether you moved their friend onto their team, you can rerun it in front of them. Leave the field blank and every click is a fresh draw.
The result can be copied as text (one line per team) or exported as CSV with team, member and tag columns, which is handy if you’re putting team names on a slide.
Step 2: the demo schedule
At 4:00 six teams need to present to a room that will lose patience around 4:45. The demo order tool does two things at once: it shuffles the presenters, and it labels each slot with a time box based on Minutes each in Options.
The default is 5 minutes. For a hackathon, 5 minutes of demo plus a question or two plus a laptop swap is closer to 7, so set it to 7. Paste the six team names (one per line), click Order presenters, and you get a numbered lineup reading 0–7 min, 7–14 min, and so on to 35–42 min. Those are offsets from the start, not clock times, so read them as 4:00 to 4:42. That leaves 18 minutes of the hour for judges to confer and announce, which is about right.
Why shuffle at all? Because every slot carries a story. First goes to a fresh room and sets the bar. Last goes to a tired room but is freshest in the judges’ minds when they score. Any team has a 1 in 6 chance of either extreme slot, so 2 in 6 of being first or last. If you let teams volunteer, the most confident team takes first and the team whose build broke at 3:50 asks to go last, and everyone reads that order as a signal. A visible shuffle at 3:55 has no signal in it.
The earlier piece on demo days covers the time-boxing side in more depth. The new part here is what you do with the order once you have it.
Step 3: matching judges to teams
Everyone watches every demo, but with three judges and six teams it works better if each judge owns two teams: they visit those teams twice during the day, ask the harder questions, and write the scoring notes. That is a matching problem, and the Two-List Random Matcher handles it, with one quirk you need to know about.
Put the six teams in List A and the three judges in List B, then click Match A → B. The matcher shuffles List B and walks down List A, giving each entry the next judge in the shuffled list. When it runs out of judges it shuffles them again and carries on. So with six teams and three judges, each judge gets exactly two teams, which is what we want, and a note under the result says that each judge was used twice.
The quirk is that each pass through the judges covers the next three lines of List A. Teams 1, 2 and 3 always get three different judges, and so do Teams 4, 5 and 6, so a judge’s two teams are always one from the top half of the list and one from the bottom half. Which pairs form is random (Team 1 is equally likely to share a judge with Team 4, 5 or 6), but Team 1 and Team 2 can never share one. If you type the teams into List A in the order the Balanced Team Generator numbered them, that top-half, bottom-half split is the same every time you run it.
The fix is the order from Step 2. Type the teams into List A in their demo order, not their team number. Note that the demo tool’s Copy button gives you one line joined with arrows, which the matcher would read as a single item, so type them one per line. Because the demo order is itself a uniform shuffle, combining the two gives every way of splitting six teams into three pairs and handing those pairs to three judges an equal chance. There are 90 such assignments (6! divided by 2 for each of the three pairs, which is 720 ÷ 8), and each is equally likely.
That also has a side effect: every judge has one team demoing in the first half of the running order and one in the second, so nobody’s scoring is bunched at one end of the afternoon. Back-to-back is still possible across the middle: the judge with slot 3 also gets slot 4 about one time in three.
If you want this step to be repeatable too, the matcher has its own Seed field. Use a different seed from Step 1.
Step 4: spot prizes for everyone else
Most hackathons have a pile of sponsor swag or small prizes beyond the judged ones: say 8 items for 26 people. The same matcher does this job, but which list goes where matters, because of the same reuse.
If you put the 26 attendees in List A and the 8 prizes in List B, the prizes are reused: every prize goes to three people, and two of them, picked at random, to a fourth. That is a correct output for “everyone gets something from a short list of types”, and the wrong one for eight physical items.
Put the prizes in List A and the attendees in List B. Now every prize is matched to a different person from the shuffled attendee list, and the 18 people left over get nothing, which is honest. Each attendee has an 8 in 26 chance of winning something, about 31%, and a 69% chance of going home with just the stickers. Judges and organisers should not be in List B; it is easier to agree that at 9:00 than at 4:55.
The post on matching two lists covers the general case. Here the only thing to remember is: the shorter list goes on the left when each item may be used once.
What gets saved, and where
All three tools keep your lists in the browser you used, so if you build the team list on your laptop on Thursday, it’s still there on Friday morning on that same laptop. They are not shared between devices, and nothing is sent to a server. Each tool also keeps its last ten results in a Recent results list on the page, which is the easiest way to answer “what was the order again?” at 4:20.
If two organisers are each running a different step on their own laptops, that’s fine. If they are both running the same step, decide who owns the official draw, or use a seed so the two laptops agree.
A timetable you can copy
| Time | Step | Tool | Setting that matters |
|---|---|---|---|
| Thursday | Collect names and roles, tidy tags | Balanced Team Generator | One tag spelling per role |
| 9:20 | Draw teams on screen | Balanced Team Generator | Number of teams 6, Seed written on the board |
| 9:30 | Teams announced, export CSV | Balanced Team Generator | |
| 3:55 | Draw demo order on screen | Demo order | Minutes each 7 |
| 4:00 | Judges matched to teams | Two-List Random Matcher | Teams in List A in demo order |
| 4:55 | Spot prizes drawn | Two-List Random Matcher | Prizes in List A, attendees in List B |
Where the tools stop
None of this measures skill. Tags are coarse: two developers on one team might be a principal engineer and an intern, and the generator only sees [dev]. If you know a team is lopsided in a way the tags can’t see, add a tag that expresses it ([dev-senior], [dev]) rather than editing the result by hand after the draw.
The demo order doesn’t enforce its own time boxes. It tells everyone when their slot ends; someone still has to hold up a card at minute six.
And the judge matching is only as fair as the judges. Randomising who scores whom removes the suspicion that a judge picked their friends’ team, which is the one thing a draw can remove. It does not stop a judge from preferring polished slides over working code. A one-line rubric handed out at 9:00 does more for that than any tool.
Run the three draws on a projector, keep the seeds visible, and the arguments that usually happen at 4:50 tend not to happen at all.