A hackathon gives students a short window to build and learn with others. GitHub's 9 October article on hackathon learning describes collaborative prototyping across different experience levels. It does not promise a job. The opportunity for an Indian student is to leave with work that another person can run, inspect and discuss, rather than only a certificate or a demo link.
The gap most students fall into is treating the repository as the deliverable. The repository is raw material. The deliverable is a short, honest record of what you decided, what you built, what broke, and what you changed afterwards.
Pick a narrow local problem, not an impressive-sounding platform
Broad ideas fail at hackathons for a boring reason: every part is half-finished, so nothing is demonstrable. A narrow problem tied to your own campus or neighbourhood gives you a real user, a real constraint, and a finish line you can actually cross.
A hypothetical example: a campus lost-and-found tool. Students post found items with a rough category, a location, and a date. Claimants search and submit a claim. An administrator marks items returned. That scope is small enough to finish and rich enough to show decisions about data, permissions, and abuse.
Write the scope as a sentence with a measurable end state. "Let a student find a matching found-item record in under a minute using category and location filters" is testable. "Build an AI-powered campus platform" is not.
Separate your contribution from the team's and from the model's
State your own contribution and any significant AI assistance plainly. A reader needs to distinguish your decisions from a teammate's work or generated code. Describe what you checked, changed or rejected rather than presenting prompts as proof of engineering judgment.
- Roles: name who owned which surface, even in a team of three. "I built the claim flow and the admin review screen; a teammate built search."
- AI use: state where it helped and where you rejected it. "Used a coding assistant to draft the filter query; rewrote it after it ignored the soft-deleted flag."
- Your decisions: list two or three calls you made and why. Schema choice, permission model, what you cut.
This is the part candidates most often skip, and it is the part that carries the most signal.
Make the repository safe and reproducible
A public repository is a portfolio artefact, which means it is also an attack surface and a privacy problem. Two rules cover most of it.
First, no secrets, ever. Not in code, not in commit history, not in a config file you deleted later. Use environment variables and a committed example file with clearly fake sample values. If you did leak a key during the event, rotate it and say so in the README. That sentence demonstrates judgment.
Second, synthetic data only. For the lost-and-found example, generate fake item records with invented names and locations. Never commit real student names, phone numbers, photos, or claim messages. If your project handles personal data at all, describe the retention rule you would apply in production, even if the prototype does not enforce it.
A reproducible README answers four questions in order: what this is, how to run it, what works, what does not. Include the exact commands, the runtime version, and any external service the reader must supply. If setup needs more than a few steps, add a container definition or a setup script.
Provide delivery and recovery evidence, not just a demo link
A live URL is fragile. Free tiers sleep, credentials expire, and a reviewer clicking a dead link learns nothing. Treat the demo as a bonus, not the proof.
Record a short screen capture of the core flow, and commit screenshots to the repository. Then go one step further and show how the thing behaves when it fails. This is where the concept of making build and recovery evidence reviewable becomes practical for a student project: a reviewer should be able to see the build steps and the recovery path without trusting your summary. A simple pipeline file that runs your tests, plus a documented rollback or restore step, turns a prototype into something that reads like engineering.
| Artefact | What it proves | Common failure |
|---|---|---|
| README with run commands | Someone else can start it | Missing env vars |
| Test output in CI | You checked behaviour | Tests that assert nothing |
| Screenshots or capture | The flow existed | Only a hero image |
| Limits section | You can judge your own work | Claims without caveats |
Show test evidence and state honest limits
You do not need high coverage. You need tests that would fail if the behaviour broke. For the lost-and-found example, that means a test that a returned item no longer appears in search results, and a test that a claimant cannot see another claimant's contact details.
Then write the limits plainly. "Search is a simple substring match, so typos return nothing. There is no rate limiting on claims. The admin role is a hardcoded flag, not a real permission system." A reviewer reading that trusts your other claims more, not less.
Revise after the event and write the CV bullet
The most valuable portfolio work happens after the hackathon ends, when you are no longer rushed. Spend a few hours on the highest-value fixes: the bug you know about, the test you skipped, the README a stranger could follow. Add a short changelog entry explaining what changed and why. That record shows you finish things.
For the CV, write one line that names the problem, your specific contribution, and a verifiable artefact. A hypothetical format: "Built claim and admin review flows for a campus lost-and-found prototype (team of three); wrote the permission tests and documented known limits." No placement claims, no invented user numbers.
On eligibility for student benefit programmes, check the current terms yourself before relying on any of them. Access conditions change and are not universal, so treat them as optional rather than assumed.
Conclusion
A hackathon is a learning format, not a hiring guarantee, and the GitHub description of these events should be read that way. What you control is the record you leave behind: a narrow problem, an honest account of your role and your AI use, a secret-free repository with synthetic data, a README a stranger can run, evidence that the build and the recovery path work, tests that mean something, and stated limits. That combination is what makes a project reviewable. Reviewable work gives you a concrete basis for discussing your contribution; it does not guarantee an interview or selection.
Image: cottonbro studio via Pexels. Illustrative developers collaborating; not a named hackathon or placement result.
