Internship fell through? Hackathons, open source and shipped projects as experience that hiring managers accept

Internships fall through for reasons that have nothing to do with you: a hiring freeze, a team reorganized out of existence, an offer that assumed a work authorization that didn't arrive in time. The summer still has twelve weeks in it, and the next recruiting cycle still opens in September with a resume that needs a line where the internship was going to be.

The good news is that an internship was always a proxy. What a hiring manager wants to know is whether you can take an ambiguous problem, build something that works, work with other people's code and opinions, and finish. Ten weeks at a company is one way to demonstrate that. There are others, and some of them produce better evidence, because the artifact is public and the manager can read it. This guide covers the three that reliably count — open source, hackathons and shipped projects — and, just as important, how to describe them so they are believed.

How managers actually weigh it

Not all non-internship experience is equal. A rough hierarchy, from most to least persuasive:

1. Code merged into a project other people depend on. It survived review by maintainers who had no reason to be kind. It is the closest thing to a job reference that doesn't require a job.
2. Something you built that real people use, however few, with a write-up of what you decided and why. Fifty active users and a clear post-mortem beat a thousand-star tutorial clone.
3. A hackathon project that kept going. The weekend itself is a sprint; what counts is the fortnight after, when you fixed what broke and shipped it to someone.
4. Coursework and solo tutorials. Fine as a floor; nobody is hired on them.

The pattern is other people. Reviewers, users, teammates, judges. Experience that involved only you and a tutorial is hard to evaluate; experience that involved other people leaves a trail a manager can follow.

Open source: pick projects where first PRs get merged

The single biggest mistake in student open-source work is choosing a project by fame. The biggest frameworks receive thousands of pull requests, and a first-time contributor's change can sit for months. What you want is a project that is actively maintained, that merges contributions from outsiders, and that has work scoped small enough to finish in a week.

On Imba Jobs the open-source page lists repos with exactly that in mind: how many pull requests from outside contributors were merged recently, median time to merge, whether there is a contributing guide, and tags for beginner-friendly repos and our "good first stop" picks. Wherever you look, the signals are the same: recent commits, issues labeled good first issue or help wanted that are not two years old, maintainers who respond in days, and a CONTRIBUTING file that tells you how to run the tests.

The first-PR playbook, which works everywhere:

• Set the project up locally and run its test suite before touching anything. If that is hard, your first contribution might be fixing the setup docs — maintainers love that.
• Pick an issue, say in the thread that you are taking it, and ask one clarifying question if the scope is unclear. Silence followed by a surprise PR is the most common way to get a polite rejection.
• Keep the change small and single-purpose. Match the project's style exactly. Add a test. Write a PR description that explains the why, links the issue, and says how you verified it.
• Respond to review within a day, without defensiveness. The review thread is part of the evidence you are building.
• After the merge, do another. Three merged PRs in one project over six weeks says more than one each in three projects.

Structured programs give this a frame and, often, money. Google Summer of Code ran its 2026 contributor application window from March 16 to March 31, announced accepted projects on April 30 and started coding on May 25, with 185 mentoring organizations this year; the 2027 cycle will follow the same shape, so the time to start contributing to a target organization is the preceding autumn. Outreachy offers three-month, remote, paid internships (a $7,000 stipend) in open source for people from groups underrepresented in tech, with cohorts running May–August and December–March. Hacktoberfest runs every October 1–31, but the 2026 edition stopped counting pull requests: rewards now come from a sticker book filled by attending Fests, joining MLH's Global Hack Week (October 9–15), checking into livestreams and submitting to the weekly DEV challenges. Treat it as a month of workshops and community, not a PR quota; the playbook above is still how contributions get merged.

A caution for F-1 students: a stipend, a paid fellowship or a cash prize can count as employment, and unauthorized employment is a serious status problem. The programs say so themselves: Outreachy tells F-1 students they may need CPT, and the MLH Fellowship FAQ says many past Fellows needed CPT or OPT. Before accepting a paid program or a cash prize, ask your DSO how your school treats it. On post-completion OPT, SEVP's OPT policy guidance lets unpaid and volunteer work related to your degree count as employment at 20 or more hours a week, which makes a serious open-source commitment a way to stop the unemployment clock — again, documented, and confirmed with your DSO.

