{"title":"Why Open Source","description":null,"content":"\"Contribute to open source\" is common career advice. It is also easy to misunderstand.\n\nOpen source is not a shortcut to a job. A single pull request will not make a weak resume strong, and most recruiters will not study every line of your GitHub history. But open source can help when it gives you real evidence: you worked in someone else's codebase, followed their standards, responded to feedback, and got useful work accepted.\n\nThat matters because most engineering jobs are not about building alone in a clean, empty project. They are about understanding existing systems, making careful changes, and working with other people. Good open source work gives a hiring manager a small but concrete sample of that.\n\n---\n\n# The Two Real Benefits\n\nOpen source can help your career in two practical ways: it can make you better, and it can make your work easier to trust.\n\nThe first benefit is **skill development**. A real codebase teaches things tutorials often skip: reading unfamiliar code, tracing behavior across files, running tests, matching the project's style, and explaining your change clearly. Even if no recruiter opens your pull request, this experience can still help in interviews. You have better examples to talk about because you have dealt with real constraints.\n\nThe second benefit is **credibility**. A merged pull request to a real project says something specific: someone responsible for that project reviewed your work and accepted it. That is different from a personal project where you make all the decisions yourself. Personal projects are still valuable, but a merged contribution shows that you can work inside someone else's standards.\n\nThere can also be a relationship benefit, but keep it realistic. If you contribute thoughtfully over time, maintainers may start to recognize your name. Sometimes that leads to referrals, introductions, or job conversations. It happens, but you should not build your whole job search around it. Your first merged pull request may take a few days, or it may take several weeks. Becoming known in a project usually takes months.\n\nThe diagram below shows how one accepted contribution turns into a career signal a hiring manager can use.\n\n\n```mermaid\nflowchart LR\n A[Work in a real
codebase]:::start --> B[Pass review
and merge]:::main\n B --> C[Public, verifiable
record]:::support\n C --> D[Hiring manager
can trust it]:::yes\n\n classDef start fill:#00ceff,stroke:#000,color:#000\n classDef main fill:#ffa94d,stroke:#000,color:#000\n classDef support fill:#38d9a9,stroke:#000,color:#000\n classDef yes fill:#69db7c,stroke:#000,color:#000\n```\n\n\nThe chain only works end to end. Work that is never merged stops at the first step, and a merge that nobody can find does not build trust. The value comes from accepted work that stays public and checkable.\n\n---\n\n# Deciding Whether Open Source Is Worth Your Time\n\n### Be clear about what you want from it\n\nDecide what you want from open source right now. If your main goal is a resume or interview signal, one or two meaningful merged pull requests to active projects can help. If your main goal is to become stronger as an engineer, depth matters more. Stay with one project long enough to understand it, improve it, and earn some trust.\n\n### Give more weight to accepted work than attention\n\nWhen choosing where to spend your time, a small contribution merged into a useful project often says more than a personal repo built mainly to attract stars. Your own projects still matter, especially for showing initiative and product thinking. But a merge into someone else's project proves a different skill: you can contribute in a shared codebase.\n\n### Understand what the contribution proves to a hiring manager\n\nA merged pull request shows that you can read unfamiliar code, follow existing conventions, make a focused change, handle feedback, and communicate with a maintainer. That is close to normal engineering work. If I were reviewing a junior candidate, I would rather see one clear merged fix with a thoughtful discussion thread than five unfinished demo projects.\n\n### Set a realistic timeline\n\nA first merged pull request can land within a couple of weeks if you choose an active project and a small issue. It can also take longer for reasons that have nothing to do with your ability. Maintainers are busy. Projects have release cycles. Some reviews move slowly. Treat the first month as a learning period, not as proof that open source is or is not \"working.\"\n\n### Decide honestly whether open source is your priority now\n\nOpen source is useful, but it is not required for every candidate. If your resume is unclear, your core projects are missing, or your interview basics need work, start there first. Open source is most helpful when it adds evidence to an already solid profile, or when you want the learning that comes from working in a shared codebase.\n\n### If it is a yes, commit to 60 days\n\nOpen source rewards consistency. A two-month commitment is long enough to find a suitable project, get one small pull request merged, and possibly start a second. That is far more realistic than trying it for one weekend and quitting because the first maintainer did not reply.\n\nUse this as a simple decision guide.\n\n\n```mermaid\nflowchart TD\n A[Should open source
be my focus now?]:::start --> B{Resume and
projects solid?}:::q\n B -->|No| C[Fix those first
Modules 02, 05]:::warn\n B -->|Yes| D{Targeting roles where
open source matters,
or want the practice?}:::q\n D -->|No, and short
on time| E[Optional
skip to Module 07]:::mid\n D -->|Yes| F[Commit 60 days
continue this module]:::yes\n\n classDef start fill:#00ceff,stroke:#000,color:#000\n classDef q fill:#ffd43b,stroke:#000,color:#000\n classDef warn fill:#ff8787,stroke:#000,color:#000\n classDef mid fill:#ffa94d,stroke:#000,color:#000\n classDef yes fill:#69db7c,stroke:#000,color:#000\n```\n\n\nIf your resume and projects already show strong evidence, you are short on time, and you are not targeting roles where open source matters much, it is reasonable to skip this for now. If you do choose it, give it enough time to produce real evidence.\n\n---\n\n# What a Merged PR Proves\n\n\n| Signal | What the hiring manager reads |\n|--------|-------------------------------|\n| You read an unfamiliar codebase | You can ramp up on existing work, which is a major part of most engineering jobs |\n| You followed the project's conventions | You can adapt to a team's style |\n| Your code passed review | Someone responsible for the project accepted your work |\n| You worked with a maintainer | You can take feedback and communicate clearly |\n| The work is public and verifiable | The claim can be checked, not just stated on a resume |\n\n\nA personal project can show that you can build something from scratch. A merged pull request shows that you can improve something other people maintain. Both are useful. For many engineering jobs, the second signal is especially relevant because most work happens inside existing systems.\n\n---\n\n# Weak Signal vs Strong Signal\n\nThe difference between open source that helps your search and open source that does not usually comes down to whether the work was accepted by a real project and whether you can explain the value of the change.\n\n**Weaker signal:**\n\n\n```javascript\nBuilt a task-queue library and published it on GitHub. It has 80 stars,\nbut no outside contributors and no known production users.\n```\n\n\n**Stronger signal:**\n\n\n```javascript\nMerged 3 PRs into a widely used task-queue library: fixed a retry bug\nunder high concurrency, added a config option requested in an issue, and\nimproved the docs for a confusing API. All three changes were reviewed\nand accepted by the maintainers.\n```\n\n\n**Why the stronger version works:** The first example may still be worth mentioning if the project is well built, but the evidence is limited. The second example shows reviewed, accepted work in a shared codebase. It is closer to what an engineering team needs from a new hire.\n\n---\n\n# Mistakes That Waste the Effort\n\nThe whole point of this work is merged, reviewed code that someone else maintains, and the items below all burn weeks chasing things that never produce that proof.\n\n- **Chasing stars instead of accepted work.** Stars can be useful context, but they are not the same as reviewed, merged work in a project other people maintain.\n- **Expecting recognition too quickly.** You are unlikely to become a trusted project regular in a month. A first pull request in that time is realistic. Influence takes longer.\n- **Treating open source as mandatory.** It is one good path, not the only path. Some candidates should improve their resume, projects, or interview skills first.\n- **Making one pull request and disappearing.** One contribution can help, but a short, steady run helps more because it shows consistency and gives maintainers a chance to recognize your work.\n- **Contributing with no goal.** Random pull requests across many projects rarely build depth or relationships. Decide whether you want skill growth, resume evidence, or both.\n- **Ignoring the learning value.** Even if no recruiter studies your pull request, the experience of working through a real review can make you better in interviews and on the job.","pageType":"job-search"}

Get Premium