A Student's Guide to Hackathons | Major League Hacking

TLDR: A hackathon is the fastest way to find out what you can build. Over a single weekend you will find a team, pick an idea, learn whatever you need to learn to make it real, and show it to people who genuinely want to see it. Nobody expects you to arrive knowing how. That is the entire point of the format. Hackathons are invention marathons, and they are open to anyone curious enough to show up: computer science majors, design students, people who declared history and got interested anyway, and people who have never written a line of code in their lives. You will leave with a project, a few new friends, and proof that you can go from nothing to something in thirty-six hours. Most people come back.

What Is A Hackathon?

An invention marathon. Programmers, designers, builders, and total beginners come together to learn, build, and share what they made over the course of a few days.

The word “hacking” causes confusion, so here is the clarification up front. It has nothing to do with breaking into systems or stealing anyone’s password. At a hackathon, hacking means quickly and intelligently building something real that other people can use. The word belongs to the people prototyping their ideas.

You do not need to be a computer science major. You do not need a technical major at all. These events are where software creators get made. A software creator is anyone who builds real, working things with software, a group that now reaches well beyond people with a computer science degree. And hackathons are open to anyone with an interest in technology and a willingness to learn. Strong teams usually mix skills: someone who designs, someone who can explain the thing to a stranger, someone who wires it together.

The format holds steady across events. You show up. You find a team or bring one. You spend the weekend turning an idea into a working thing. You demo it at a science-fair-style expo where judges walk table to table and ask what you built. Somebody wins something. Everybody leaves knowing more than they did on Friday.

Most events run 24 to 48 hours across a weekend, and they range from fifty-person gatherings to events with well over a thousand hackers. MLH supports thousands of events each year across 100+ countries.

Am I actually allowed to go to a hackathon?

Probably! The definition of a hackathon participant is broader than most people assume. MLH defines “student” generously: Anyone attending a traditional school, college, or university, anyone in a bootcamp or similar program, and anyone who graduated within the last twelve months. MLH hackathons are primarily for students, but may also include professionals.

The people who cannot compete are the organizers, volunteers, judges, sponsors, and anyone else in a privileged position at the event. They can be there. They just cannot enter.

Individual events can set their own eligibility on top of this. Age minimums, school affiliation, and whether high school students can attend vary event to event. The event page is the authority. MLH’s standard rules are a template that organizers can use as-is, fork, or replace entirely.

Do I need to know how to code to attend a hackathon?

No. This is the question that keeps most people home, so here is the direct answer.

MLH’s judging criteria weigh Learning equally with Technology. Judges are told to reward a team that stretched itself, and the rules give an explicit example: a team that always builds virtual reality projects and tries a mobile app instead should be rewarded for the exploration. Not knowing how to do something is a scoring category.

The criteria also spell out what does not count. Quoting the spirit of MLH’s rules: It does not matter if your code is messy, badly commented, or inefficient. Hacking is about playing around, making mistakes, and learning new things. If your code is not production ready, nobody is marking you down.

Here’s something else worth understanding: The floor for entry has moved. The setup work that used to eat a beginner’s entire first weekend, installing the language, configuring the environment, hunting Stack Overflow for the right command, now happens in a conversation with an AI tool. MLH co-founder Jon Gottfried’s framing for the current era contains a good analogy: AI generates the bricks, you still have to build the house. The weekend is about the house.

That shift is why more people can build software than at any point before. If you can describe what you want to make, you can start making it. That is what a software creator does. And in the AI era, everyone is a beginner at something, so a room full of first-timers is exactly where you belong.

There will be workshops. There will be mentors whose job is to sit down at your table when you are stuck. Roughly half the room is at their first hackathon, and the other half remembers being there.

What should I build at a hackathon?

Build something small. The only real requirement is that you can show it in two minutes.
MLH’s rules are more permissive than most first-timers expect, and knowing this in advance saves a lot of Friday-night anxiety:

