Internships, Freelance, or Open Source: What to Highlight

Highlight the internship, freelance assignment, or open-source contribution that best proves the target role's work, regardless of which label sounds most impressive. An internship may show team processes, freelance work may show independent delivery to a client, and open source may show a reviewable contribution in a shared project. Describe the task, your own action, the deliverable, and the setting. Do not treat a proposed gig, unmerged pull request, or unpaid practice piece as completed client or production work.

Compare evidence, not prestige

There is no universal ranking in which every internship beats every freelance project, or every open-source contribution beats a class assignment. A short internship with mostly observation may provide less relevant evidence than a completed client deliverable. A substantial accepted code contribution may be stronger than a freelance task unrelated to the role. The target job determines which example deserves attention.

Ask four questions for each experience: How close was the work to the target task? What did you personally decide or deliver? Can someone verify or inspect the output? What context or constraints made the work meaningful? Use those answers to choose section order and bullet space.

The work experience glossary explains that employment is not the only source of relevant work. The label still matters because employers need to understand whether the work was supervised, client-facing, public, paid, or self-directed.

Step 1: Describe what each setting can prove

Internships can demonstrate working within an organization: responding to a supervisor, using team tools, following procedures, and contributing to real deadlines. Their value depends on the work, not the title alone. If your internship involved research notes and a recommendation, describe those outputs. If it was mostly observation, say what you actually learned or assisted with rather than inventing ownership.

Freelance work can demonstrate scope setting, client communication, delivery, and revision. It may also reveal the challenge of working with limited resources. A paid contract is still subject to confidentiality and permission. If you created a sample for a prospective client that was never commissioned, label it as a proposal or independent project, not a client engagement.

Open-source work can demonstrate working in a shared codebase, responding to review, documentation, tests, or maintenance. A merged contribution is easy to link, but a useful issue report, documentation change, or reviewed proposal can also show judgment. State the status precisely. An unmerged pull request is work you attempted, not a production feature.

Step 2: Pick the strongest example for this application

Read the role's main responsibilities. A junior software role that emphasizes collaboration and code review may value a small merged fix with a clear discussion thread. A design role that involves client discovery may value a freelance project with a real brief, revisions, and a deliverable you have permission to show. A research assistant role may value an internship where you followed a protocol and documented data carefully.

Make a three-line evidence note for each candidate example: target requirement, my action, proof available. If you cannot explain the action or show any evidence, ask whether another example would be stronger. Do not use a numerical ranking that pretends different employers value the same signals identically.

Example: software engineering application. A student completed an internship where they attended planning meetings but did not change the codebase. They also submitted a documentation fix to an open-source library that a maintainer reviewed and merged. For a role that values clear technical writing and collaboration, the merged contribution may deserve a prominent bullet and link. The internship can still show exposure to team routines, but the candidate should not claim to have shipped code there.

Example: marketing coordinator application. A student has a freelance newsletter assignment for a local nonprofit, with a brief, two revision rounds, and a final newsletter they are allowed to show. They also joined a short internship with little direct writing. For a role requiring email copy and stakeholder feedback, the freelance item may be the stronger lead. The candidate should describe the actual client and scope without implying the newsletter alone produced an unmeasured fundraising result.

Step 3: Give each experience an accurate resume label

Use the real employer or project name, your role, dates, and setting. An internship belongs under Experience with "Intern" in the title when that is what the employer called it. Freelance work can be listed under Experience or Projects depending on the scope, with "Freelance" or "Contract" clear. Open-source work may fit under Projects or Contributions, especially when several small changes belong to one project.

Do not hide the distinction by giving every entry a corporate-sounding title. "Independent contributor" can be accurate for open source, but the reader should still know the project was community maintained. Likewise, a freelance website for one client is not a role as "Head of Web Strategy" unless that was truly the contractual scope.

Be precise about group outcomes. If three interns worked on a report, describe the section you researched or the analysis you performed. If a maintainer changed your proposed solution during review, credit the review process and state what was merged. If a client provided the design and you implemented it, do not claim the design as your own.

You can combine several small assignments under one clearly named freelance entry, but give a representative client task its own bullet when it shows the target skill. For open source, a Contributions or Projects entry can group documentation, issue triage, and code under the same project. Do not compress different statuses into a single claim such as "shipped features" if one item was only proposed. A reader should be able to match each claim to a real artifact or explanation.

If an internship and freelance assignment happened during the same period, preserve their actual dates. Overlap is normal for students. There is no need to disguise it through a vague timeline. When a role was part-time or occasional, say so if the scope might otherwise imply full-time employment. Accurate labels make the strongest parts of your work more credible.

Step 4: Write bullets that show task, contribution, and result

