Hackathons Explained

A hackathon is an event where people form teams, pick a problem and build something in a short period, usually a weekend or less. The word suggests all-night coding and energy drinks, and sometimes that is accurate, but most hackathons today are friendlier and more varied than the stereotype. They can be one of the fastest ways for a student to learn new tools, meet collaborators, add a project to a portfolio and experience what building under pressure feels like.

They also have downsides: poor sleep, unclear rules and projects that never survive the weekend. This guide explains how to choose an event, prepare and get the most from it.

Events, formats and rules vary widely. This guide describes common patterns and does not name specific events or organizers. Read each event's own rules.

What a hackathon looks like

A typical event follows a pattern.

1. Opening: organizers explain the theme, rules, schedule and prizes.
2. Team formation: participants pitch ideas or find teammates.
3. Building: teams work, with mentors and workshops available.
4. Check-ins: progress updates, meals and breaks.
5. Submission: teams submit code, a description and sometimes a video.
6. Demos and judging: teams present to judges and peers.
7. Awards and closing: winners are announced, and participants network.

Events can be in person, online or hybrid. Some are open to everyone, others only to students or particular groups.

Types of hackathons

• General hackathons: open themes, wide range of projects.
• Themed hackathons: focused on health, sustainability, education, accessibility, finance, civic technology or other areas.
• Corporate or sponsor hackathons: companies invite participants to use their tools or solve their challenges.
• University hackathons: run by student societies, often beginner friendly.
• Game jams: build a game within a time limit.
• Data hackathons: analyze datasets and create visualizations or models.
• Design sprints and ideathons: focus on concepts and prototypes, with less coding.
• Social impact and civic events: work with communities and public bodies.
• Long-form hackathons: run over weeks.

Choose a type that matches your goals and comfort level.

Why join

• Learn quickly. Building under time pressure teaches practical skills.
• Try new tools without long commitments.
• Meet people: future teammates, mentors and employers.
• Build portfolio projects.
• Practice teamwork and communication.
• Explore career paths.
• Have fun and test ideas.
• Practice presenting and pitching.

Many employers value the initiative that hackathons show, though they do not replace deeper work.

Find and choose events

• Ask your department, computing society and careers service.
• Check university and local tech community listings.
• Look at event aggregators and sponsor announcements.
• Follow student tech groups on social media.
• Check the rules and schedule. Is it online or in person? Is travel needed? Are meals and accommodation provided?
• Check eligibility such as student status, age and location.
• Read the code of conduct and safety information.
• Look at past project showcases to gauge level.
• Check the cost. Most hackathons are free, but travel can add costs. Our budgeting section helps you plan.
• Beware of scams. Fake events may ask for payment or personal data. Verify organizers independently.

If you are new, choose a beginner-friendly or university-run event.

Build a team

Teams are often two to five people.

• Join with friends if you can, or find teammates at the event.
• Balance skills: developers, designers, data people, writers and presenters. Non-coders contribute greatly.
• Be inclusive. Welcome newcomers.
• Agree roles and communication early.
• Check compatibility in goals: are you there to win, learn or have fun?
• Respect working styles and boundaries.
• Plan breaks and sleep.

If you are looking for a team, prepare a short introduction of your skills and interests.

Prepare before the event

• Read the rules and judging criteria.
• Check what you may use: pre-existing code, libraries, sponsor tools and data.
• Set up your environment: install tools, test accounts and create a repository.
• Practice a basic project to refresh your skills.
• Learn the sponsor tools if relevant.
• Bring equipment: laptop, charger, headphones, adapters and a power strip if allowed.
• Plan your logistics: travel, meals and sleep.
• Tell friends and family where you are.
• Secure your accounts. Use strong passwords and two-factor authentication. Our digital safety section explains how.
• Think of problems you care about, to bring ideas.

A weekend plan

