Remember that hackathons are like marathons. Some people go to compete but most people take part to better themselves and have fun. Whatever the reason is you're at a hackathon, make sure you're upholding the hacker spirit by collaborating with other teams, helping beginners, and having fun.



  1. Teams should be made up exclusively of  2-6 college students who are not mentors, judges, or sponsors.
  2. Teams can of course gain advice and support from organizers, mentors, sponsors, and other participants.
  3. All work on a project should be done at the hackathon.
  4. Teams can use an idea they had before the event.
  5. Teams should be working on a new project. Adding new features to existing projects is not allowed to be submitted as a hackathon project. 
  6. Teams can use libraries, frameworks, or open-source code in their projects. Working on a project before the event and open-sourcing it for the sole purpose of using the code during the event is against the spirit of the rules and is not allowed.
  7. Teams must stop hacking once the time is up. However, teams are allowed to debug and make small fixes to their programs after time is up. e.g. If during demoing your hack you find a bug that breaks your application and the fix is only a few lines of code, it's okay to fix that. Making large changes or adding new features is not allowed.
  8. Projects that violate the rules of Hack for Humanity are not allowed.
  9. Teams can be disqualified from the competition at the organizers' discretion. Reasons might include but are not limited to breaking the rules of Hack for Humanity or other unsporting behaviour.


Our hackathon is dedicated to providing a safe and comfortable environment and harassment-free experience for everyone, regardless of the following:

  • gender
  • gender identity and expression
  • age
  • sexual orientation
  • disability
  • physical appearance
  • body size
  • race
  • ethnicity
  • nationality
  • religion
  • political views
  • previous hackathon attendance or lack of
  • computing experience or lack of
  • chosen programming language or tech stack

We do not tolerate harassment of hackathon participants in any form. Sexual language and imagery are not appropriate at any hackathon venue, this includes the following:

  • hacks
  • talks, presentations, or demos
  • workshops
  • any parties associated with the hackathon
  • social media
  • any other online media

Hackathon participants violating these rules may be sanctioned or expelled from the hackathon without a refund (if applicable) at the discretion of the hackathon organizers.




After hacking finishes, there will be two rounds of judging which will take place. During the initial round, teams will perform short demos their projects to pairs of judges. You will be judged not only based on what you built, but also on the quality of your pitch or the quality of your idea. You are encouraged to present what you have done even if your hack is broken or you weren’t able to finish. It's okay if you didn't finish your hack - that happens all the time! Completion is only one part of the judging criteria, so you might still do well.


A select number of groups will then be picked for the final round of judging. This round involves presenting and demonstrating the project on the main stage. All of our judges will be involved in the deliberation process to choose the winner for each of the four categories.


Judging Criteria


Teams will be judged on these criteria. Judges will weigh the criteria equally. During judging, participants should try to describe what they did for each criterion in their project.


  • Technology: How technically impressive was the hack? Was the technical problem the team tackled difficult? Did it use a particularly clever technique or did it use many different components? Is it a scalable design/solution?
  • Polish: Did the team put thought into the user experience? How well designed is the interface? For a website, this might be about how clean and beautiful the CSS or graphics are. For a hardware project, it might be more about how good the human-computer interaction is. Is the project designed with accessibility in mind?
  • Innovativeness: Does the hack show the team thought “outside of the box”? Does it have a certain “wow factor” to it? Is it different compared to previous solutions?
  • Social Impact: How much good could this hack bring to others in the specific theme?
  • Project Completeness: Is there a demo of the product’s functionality? Can major user action flows be completed without significant obstacles?


These questions should only be used to help judges make decisions. They are not strict guidelines for judging. These criteria will guide judges but ultimately judges are free to make decisions based on their gut feeling of which projects are the most impressive and most deserving.