An employer needs more than the setting. Start with your action, name the method or tool when relevant, and identify the deliverable or observable outcome. A result may be a completed document, accepted change, working page, clear handoff, or client approval. Use a metric only when you know its source and what it measures.

Internship bullet: "Documented recurring support questions and drafted help-center updates for supervisor review." This distinguishes drafting from final approval and shows a real output.

Freelance bullet: "Developed a newsletter from a client brief, revised the copy after two review rounds, and delivered the approved version." Use the count only if that is what happened; otherwise say "after client feedback."

Open-source bullet: "Updated installation instructions in a community library and incorporated maintainer feedback before the change was merged." If it was not merged, replace the final phrase with the actual status. The strong resume bullet guide covers action, context, and evidence in more detail.

Step 5: Provide proof without exposing private material

A public pull request or documentation link can support open-source claims. A freelance sample may require client permission. An internship deliverable may be confidential even if you wrote it. Do not upload private data, code, designs, or internal documents merely to make a portfolio look stronger. A short explanation of the work, with sensitive details removed, can still show your method.

The proof-of-work guide is written for career changers but its project-labeling and confidentiality principles also apply here. If you need a shareable site for approved samples, Democruit personal website templates provide a place to present selected work. The site should not be used to imply client approval you have not received.

For a private internship report, you can describe the problem, your method, and your specific section without copying the report or naming the organization. For a client design, ask whether you may show a final image, an anonymized process summary, or neither. For an open-source pull request, check the public thread before linking: review comments can be useful evidence of how you responded, while an abandoned proposal may require a short explanation of what happened. Never use a public link as a substitute for explaining your contribution in the resume itself.

For internship applications, the internship resume guide shows how coursework and campus evidence can sit beside work experience. If a letter is requested, the internship cover letter scenario can help explain why a particular project fits the employer's task without repeating your resume.

When none of the three examples is an exact match

An entry-level posting may ask for work you have not done in any setting. Choose the nearest task you can explain and name the difference. If the role involves reviewing production code, a reviewed class repository can show your response to feedback, but it does not prove production maintenance. If the role involves managing client accounts, a freelance design revision can show client communication, but it may not prove ongoing account ownership. That boundary helps the employer judge what training you would need.

You can also combine evidence from different settings without forcing one example to carry every requirement. An internship can show team routines, a freelance project can show a completed deliverable, and an open-source contribution can show public review. In a cover letter or interview, connect them to the role in one short explanation. On the resume, let each entry do its own job: factual title, specific task, your contribution, and status. Too many repeated bullets about "collaboration" make three varied experiences look identical.

If the opportunity was brief, state what was completed within that window. A one-day contribution does not need a grand title, but a carefully documented fix can still be relevant. If the work ended without a deliverable, a concise account of the research, proposal, or handoff may be honest evidence. Leave it off when you cannot identify a contribution or answer a follow-up about the process.

Common mistakes and how to fix them

1. Leading with the most prestigious label. It can bury a more relevant deliverable. Lead with the example that best answers the job's requirements.
2. Claiming an internship team's entire output. Separate your action from the team's work and any supervisor approval.
3. Treating a proposal as a freelance contract. Label uncommissioned work as a proposal or independent sample.
4. Calling an unmerged change a shipped feature. State whether it was proposed, reviewed, accepted, or merged.
5. Publishing private material. Get permission or use a safe description and approved sample.
6. Listing tools without the task. A tool name alone says little. Show what you used it to deliver.

Best practices

Keep a private record of each experience's scope, your contribution, feedback, and current status. Confirm links still work before sending an application. Update an open-source bullet when the contribution status changes. If your best example is small, explain it well rather than inflating its size. A clear, modest contribution can be easier to trust than a broad claim with no inspectable work.

Final checklist

• I selected the lead example based on the target role, not prestige alone.
• Each entry names its real setting, role, and dates.
• My bullets distinguish my actions from team or maintainer work.
• Freelance and open-source status are described accurately.
• Any public sample is safe and permitted to share.
• Every major claim has a deliverable or explanation I can provide.

Frequently asked questions

Is a freelance project better than an internship?

Neither is automatically better. Compare what you did with the target role's tasks and how clearly you can show the output. A small completed client project may be more relevant than a mostly observational internship for some roles.

Does open-source work count if it was unpaid?

Yes, it can demonstrate relevant work. State the project, your contribution, review or merge status, and any link the reader can inspect. Do not present it as paid employment.

Can I include a pull request that was not merged?

You can if the work and discussion are relevant. Label it as proposed or reviewed, explain what you learned or changed, and do not imply it reached production. A merged change is not the only useful evidence, but the status matters.

How should I list several small freelance jobs?

Group them under one clearly labeled freelance entry when that makes the timeline easier to read, then choose representative projects. Keep client names and samples only where you have permission, and describe the actual scope of each example.