You can use an idea you had before the event.
You can build something that already exists. Hacks do not have to be innovative. Judges are told that if somebody wants to work on a common idea, they should be allowed to, and should be judged on the quality of the hack.
You can revisit an idea you have worked on before, as long as you do not reuse the code or project materials.
You can use libraries, frameworks, and open source code.

The one hard line: All work on the project has to happen during the hackathon. Building it early and open-sourcing it so you can pull it back in over the weekend goes against the spirit of the rules and is not allowed.

Good first projects are almost embarrassingly small. Something that fixes a problem you personally have, or something useless but funny, is a great example. MLH’s own rules say a pointless project is sometimes the best hack. The teams that struggle are the ones trying to build the next Instagram by Sunday afternoon.

Can I use AI at a hackathon?

Yes, and MLH has a written policy on it, which is worth reading before you go: The standard hackathon rules.

MLH encourages the community to learn these technologies and leverage them. The framing in the rules is that the best projects will leverage AI but ultimately be created by humans.

Two rules govern it:

Use it: Teams may use AI to assist while coding: code completion, code generation, image generation, and similar tools.
Say you used it: Teams should be honest and transparent about which AI tools they used, list them in the project submission, and answer questions about them from organizers, judges, and other hackers.

The second rule has teeth. MLH’s Organizer Guide recommends that organizers disqualify projects that fail to credit their AI usage and report them to [email protected]. It also advises organizers to make clear that a project should not be a reskin of an existing AI tool. What judges want to see is what you created, changed, and built during the weekend.

Transparency is everything. Write down what you used.

What does a hackathon actually look like?

Schedules vary by event. Here is a typical weekend from the inside.

Friday

4:45pm Arrive at the venue and join the check-in line. It is longer than you expected and full of people who also do not know anybody.
5:15pm Reach the check-in booth, hand over your student ID, and collect a bag of t-shirts and stickers.
5:30pm Find a seat in the auditorium. Introduce yourself to the row in front of you. Ask what they are planning to build. Nobody knows yet.
6:00pm Opening ceremony. Organizers kick things off and sponsors introduce the technologies you can build with this weekend, along with the prizes attached to them. Write down the two that sound interesting.
7:30pm Ceremony ends. The room empties into a hall full of tables and power strips.
7:35pm Put your bag on the first open table and introduce yourself to the people beside you. They need one more person. You need a team. Done.
7:45pm Walk the sponsor booths along the wall. Every booth is staffed by engineers, mentors, and recruiters who are there specifically to talk to you. Ask them what their thing does.
8:15pm Dinner. Your team eats and argues about ideas.
8:45pm You are cutting into hacking time, so you set a deadline: thirty minutes to pick.
9:15pm Decided. A shared problem, a small solution, nothing revolutionary. You split roles. You take the back end, which you have never done.
9:30pm Create the repo and get everyone pushing to it. Somebody on the team has done this before. Somebody has not.
9:55pm A workshop starts in fifteen minutes. Your teammates are deep in it, so you go alone.
10:10pm Workshop. You follow along on your laptop and get something running. You are not yet sure how it becomes the project.
11:00pm Back at the table. Your team went to a Git workshop and returns knowing how to stop overwriting each other’s work.

Saturday