Hackathons: the weekend is the start, not the end

A hackathon gives you a team, a deadline and a reason to ship. Judges reward demos; hiring managers, later, reward what the demo turned into. Treat the event as the first 48 hours of a four-week project.

Picking one. Imba Jobs' hackathon list and Devpost show what is open, online or in person, and whether it is beginner-friendly. Prefer events whose sponsors' tools are relevant to the kind of role you want — a payments API, a mapping SDK, an inference platform — because the project you build there is also a conversation starter with those companies. Prefer teams with one person who has shipped before.

During. Decide the one thing the demo must do and build that first; add nothing until it works end to end. Use a boring stack you know. Keep a running list of what you cut. Commit often, with messages a stranger can read, because the repo is the artifact.

After. This is the step almost everyone skips, and it is the whole difference between a line a manager ignores and one they ask about:

1. Spend two weeks making it actually work — error handling, deployment, a real database, the three features you faked.
2. Put it in front of ten to fifty people who have the problem: a student organization, a subreddit, a Discord, a campus office.
3. Write a one-page post-mortem: what you built, what you decided and why, what the numbers were, what you would change. Link it from the README.
4. Only then put it on the resume, with the numbers.

Shipped projects: a real problem, a real user, a real write-up

The strongest project on a new-grad resume is usually not a hackathon or a contribution at all. It is a small product that solved a problem for a specific group and is still running. It does not need to be novel. It needs to be used.

Finding a problem. Look where you already are. Student clubs run on spreadsheets and group chats; departments have scheduling pain; a family business has a process done by hand; international student offices answer the same questions a hundred times a term. Ask what people do today, build the narrowest thing that replaces one step, and watch them use it.

Building it. Deploy early, to a real URL, with a real domain if you can afford one. Add basic analytics so you have numbers. Keep the code public unless there is a reason not to; a manager who can read your commits can skip half the interview questions.

Writing it up. The write-up is what makes a project legible to people who did not watch you build it. Problem, users, the two or three decisions that mattered, the metrics, the thing that went wrong, what you'd do next. Short. On your site, in the README, and compressed to two bullets on the resume.

Making it legible to a parser, a model and a person

All of this fails if the resume says "Personal project — built a web app." Our guide on resumes that parse covers the mechanics; for projects specifically:

• Use a Selected Projects section with the same structure as experience: name, your role, dates, a link, and three outcome bullets. "Contributor, Project (Rust): 4 merged PRs including a 30% speedup of the parser hot path; reviewed by core maintainers" is a bullet a reader can verify in one click.
• Numbers, mechanism, tools. Users, requests, data size, latency, time saved, PRs merged. How you did it. With what.
• Roles, honestly. On a team project, say what you owned. Managers ask, and teammates are findable.
• Links that work logged out. GitHub, the live app, the write-up. Check from a private window.
• A GitHub profile README that points at the three things you most want read, with one sentence each. Pin them.

In interviews, these become your stories: the bug that took three days, the review comment that changed your design, the user who used the feature in a way you never intended. They are better stories than most internships produce, because you made every decision yourself and can explain all of them.

The twelve-week version

If the internship fell through in May and recruiting opens in September, a workable plan is: weeks one to two, three merged PRs in one project chosen for merge odds; weeks three to six, a shipped project with ten real users and a write-up; weeks seven to eight, a hackathon with a team, followed by the two-week finish; weeks nine to twelve, a second round of contributions to the same open-source project (now you know it) and interview preparation built on the stories you just acquired. Apply through the summer as internship and new-grad postings appear, and keep the resume updated as each artifact lands.

None of this replaces talking to your DSO about anything that involves money or looks like work while you are on F-1 status, and none of it is a substitute for the ordinary advice: tell your network the internship fell through, because the fastest fix is still someone who knows you and has a team with a gap.