What Changed in the Rules Since the Last MS Hackathon Round
Why the rules changed between rounds
Every MS Hackathon round teaches the organizing team something new. After the previous round, feedback from mentors, judges, and participating teams pointed to a handful of gaps: unclear timekeeping, inconsistent repo requirements, and confusion about how partial work is scored. The result is a set of rule adjustments that apply to the next round.
This recap is written for returning teams. If you competed before, assume nothing is identical. The spirit of the event is unchanged, but several concrete details now work differently, and ignoring them can cost you points before you write a single line of code.
Timing and submission windows
The biggest change concerns the clock. Previously, teams could keep pushing commits until the judges started reviewing. Now the submission window closes hard at the announced deadline. The repository state at that moment is the only state that gets evaluated.
There is also a short grace period for a submission form, but it does not extend coding time. The form only confirms your team name, track, and repository link. If the form is missing, the repository is not reviewed at all.
- Freeze your code before the deadline.
- Submit the form within the grace period.
- Verify the repository link is public or judge-accessible.
Repository and tooling requirements
Returning teams remember the loose approach to project structure. That is gone. Each repository now needs a README with setup steps, a license file, and a clear description of which parts were built during the event.
Pre-existing boilerplate is still allowed, but it must be declared. Undeclared starter code counts as a rule violation, and judges may discount the affected feature entirely.
"Declare what you brought, and we will judge what you built."
Scoring and judging adjustments
Scoring now separates functionality, code quality, and presentation more cleanly. Partial credit is explicit, so a working core feature beats a broken ambitious one. Judges also score documentation, which means your README is no longer an afterthought.
| Area | Old rule | New rule |
|---|---|---|
| Deadline | Soft cutoff | Hard cutoff |
| Starter code | Undeclared | Must be declared |
| README | Optional | Scored |
What this means for returning teams
If you are coming back, the safest move is to treat this as a new event. Re-read the full rule set, assign one teammate to own the submission checklist, and build in a buffer before the deadline.
Teams that adapt quickly will find the changes fair and predictable. Teams that rely on memory will lose points for reasons that have nothing to do with their engineering skill. Prepare deliberately, and the adjusted rules work in your favor.