External Proof: Open Source, Hackathons and Writing About Your Work

You built a project, deployed it and wrote a good README. To a recruiter, it is still something you say about yourself, however well presented. The next step up the proof ladder is evidence that someone else looked at your work and valued it: a maintainer merged your change, judges picked your project, readers responded to your post.

You need only one of these. This article covers all three so you can choose the one that suits your time and target companies.

• How to choose an open-source project that helps your applications, and find a real issue in it.
• The etiquette of contributing, so that your first pull request is welcome.
• How to describe a contribution on your resume, merged or not.
• Which hackathons are worth your time and what to take away from them.
• How to write a short technical post about your work, with AI as an editor.

The common mistake is to aim at the most famous projects, such as large frameworks or operating system kernels, get lost in a huge codebase and give up. Or to fix a typo in documentation, which helps the project a little and proves almost nothing about you.

A better approach, stack-aligned contribution:

1. Note the stack in your target companies' job descriptions (article 7 already gave you this list): the language, the framework and the libraries they name.
2. Find smaller libraries in that stack: plugins, client libraries, validation libraries, testing utilities. A library with a few hundred to a few thousand stars, active maintainers and recent releases is a good size.
3. Find a real issue: a bug with steps to reproduce, a missing test for an existing feature, a small, well-defined feature request, or an error message that confuses users.

The connection then works in your applications: "Your team uses [library]; I fixed [issue] in it: [link]." Few freshers can say that.

Maintainers are usually volunteers or busy employees. A contribution that costs them more effort than it saves is unwelcome, however well meant. Follow this order:

1. Read the contribution guide (CONTRIBUTING.md) and the code of conduct. Follow their rules on branches, tests, commit messages and signing.
2. Reproduce the problem locally before anything else. If you cannot reproduce it, say so on the issue with what you tried.
3. Comment before you start: "I'd like to work on this. My plan is [one or two sentences]. Does that fit?" Do not just write "please assign me", and do not start on an issue someone else is already working on.
4. Keep the change small and focused. One issue, one pull request. Do not reformat unrelated files.
5. Add or update tests that fail before your fix and pass after it.
6. Describe the pull request well: what was wrong, how you fixed it, how you tested it, and a link to the issue.
7. Respond to review politely and quickly. Review comments are a free lesson from an experienced engineer.

This is a good use of an assistant: it can read code quickly and explain structure. Ask it to point you to places to read, and verify by reading them yourself.

I want to fix this issue in an open-source library: [paste issue text].Below are the README, the folder structure and the files I think are relevant.1. Explain how the relevant part of the code works, citing file and function names   from what I pasted.2. Where is the bug most likely to be, and why?3. What test would reproduce it?Do not write the fix. Say clearly if the answer depends on code I did not paste.[paste README, tree output, and relevant files]

Then read those files yourself, reproduce the bug, and write the fix.

A merged pull request is the strongest version. An open pull request that fixes a real issue still shows work, as long as you describe it honestly:

Open source: Fixed incorrect time-zone handling in date parsing in [library](used by [n] dependants on GitHub). Added 6 regression tests. Merged. [PR link]Open source: Proposed a fix for [issue] in [library], with tests; under review. [PR link]

Never describe an open pull request as merged, or a typo fix as "contributed to [famous project]". The link lets anyone check, and interviewers do.

A hackathon gives you three things: a deadline that forces you to finish something, a team experience you can talk about in behavioral rounds (article 34), and occasionally a result that others decided on.

• Devpost: many online hackathons worldwide, often with sponsor prizes.
• Unstop: a large Indian platform for student competitions and hackathons, including company-sponsored ones.
• Major League Hacking (MLH): a student hackathon league with many online and in-person events.
• Company-run hackathons and hiring challenges: some companies use these to find candidates.
• Your college and nearby colleges: smaller events, often with less competition.

