Hackathons
Hackathons are short, intense project-building events. They are useful for learning new tools, meeting teammates, creating resume projects, and practicing how to explain technical work.
hackathons worth applying to
Section titled “hackathons worth applying to”Most of these are open to students from any school, not just the host university. Applications usually open one to two months before the event and close early, so the real skill is watching for them to open.
Dates last verified September 3, 2026. Hackathon dates move every year, so treat anything here as a starting point and confirm on the event's own site.
Fall 2026
Section titled “Fall 2026”Applications for most of these are open or opening now.
| Event | Host | Dates |
|---|---|---|
| HackRice | Rice | Sep 11-13, 2026 |
| Hack the North | Waterloo | Sep 18-20, 2026 |
| HopHacks | Johns Hopkins | Sep 18-20, 2026 |
| VTHacks 14 | Virginia Tech | Sep 18-20, 2026 |
| HackMIT | MIT | Sep 19-20, 2026 |
| HackGT 13 | Georgia Tech | Sep 25-27, 2026 |
| ShellHacks | FIU | Sep 25-27, 2026 |
| BigRed//Hacks | Cornell | Oct 2-4, 2026 |
| MHacks | Michigan | Oct 3-4, 2026 |
| HackNC | UNC Chapel Hill | Oct 9-11, 2026 |
| Knight Hacks IX | UCF | Oct 9-11, 2026 |
| HackHarvard | Harvard | Oct 16-18, 2026 |
| SwampHacks XII | Florida | Oct 16-18, 2026 |
| Hack the Valley | Toronto Scarborough | Oct 16-18, 2026 |
| DubHacks | Washington | Oct 17-18, 2026 |
| LA Hacks AI Hackathon | UCLA | Oct 17-18, 2026 |
| Cal Hacks 13.0 | UC Berkeley | Oct 23-25, 2026 |
| HackTX 26 | UT Austin | Oct 24-25, 2026 |
| HackPSU Fall | Penn State | Oct 24-25, 2026 |
| SunHacks Arizona | ASU | November 2026, TBA |
| HackUTD | UT Dallas | Nov 7-8, 2026 |
| HackRPI | RPI | Nov 7-8, 2026 |
| HackPrinceton Fall | Princeton | Nov 13-15, 2026 |
| HackUMass | UMass Amherst | Nov 13-15, 2026 |
| Opportunity Hack Arizona | ASU | Nov 14-15, 2026 |
| Hack Western 13 | Western University | Nov 20-22, 2026 |
Winter and Spring 2027
Section titled “Winter and Spring 2027”Applications generally open between November and February.
| Event | Host | Dates |
|---|---|---|
| DeltaHacks | McMaster | Jan 9-10, 2027 |
| UofTHacks | Toronto | Jan 15-17, 2027 |
| uOttaHack 9 | Ottawa | Jan 15-17, 2027 |
| nwHacks | UBC | Jan 16-17, 2027 |
| Hack@Brown | Brown | Feb 5-7, 2027 |
| SpartaHack | Michigan State | Feb 6-7, 2027 |
| TreeHacks | Stanford | mid-February 2027, TBA |
| HackNYU | NYU | February 2027, TBA |
| SF Hacks | SF State | Feb 19-21, 2027 |
| HackIllinois | UIUC | Feb 26-28, 2027 |
| Hacklytics | Georgia Tech | Feb 26-28, 2027 |
| PennApps XXVII | Penn | spring 2027, TBA |
| Diamondhacks | UC San Diego | Apr 4-5, 2027 |
| HackKU27 | Kansas | Apr 9-11, 2027 |
| Bitcamp | Maryland | April 2027, TBA |
| WildHacks | Northwestern | April 2027, TBA |
| LA Hacks 27 | UCLA | Apr 16-18, 2027 |
| HackDavis | UC Davis | spring 2027, TBA |
This list is curated. MLH’s season page has the full slate of several hundred events if none of these fit your timing.
start local
Section titled “start local”If you have never done one, start with SunHacks or Opportunity Hack here at ASU. No travel, no application stress, and the same skills transfer directly to the bigger ones. SoDA usually has people going to both — ask in the Discord.
applying and getting there
Section titled “applying and getting there”- Apply early. Many of the large hackathons admit on a rolling basis, so the same application is much stronger a week after it opens than a week before it closes.
- Applications are short. Usually a resume, a link or two, and a couple of short answers about what you want to build. Write real answers rather than generic ones — organizers read a lot of these.
- Apply as a team where allowed. Some events let you submit a team application, which can improve everyone’s odds and saves you from scrambling for teammates at the venue.
- Ask about travel reimbursement. Big hackathons often reimburse part of the cost of getting there, sometimes only if you come with a group from the same school. Check before you book anything.
- Being rejected means very little. Acceptance is heavily oversubscribed and partly random. Apply to several in the same season instead of pinning hopes on one.
- Check the rules on prior work. Almost all of them require the project to be built during the event. Planning ahead is fine; pre-writing the code is not.
what to expect
Section titled “what to expect”InnovationHacks was described as a two-day rapid software prototyping event with teams of two to four people and problem statements revealed at the event. Other hackathons vary, but the core pattern is similar: form a team, understand the prompt, build a prototype, and present it clearly.
team composition
Section titled “team composition”Choosing the right teammates matters. A strong team is not just “four coders.”
Look for complementary strengths:
- Backend or infrastructure
- Frontend or mobile
- Product design
- User experience
- Data, AI, or domain knowledge
- Project management
- Pitching and storytelling
Agree early on communication norms, roles, and how you will make decisions when time is short.
understand the problem first
Section titled “understand the problem first”Do not jump straight into code. Use the 5Ws:
- Who has the problem?
- What job do they need done?
- When does the problem happen?
- Where does the solution need to work?
- Why does this matter?
Then turn needs into requirements:
- What must the solution do?
- What constraints exist?
- What would count as success?
- What can be safely skipped for a demo?
- What is novel, useful, or impressive about the approach?
design for feasibility
Section titled “design for feasibility”A hackathon project should be scoped to finish. Define components and responsibilities before implementation.
Good design choices:
- Use a stack your team can move quickly in.
- Prefer simple architecture over clever architecture.
- Use abstraction only where it reduces confusion.
- Keep communication tight.
- Pick a deployment plan early.
- Decide what the demo path will be before building too much.
Vercel plus Supabase is a common quick stack for web apps, but use whatever your team knows well enough to ship.
implementation habits
Section titled “implementation habits”- Use version control from the start.
- Prefer a monorepo unless there is a strong reason not to.
- Document early so teammates and judges can understand the project.
- Work in parallel, but integrate often.
- Reserve time for the presentation.
- Avoid scope creep.
- Treat prototypes like experiments.
The presentation is part of the product. A polished pitch can beat a slightly more complete project that judges cannot understand.
what to skip
Section titled “what to skip”For a demo, no one is usually going to use your product at production scale. Skip low-value complexity unless it is central to the prompt.
Usually skip:
- Full authentication
- Complex onboarding
- Perfect settings pages
- Overbuilt admin tools
- Edge cases that will not appear in the demo
- Infrastructure that does not support the story
using AI tools
Section titled “using AI tools”AI tools can help with debugging, scaffolding, design ideas, and unfamiliar APIs. Treat them like fast but imperfect assistants.
Good AI use:
- Ask for options, then choose intentionally.
- Use AI to explain errors or unfamiliar libraries.
- Generate boilerplate, then review it.
- Use it to brainstorm edge cases.
- Keep ownership of product direction and final code.
Risky AI use:
- Letting generated code define the whole product.
- Accepting code you cannot explain.
- Spending more time prompting than building.
- Shipping insecure or broken code because it looked plausible.
judging and presentation
Section titled “judging and presentation”A good final presentation answers:
- What problem did you choose?
- Who is the user?
- What did you build?
- Why is it useful or interesting?
- What is technically impressive?
- What did you learn or validate?
- What would you do next?
Show the happy path. If something is fragile, demo the part that works and explain the future plan honestly.