12:00am Midnight pizza. Steady progress. The small problems have all been solvable so far, mostly by the person sitting next to you.
1:10am Stuck. Thirty minutes on one thing that will not work. You get up and walk around, which is the correct move.
1:15am You pass a mentor at their booth and describe the problem. They offer to come look.
1:25am Ten minutes together and they explain what is actually happening. You realize you covered this in a class last month. You thank them and sit back down.
2:30am Your teammate looks stuck. She has the problem you solved twenty minutes ago. You explain the fix. (This is the best part of the weekend.) Keep going.
7:30am Breakfast.
11:00am Crunch. It is starting to look like a real thing, and there are still a dozen problems.
11:30am Lunch, eaten at the table.
11:45am Submit the project. Your README lists the AI tools you used, because that is the rule and because judges will ask. You get a table number and start practicing the demo in your head.
12:00pm The expo begins. Judges and other hackers move table to table while your team takes turns demoing. The tenth time you explain it, it finally sounds good.
1:30pm A judge stops at your table. You walk them through it. They ask what you built versus what you generated. You have a real answer, because you wrote it down.
2:00pm Expo ends. Everyone files back into the auditorium.
2:30pm Closing ceremony. Sponsors hand out prizes for their categories.
3:00pm Top hacks announced. Yours is one of them, or it is not. You have an “I Demoed” sticker either way, and you got it for being willing to show the thing.
3:30pm It ends. You exchange contacts with people you met thirty-six hours ago and cannot wait to sit down and keep working on it. Right after you sleep.

How will I be judged at a hackathon?

At MLH digital events and in MLH categories at in-person events, four criteria are weighed equally.

Technology. How technically impressive was the hack? Was the problem difficult? Did it use a clever technique or many components?
Design. Did the team think about the user experience? For a website that might be the interface. For hardware it might be how good the interaction is.
Completion. Does the hack work? Did the team get where they wanted to go?
Learning. Did the team stretch? Did they try something new?

The rules are equally explicit about what judges do not score:

How good your code is.
How good the idea is.
How well the project solves a problem. Something useless can be a great hack.
How well you pitch. Hacking is about building and learning, not selling.

Beyond the criteria, judges are free to go with their gut on which projects are most impressive and most deserving.

Demo even if it is broken. MLH is direct about this: you are strongly encouraged to present what you built even if it does not work or you did not finish, because completion is only one criterion of four, and you might still do well. Pitches and presentations are discouraged. Show the thing. If you have nothing at all to show, present what you tried and what you learned, which other attendees generally find more interesting than a polished demo.

What do I get out of a hackathon?

A project. You arrive with nothing and leave with something that runs, which is a different feeling from finishing a tutorial.

You get access: Every hacker at an MLH Member Event gets MLH Software Lab access, which means discounts and freebies on APIs and developer tools, from hosting credit to free domain names. Sponsor prize categories vary by event.

You meet people, and this is the one alumni talk about years later: Mentors who work through the night because they wish they had this at your age. Recruiters who came specifically to find people like you. Other students who now text you when they are stuck.

You build a track record: Your projects accumulate. So does the evidence that you can ship.
Where do I find hackathon schedules?

The 2026 season schedule lists every official MLH member event, sortable by date and location. Beyond the weekend events:

Global Hack Week runs online, which makes it the lowest-friction way to try the format without travel.
TechTogether runs events built around broadening who shows up.
The MLH Discord is where people find teammates before they ever get to a venue.

Cost, travel reimbursement, and whether meals are covered vary by event. Check before assuming.

What do I do after a hackathon?

Post the project on DEV, explain what you built and what broke, and ask for feedback. MLH describes itself as the lab and DEV as the library. The lab is where you get your hands dirty over a weekend; the library is where that knowledge becomes permanent, searchable, and useful to the next software creator who tries it. A hackathon project with a writeup behind it is worth more than the project alone.

Then go to your next hackathon. The second hackathon is easier than the first and better than the first, because you stop spending Friday night being nervous.

If the weekend format turns into something bigger, the MLH Fellowship is a 12-week remote internship alternative where you work on real projects from MLH’s partners in a small pod with mentors. It is the next rung for people who find out at a hackathon that they like this.

Hackathon Values & Conduct

Every MLH event runs under the MLH Code of Conduct and Community Values. Harassment and abuse are never tolerated, and if a situation at an event makes you uncomfortable there is a documented reporting procedure. Read it before you go. It’s not long.

Don’t forget what MLH’s own rules say about the point of all this: Hackathons are like marathons. Some people come to compete. Most people come to better themselves and have fun. However you got here, uphold the hacker spirit by collaborating with other teams, helping beginners, and having fun.

Have fun and happy hacking!