If you have seen the word "hackathon" on a poster in your college corridor and quietly decided it was not for you, this page is written for you specifically.
The one-sentence version
A hackathon is a time-boxed event where teams build a working project from scratch — usually over 24 to 48 hours — and then show it to judges.
That is genuinely all it is. Everything else is detail.
First, what it is not
The word does most of the damage here, so let us clear it up.
- It has nothing to do with hacking into anything. "Hack" here means building something quickly and roughly, in the older sense of the word. Nobody is breaking into systems.
- It is not a competitive programming contest. You are not solving algorithm puzzles against a timer. You are building a product.
- It is not an exam. There is no syllabus, no right answer, and looking things up is the entire job.
- It is not only for computer science students. Design, writing, business thinking and presenting are all scored. Teams made entirely of coders routinely lose to mixed teams.
What actually happens, hour by hour
Here is the real shape of a 36-hour online hackathon, which is the classic format and what most first-years picture when they hear the word.
FirstHack is not this format. It runs as three rounds across two weeks — idea, prototype, final pitch — with a deadline at the end of each rather than one long clock. Everything below still applies to how you work inside a round; you simply get days instead of hours, and you sleep in your own bed. The schedule page has the exact dates.
Hour 0 — Kickoff
Organisers explain the rules, announce the themes or problem statements, and start the clock. This usually takes an hour and you should pay attention to the judging criteria section, because most teams never look at it again and it is literally the marking scheme.
Hours 0–3 — Deciding what to build
This is the phase that most often goes wrong. Teams either spend eight hours arguing about ideas, or they pick something enormous and never finish it. The good version: pick a problem one of you has personally had, decide the single smallest version of it that would still be useful, and start.
Hours 3–28 — Building
The long middle. You will get stuck. This is not a sign that you do not belong — being stuck is the normal state of building software, including for people who do it professionally. It is why mentors exist.
Hours 28–34 — Stop building
Experienced teams stop adding features here and start packaging: writing the README, recording the demo video, and testing that the thing actually runs on a machine that is not the one it was built on. First-time teams almost always skip this and lose marks they had already earned.
Hours 34–36 — Submission
Upload the repository link, the video, and the write-up. Submit early. Deadlines at hackathons are enforced by software, and "my internet went down" is not a category the form accepts.
After — Judging
Judges score submissions against published criteria over the following days, and results are announced. At a well-run event you can ask for feedback afterwards even if you did not place.
What you are expected to produce
Almost universally, three things:
- A code repository — normally public on GitHub, with commit history that shows the work happened during the event.
- A demo video — usually 2–3 minutes, usually a screen recording. This is what judges actually watch. Most of them will not run your code.
- A written description — what it does, who it is for, how to run it.
What "good" looks like for a first-timer
This is the part nobody tells beginners, so here it is plainly.
A project that does one thing and does it properly beats a project that does five things badly. Every time. On every rubric. Judges have seen hundreds of ambitious half-built dashboards and they can spot placeholder data instantly.
Your goal for a first hackathon is not to win. It is to submit something that runs. That alone puts you ahead of a large share of first-time teams, most of whom submit nothing at all — not because they lacked skill, but because they scoped too big and ran out of time.
Do you need to know how to code?
You need to be willing to learn in public, quickly, with help available. That is a different thing from already knowing.
At beginner-focused events, plenty of participants write their first meaningful program during the event itself, with a mentor walking them through it. If an event's format assumes you already know everything, that event is not designed for first-years — which is a statement about the event, not about you.
Why bother at all?
- You end up with a real project. In your first year, having one thing you actually built puts you ahead of most of your batch when internship applications start.
- You learn how to finish. Starting projects is easy and common. Shipping one under a deadline is a genuinely different skill, and it is the one employers notice.
- You meet people. Teammates and mentors from other colleges tend to outlast the project itself.
- It compresses the learning curve. A focused weekend of building teaches more than a month of tutorials, because you hit real problems instead of pre-solved ones.
The honest downsides
So you can decide properly:
- It is tiring. 36 hours with poor sleep is a real physical cost.
- Your first one will probably feel chaotic and slightly embarrassing. That is normal and it gets much better by the second.
- If your team does not gel, it can be frustrating in a way solo work is not.
- You might not finish. Roughly a third of first-time teams do not submit. Knowing that in advance is the best protection against it.
How to pick your first one
Look for these signals when choosing an event:
- Does it say explicitly that beginners are welcome — and does the format back that up with mentors and separate judging?
- Is the judging criteria published before you register?
- Are the rules, refund policy and organiser details easy to find?
- Is it online? For a first event, removing travel and accommodation removes a lot of reasons to drop out.
If an event answers yes to all four, it is a reasonable first one. If it is vague on all four, wait for a better one.