Pick one:a hackathon, or open source.

One focused month, one real thing shipped. How to choose a beginner-friendly repo, write a PR that actually gets merged, and list it on your resume without overstating it.

Two pathscompared honestly
Five-stepPR process
List iton your resume, honestly

Hackathon

A concentrated 24-48 hour build, usually with a team. Good for practising working under time pressure and shipping something end-to-end fast, even if imperfect.

Best if: Best if you enjoy fast-paced building and want a demo-able project quickly.

Open-source contribution

A smaller, focused change to an existing real project. Good for practising reading unfamiliar code and working within someone else's standards and review process.

Best if: Best if you want practice specifically at reading and navigating a large, real codebase.

Finding a beginner-friendly repo

Search GitHub for the "good first issue" or "help wanted" label — most active projects tag beginner-friendly work this way specifically.
Pick a project you actually use or understand, even a little — context makes the code far easier to navigate than a completely unfamiliar domain.
Check the project has a CONTRIBUTING.md file and active recent commits — an abandoned repo means slow or no review, which wastes your effort.
Start smaller than you think you need to — a documentation fix or a small bug fix is a completely legitimate first contribution, not a lesser one.

Writing a PR that gets merged

1. Read the contributing guidelines first

Every project has its own process (branch naming, commit message format, testing requirements) — following it precisely is itself a signal of care.

2. Comment on the issue before starting

"I'd like to work on this" prevents duplicate effort and often gets you useful guidance from a maintainer before you write a single line.

3. Keep the change focused

One PR, one clear purpose. A PR that fixes one bug and also reformats unrelated files is harder to review and more likely to get stuck.

4. Write a clear PR description

What the change does, why, and how you tested it. This is the same communication skill covered in the AI-era skills guide, and it directly affects how fast your PR gets reviewed.

5. Respond to review feedback promptly and gracefully

Maintainers remember contributors who engage well with feedback. A quick, polite response to requested changes often matters more than getting it perfect on the first try.

Need a starting idea?

Browse project briefs if you'd rather build than contribute.

Browse project ideas

Keep going

GitHub / project review Project explanation scripts All fresher guides

QUESTIONS? WE'VE GOT ANSWERS

Common questions

A real first contribution, done right

Which is better for a resume, a hackathon or an open-source contribution?

Both are legitimate and they demonstrate different things — a hackathon shows you can ship fast under pressure, an open-source contribution shows you can work within someone else's codebase and process. Pick based on which skill you want to practise, or do one of each over time rather than treating it as a single choice.

How do I list a small open-source contribution honestly on my resume?

Name the project, describe specifically what you changed and why, and link the actual merged pull request. A small, honest, linked contribution is more credible than a vague claim about "contributing to open source" with nothing to verify it.

What if my hackathon project didn't win anything?

That's completely fine to include — most hackathon projects don't win, and what matters on a resume is what you built and your role in it, not the outcome of the competition. Describe it the same way you would any other project, using the explain-projects template.

I'm nervous my code isn't good enough for a real open-source project. Should I wait?

No — "good first issue" labels exist precisely because maintainers expect and welcome beginner contributions on those specific items. A small, well-scoped, well-tested change is what's expected; nobody expects a fresher's first PR to be architecturally sophisticated.

How long does a first open-source contribution usually take?

For a well-chosen "good first issue", often a few hours to a couple of days including the review back-and-forth — budget more time for finding the right issue and reading the contributing guidelines than for the code change itself.

Can I do a hackathon solo, or do I need a team?

Most hackathons allow solo participation, though many are designed around small teams and team-based ones can be a good way to practise collaboration under pressure. Check the specific hackathon's rules — both formats are valuable experience.

Still have questions? We're happy to help.

Email us We usually reply within a day