What counts as proof of work
- A project that runs. A web app, a command-line tool, a small service, a script others have used.
- An open-source contribution. A bug fix, a documentation improvement, a test. Small and accepted counts.
- A write-up. A short post on how you solved a hard problem, with code.
- A hackathon or competition result, with a link to what you built.
- A tool for a real person. A club website, a notes app for your class. Real users matter.
Certificates and course completions are fine to list, but they are not proof you can build something. A reader can't open one and see how you think.
Make it easy to judge in a minute
A recruiter or engineer who clicks your link will give it about a minute. Make that minute count with a README that answers these questions:
- What is it? One sentence at the top.
- Why did you build it, and for whom?
- What does it look like? A screenshot, a short GIF or a live link.
- How do I run it? Three commands that work on a fresh machine.
- What was hard? A paragraph on one real problem and how you solved it.
- What would you improve? Honest limitations are a good sign.
Add a few tests and a short description in the repository settings. Pin your best two or three repositories on your GitHub profile.
Describe it in one sentence
Use this shape: what it does, for whom, with what, and the result if you have a true one.
Vague descriptions and specific ones
| Vague | Specific |
|---|---|
| A web app using React | A meal-planning app in Next.js and Supabase with offline support and shared household lists |
| A machine learning project | A question-answering tool over 2,000 research papers, with a 150-question evaluation set to compare retrieval methods |
| A backend project | A replicated key-value store in Go with leader election, benchmarked at 25,000 writes a second on three nodes |
Starting with open source
- Pick a project you already use. You know where the rough edges are.
- Look for issues labelled "good first issue" or "documentation".
- Read the contributing guide, and keep the change small.
- Fix a typo or clarify a docs page to learn the workflow, then take a real bug.
- Link the accepted pull request on your resume and in your emails.
A four-week plan
From nothing to something you can show
| Week | Do this |
|---|---|
| 1 | Pick one small project you'd use yourself. Write the one-sentence description before you write code. |
| 2 | Build the smallest version that works end to end. Deploy it or record a short demo. |
| 3 | Write the README, add tests for the core path, and fix the biggest rough edge. |
| 4 | Put it on your resume, then write to five companies with it as the main line of your email. |
Using it in a cold email
Lead with the project in one sentence, link it, and connect it to the company only if the link is true. The structure is in how to cold email a recruiter.
Frequently asked questions
- Do I need open-source contributions to get an internship?
- No. They help, but a finished project of your own, well explained, is enough to start with.
- What if my project is a tutorial clone?
- Make it yours: add a feature the tutorial doesn't have, change the problem it solves, and say what you changed. Don't present a tutorial project as original work.
- How big should my project be?
- Small and finished beats large and abandoned. Something you can explain in ten minutes and run in two.
- Should the project be deployed?
- A live link makes it easier to judge, but it isn't required. A short screen recording and a README with clear steps work too.