TT Finals-69.jpg
TT Finals-56.jpg

Hackathon Guidelines

The rules of the competition

  1. Teams must have a minimum of 4 members, but no more than 8 members. There is a limited number of prizes for each award. So if you form a large team and win a challenge, there might not be enough prizes for everyone on your team.

  2. Teams should be made up exclusively of registered participants who are not organizers, volunteers, judges, sponsors, or in any other privileged position at the event.

  3. All team members should be present at the event. Leaving the venue for some time to hack elsewhere is fine.

  4. Teams can of course gain advice and support from organizers, volunteers, sponsors, and others.

  5. All work on a project should be done at the hackathon.

  6. Teams can use an idea they had before the event.

  7. Teams can work on ideas that have already been done. Hacks do not have to be “innovative”. If a team wants to work on a common idea this is allowed and will only be judged on the quality of the hack.

  8. Teams can work on an idea that they have worked on before. Participants must clearly define what previously developed and newly created.

  9. Adding new features to existing projects is allowed. Judges will only consider new functionality introduced or new features added during the hackathon in determining the winners.

  10. 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.

  11. 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.

  12. Teams must register on Saturday October 19 by 6:00 pm through the provided Google Form.

  13. Projects that violate the Code of Conduct are not allowed.

  14. Teams can be disqualified from the competition at the organizers' discretion. Reasons might include but are not limited to breaking the Competition Rules, breaking the Code of Conduct, or other unsporting behavior.

Cube_icon.png

Judging Criteria

Teams will be judged on these four 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 you find a new use for, or leverage, an existing piece of technology? Did the technology involved make you go "Wow"?

  • Innovation: How innovative and groundbreaking was the idea? Did it use a particularly clever technique or did it use many different components?

  • Open-source: Does your project live on GitHub/Bitbucket? Is it open? Did you leverage other great techniques that already exist? We encourage you to develop an app that can easily be used by others.

  • Learning: Did the team stretch themselves? Did they try to learn something new? Which technologies/APIs/products/methods did you use, that you didn't know before?

  • Teamwork & Collaboration: We encourage you to have colorful teams. As such we will give points for teams that are not solely formed of coworkers. After all, we want to use this time to make new connections too.

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.

It's important to note that these judging criteria do not include:

  • How good your code is. It doesn't matter if your code is messy, or not well commented, or uses inefficient algorithms. Hacking is about playing around, making mistakes, and learning new things. If your code isn't production ready, we're not going to mark you down.

  • How well you pitch. Hacking is about building and learning, not about selling.

  • How good the idea is. Again, hackathons aren't about coming up with innovative ideas. It's about building and learning.

  • How well the project solves a problem. You can build something totally useless and as long as you're learning and having fun, that's a good hack! Sometimes a pointless project is one of the best hacks!

So don't worry about coming up with the next big idea, you'll have plenty of time for that outside the hackathon. just focus on learning, having fun, and making new friends. At the end of the day the skills you learn and the friends you make might lead to the next big thing—but you don't have to do that to win a hackathon.