• Look at all the prize categories, not just the grand prize. Many hackathons have category prizes for the best use of a sponsor's technology, the best beginner project and so on, which are easier to win and just as verifiable.
• Scope ruthlessly. A small demo that works beats an ambitious one that crashes during judging.
• Keep the code afterwards. Push it to your GitHub with a README and a short video of the demo. A hackathon project you can show is worth much more than a line saying you took part.
• Know your part. In a team, be ready to say exactly what you built.

On your resume:

Winner, Best Use of [Sponsor] API, [Hackathon name] ([platform], [month year], [n] teams).Built [what] with [stack] in 36 hours; I built [your part]. [repo] [demo video]

"Finalist" or "top 10 of 300 teams" is worth listing if it is true and checkable. Participation alone is not worth much space; the project you built is.

A short post about something you built shows that you understand it well enough to explain it, and it gives you a link that comes up when someone searches your name. It does not need to be long or clever.

Good topics for a first post are specific and first-person:

• One decision: "Why I used idempotency keys in my payment service, and the race condition I found."
• One bug: "The time-zone bug that broke my booking app, and how I tracked it down."
• One measurement: "How adding an index took my search endpoint from 400 ms to 15 ms."
• One contribution: "My first open-source fix: what I learned from the code review."

Avoid generic tutorials ("What is REST?"). Thousands exist, and they show nothing about you.

Developer blogging platforms (such as dev.to and Hashnode), your own portfolio site, or LinkedIn articles all work. Cross-posting is fine if the platform allows it. Link the post from your project README and your LinkedIn Featured section (article 13).

Recruiters and engineers increasingly recognise AI-written posts: smooth, generic and empty of real detail. They also tell readers that you did not write it. Write the draft yourself, then use AI to improve it:

Below is a draft blog post I wrote about a bug I fixed in my project.Act as a strict editor. Do not rewrite it in your own style.1. Which paragraph is hardest to follow, and why?2. Where does a reader need a detail I did not give (a number, an error message,   a code snippet)? List questions, not answers.3. Which sentences are generic and could appear in anyone's post?4. Suggest a clearer title, keeping it specific.Keep my voice. Point out problems; I will fix them myself.[paste draft]

Communities such as Reddit's programming and side-project forums, or "Show HN" on Hacker News, can bring feedback and readers, but they are blunt and have strict rules against self-promotion. Share only when the project is genuinely useful to others, read each community's rules first, and treat criticism as free review.

Farhan targets companies whose job posts mention Spring Boot and a particular validation library.

• Open source: while building his project he finds that the validation library gives a confusing error message for one case. He searches the issues, finds it reported but unfixed, comments with a plan, gets a maintainer's go-ahead, and submits a small fix with two tests. After one round of review it is merged.
• Writing: he writes an 800-word post about the bug, the review comments and what he learned about the library's internals, with an AI editor pass that points out two places where readers would need the actual error message.
• Resume line: the merged pull request, with the link, under a separate "Open source" heading.

In an interview at a company using that library, this becomes a ten-minute conversation he leads.

• Typo-only pull requests to famous projects, listed as "contributor to [project]".
• Starting work without commenting on the issue, then finding someone else already fixed it.
• Submitting AI-generated changes you have not tested or understood.
• Entering hackathons to collect participation certificates instead of shipping something showable.
• Publishing an AI-written post under your name.

Hi, I'd like to work on this if no one else is.I can reproduce it on the latest release: parsing "2026-03-01T10:00:00Z"throws a DateTimeParseException, while "2026-03-01T10:00:00+00:00" works.My plan: treat a trailing "Z" as UTC in [the parsing function], and addtests for "Z", "+00:00" and a non-UTC offset. Does that approach fit howyou'd like this handled, or is there a reason "Z" is rejected on purpose?

• Next: Honest Numbers: Measuring and Quantifying Student Projects adds the measurements that make your proof convincing.
• For using AI to understand unfamiliar code, see the AI course's articles on coding assistants, starting with AI Coding Assistants: Modes, Strengths and Your Responsibility.
• For editing your writing with AI without losing your voice, see How to Use AI for Emails and Documents Without Losing Your Voice.