Hour 0 to 2: Idea and scope. Discuss problems, choose one and define a small, achievable goal. Write a one-sentence description: "We help X do Y by Z." Decide who does what.

Hour 2 to 6: Foundation. Set up the repository and basic structure. Build the simplest version of the core feature. Make design sketches.

Hour 6 to 20: Build. Develop the main features. Test often. Keep a working version at all times. Check in with mentors. Sleep for a few hours.

Hour 20 to 30: Polish. Fix bugs, improve the interface, prepare data and add the extras only if time allows. Freeze features before the deadline.

Hour 30 to 36: Demo preparation. Write the submission text, record a demo video if required and rehearse your pitch.

Presentation and judging. Present, answer questions and listen to others.

Timelines differ by event. The principle holds: scope small, get something working early, polish late and leave time to prepare the demo.

Tools and workflow

• Version control from the start, with frequent commits and clear branches.
• A shared task list to track progress.
• Communication channels for the team.
• Pre-built components, templates and APIs (where allowed) to save time.
• Cloud services with free tiers. Watch limits and costs.
• Design tools for quick prototypes.
• AI coding assistants, if permitted. Follow event rules and understand what the tools generate.
• Backup: keep copies of code and slides.

Do not leave secrets in public repositories. Use environment variables.

Pitching and judging

Judges often see many projects in a short time.

• Start with the problem and who it affects.
• Show the demo, keeping it short and reliable. Record a backup video.
• Explain what you built and how, briefly.
• Highlight what is novel or useful.
• Be honest about limitations and next steps.
• Share the team's contributions.
• Keep within time limits.
• Practice, and assign speakers.
• Answer questions calmly.
• Understand the criteria: usually idea, execution, impact and presentation.

Judging can be subjective. Do not take results personally.

Wellbeing and safety

• Sleep, even if briefly. Exhaustion damages code and mood.
• Eat and drink water.
• Take breaks.
• Avoid excessive caffeine.
• Respect personal boundaries and the code of conduct. Report harassment or discomfort to organizers.
• Stay safe traveling, especially at night.
• Protect your belongings, and don't leave devices unattended.
• Manage stress. It is okay to withdraw if you need to.
• Be aware of your study commitments. Do not let an event wreck your coursework.

Rules, ownership and ethics

• Read the terms about intellectual property, licenses and sponsor rights. Some events let teams keep their work, others grant sponsors certain permissions.
• Respect rules about pre-existing code. Starting with a ready-made project can disqualify you.
• Credit sources and libraries, and follow licenses.
• Be careful with data. Use only data you are allowed to use, and protect privacy.
• Don't misrepresent your work. Be clear about what was built during the event.
• Think about ethical impact. Who could be harmed by your idea? Consider fairness, privacy and accessibility.
• Respect others. Collaborate and compete fairly.

After the event

• Rest.
• Thank organizers, mentors and teammates.
• Connect with people you met.
• Finish and polish the project if you want to include it in your portfolio. Add a README, screenshots and a license.
• Write a short blog post or profile update about what you built and learned.
• Reflect: what worked, what you would change and what you want to learn next.
• Consider continuing the project with the team, turning it into a real product, or contributing it to open source.
• Keep records of any prizes or recognition for your resume.

Common mistakes

• Overambitious scope.
• No working version until the end.
• Ignoring rules.
• Neglecting the demo.
• Not sleeping.
• Poor teamwork or communication.
• Forgetting to back up or commit.

A quick checklist

• Have I read the rules and chosen an event suited to my level?
• Do I have a team or a plan to find one?
• Is my environment ready and my accounts secure?
• Have I planned a small scope and a demo?
• Do I know the ownership terms and conduct rules?

Final thoughts

Hackathons are compressed learning experiences. Choose an event that fits your level, build a balanced team and keep your scope small. Get a working version early, polish late and prepare a clear demo. Look after your wellbeing, respect rules and people and use the experience to learn, connect and grow.