Run a Hackathon From One Join Link

An organization set up for hackathons can now run the whole event on AlgoArena. People enter through one link and form teams, each team hands in one project, and judges score the hand-ins against a rubric, a short list of criteria, to get a ranked list. Until this change, an assessment marked as a hackathon behaved almost exactly like any other assessment. There were no teams, no hand-in, and nowhere for judges to keep scores.

Entering the event

In an organization that runs in Hackathon mode, a new assessment can be marked as a hackathon at the setup step that asks what the assessment is for. On a hackathon, the Invite tab holds the event's settings in place of the email invite form, because a person invited by email would not be on any team. The organizer turns on an open join link and can cap how many people enter. They also set the largest team size, from one to four people, and can add tracks, which are themes that teams choose between.

Whoever opens the link signs in, reads how the event works, and then starts a team, joins one with a team code from a teammate, or enters alone as a team of one. Team codes are six characters long and leave out I, O, 0, and 1, so a code read aloud or copied off a projector slide is hard to get wrong. Before anyone starts, the page says what is recorded and that judges can watch a replay of each person's work.

Each person then starts their own attempt with its own workspace, AI, and timer, so teammates never type in each other's editors. We chose this because two AI agents, which edit files on their own, overwrite each other's work when they share one folder. The AI building tools we studied give each person or agent a separate copy for the same reason.

One repo per team

When the event includes a Machine question, which runs on its own cloud computer with a terminal, each team shares one Git repository (a repo). Every member pushes, or uploads, their work to their own branch of the repo, named after them. When every teammate starts from the same files, the repo's main branch begins with those starter files, so two teammates who edit different files can combine their branches later without a clash. Any API key the question hands out is kept out of the repo, since the organizer may make the repo public later.

Other kinds of question have no repo. Each person's code stays in their own attempt, and the team picks whose attempt the judges see when it hands in.

Handing in

Any member can hand in for the team and can change the hand-in until the event ends. On a team repo, a hand-in names a branch, or one commit on it. On other questions it names whose attempt the judges should open. Every hand-in also takes a description of what the team built and an optional demo link. If a hand-in is refused, for example because of a bad demo link, the reason appears next to the Hand in button.

Owners, admins, and organizers can take someone off a team before the event ends. The team gets the open place back. The person who was removed keeps their attempt and their branch and can start or join another team. If the team's hand-in pointed at their work, it is cleared, so the team has to hand in again before hand-ins close. A removed person who tries to push is told they were removed from the team.

Ending the event

Ending the event takes one button on the judging page and cannot be undone. It closes hand-ins for every team and stops every push to a team repo. Any attempt still open is submitted, the same way an attempt is submitted when its time runs out. A hand-in that named a branch but no commit is pinned to the commit the branch was on at that moment, so judges see the code as it stood when the event ended.

The organizer can then make every team repo public. The confirmation warns that any key a team committed to its repo becomes public too. Repos that could not be made public are listed by name with a Try again button.

Judging

Anyone in the organization running the event can judge. Outside judges join the organization through the normal team invite, usually as viewers. The judging page lists each team with its hand-in, its members, and links to each member's report and replay. On hiring and training assessments, reviewers and viewers do not see the replay. On a hackathon every judge does, because the replay answers a question judges ask about every team, which is whether each member built part of it.

The starting rubric has four criteria, each with a short question for the judge: Technology, Design, Completion, and Learning. The organizer can rename or rewrite them, and use up to eight, until the first score is saved. From then on the rubric is fixed, so every team is scored against the same one. Each judge gives every criterion a whole number from 1 to 5 and can leave a comment for the organizers. Scoring opens once the event has ended. Judges who are on a team cannot score that team.

Teams are ranked by the average of the judges' totals, both overall and within each track. Teams with the same average share a rank. Teams that never handed in are kept off the ranking and listed on their own. A team that handed in but has no scores yet appears under Not scored yet instead of at the bottom, so a round of judging that is half done never reads as a loss for the teams still waiting. When every team has its scores, the organizer closes judging and the ranking stops changing. If a judge needs to fix a score, the organizer can reopen it.