After this lesson, you will be able to: Find a good first issue, fork and contribute to a real open-source project, follow its contribution guidelines, and get a pull request merged, then talk about it in interviews.
A merged pull request to a real open-source project is one of the strongest things a junior engineer can show. It proves you can read an unfamiliar codebase, follow a team's process, and collaborate with strangers under review. This lesson is both a how-to and the passion project for this subtrack: by the end you will have submitted a real contribution.
A personal project shows you can build. A merged open-source PR shows something rarer: that you can drop into code you did not write, follow conventions that are not yours, take review feedback without ego, and ship a change a maintainer trusts enough to merge. Hiring managers read it as 'this person can already work on a team.' It exercises every skill in this track at once: reading code, branching, PR hygiene, CI, and communication.
The full workflow. Your goal for this lesson is to complete it on a real project.
Pick a project you actually use or understand, in a language you know. Familiarity beats prestige.
Find a starter issue: filter issues by labels like `good first issue`, `help wanted`, or `documentation`.
Read CONTRIBUTING.md and the code of conduct. Follow their setup, branch naming, and commit-message rules exactly.
Comment on the issue to say you're working on it, so two people don't duplicate the work.
Fork the repo, clone your fork, create a branch, and get the project running + tests passing locally first.
Make the smallest change that fully solves the issue. Add or update tests. Run their linter and test suite.
Open the PR from your fork: a clear title, a description linking the issue (`Fixes #123`), and what you changed and why.
Respond to review politely and promptly. Push fixes to the same branch; the PR updates automatically.
After merge: thank the reviewer, and save the PR link for your resume and interviews.
GitHub's own issue search supports `label:"good first issue"` across all public repos. Sites like goodfirstissue.dev and up-for-grabs.net aggregate beginner-friendly issues. Documentation fixes (typos, missing setup steps, unclear examples) are real, welcome contributions and a great first PR, do not dismiss them as 'not real code.' Maintainers value docs highly.
Opening a giant PR that rewrites things nobody asked you to touch. Small and scoped gets merged; sprawling gets closed. Skipping CONTRIBUTING.md and getting the PR rejected on process, not code. Not running the project's tests/linter before opening the PR, so CI fails publicly. Going silent when a maintainer requests changes. Responsiveness is most of what gets a PR over the line. Picking a famous, fast-moving project for your first PR. Start somewhere smaller where maintainers have time to review.
Pick the strongest answer.
Sign in and purchase access to unlock this lesson.