How to Make the Most of an Unpaid Internship as a Developer

TL;DR - An unpaid internship is a time-limited exchange: your labor for experience, exposure, and a reference. You need to maximize all three. - Scope your work intentionally so it results in a portfolio piece. If the org doesn't have a project brief, write one yourself. - Build the relationship with your supervisor week by week. A strong reference doesn't happen automatically at the end. - Document your work throughout, not just at the end when you're scrambling to update your resume. - Know the signs that an organization isn't holding up their end, and know when to walk away. - What you take out depends almost entirely on how deliberately you go in.

Unpaid internships get a lot of justified criticism. The model is imperfect, often inequitable, and sometimes exploitative. None of that is untrue.

But they exist, and for some junior developers, they're the most accessible path to real experience and a technical reference. If you're going to take one, go in with a plan to actually get something from it. That means being deliberate about the work you take on, the relationship you build with your supervisor, and the evidence you collect along the way.

Here's how to do that week by week.

Before You Start: Set Expectations Upfront

The biggest mistake people make in unpaid internships is starting without clarity on what they're working toward. "I'll figure it out as I go" leads to weeks of ambiguous work that you can't put in your portfolio and a supervisor who doesn't know you well enough to give a strong reference.

Before your first day, try to get answers to:

What will I be working on? If the answer is vague ("various projects," "whatever comes up"), push for more specificity. Ask if there's a specific initiative, feature, or project you'll own during your time there.

Who will I be working with directly? Know who your day-to-day supervisor is. This is the person whose opinion of you will become your reference.

How will we measure whether this was successful? A question like this signals that you're serious about delivering something. It also forces the organization to think concretely about what they want from you.

What does a successful end product look like? If they want a working feature, ask what "working" means. What should it do? Who will use it? How will you know when it's done?

Some organizations won't have crisp answers to these questions. That's a yellow flag, not a dealbreaker. But it means you'll need to create this structure yourself.

Scope Your Work So It Becomes a Portfolio Piece

At the end of your internship, you want to have something you can show: a deployed feature, a tool that people are using, a meaningful contribution to a real codebase. Getting there requires scoping your work with the end in mind.

Write a project brief if they don't have one

If the org doesn't hand you a clear project definition, write one yourself and share it with your supervisor for sign-off. A one-page document that answers:

What problem are we solving?
Who is it for?
What does "done" look like?
What are we explicitly not building?
What's the timeline?

This document protects you. If scope starts to creep, you have a record of what was agreed. It also demonstrates professional behavior that your supervisor will notice.

Aim for something deployed or merged

A feature that's deployed to production is a portfolio piece. A PR that's merged into a real codebase is a portfolio piece. A design document that sits in a Google Drive folder is not.

Push toward deliverables that exist in the world outside a local development environment. If the org doesn't have a deployment pipeline, ask how you can get your work in front of real users. Sometimes that means setting up a basic deployment yourself, which is its own useful experience.

Pick a scope you can finish

An ambitious project that's 80 percent complete at the end of your internship is weaker than a modest project that's shipped. Err on the side of smaller and finished.

Build the Reference Relationship Week by Week

A strong reference doesn't come from showing up and doing what you're told. It comes from being the kind of person your supervisor wants to tell a story about.

Check in regularly

Don't wait for your supervisor to come to you. Set a recurring 30-minute weekly check-in if one doesn't exist. Prepare a brief update: what you worked on, what you're working on next, and any blockers.

This accomplishes two things. First, it keeps your supervisor informed so your work is visible. Second, it gives you a weekly opportunity to demonstrate that you're organized, proactive, and thoughtful.

Ask for specific feedback

At some point in the middle of your internship, ask your supervisor directly: "Is there anything about how I'm approaching the work that I should do differently?" or "How would you describe my work to someone else?"

This question signals coachability. It also gives you information you can actually act on, which is important because the time to fix your approach is in the middle of the internship, not at the end.

Act on what you hear

If your supervisor gives you feedback, act on it visibly. Come back the next week and say "I tried the approach you suggested and here's what happened." This closes the feedback loop and demonstrates that working with you is productive.

Ask for a specific reference before the end

Don't wait until after your internship is over to ask. Around your last week, say directly: "I'm actively applying for junior developer roles and I'd value having you as a reference. Would you be willing to speak to my work here?"

If yes, follow up with a brief summary of what you'd like them to emphasize (specific projects, skills, growth you demonstrated) and let them know how and when they'll be contacted.

For more on building this relationship and asking well, see how to get a reference when you've never had a tech job.

Document Your Work Throughout

This is where most people fail. They do real work, learn real things, and then spend twenty minutes at the end trying to reconstruct what they actually did for their resume. The result is vague and undersells the experience.

Keep a running log

Every week, write down in plain language: what you worked on, what decisions you made, what you learned, and what the outcome was. A simple bullet list in a notes app is fine. The point is to capture specifics while they're fresh.

These notes become the raw material for: - Your resume bullet points - Portfolio case studies - Interview stories ("tell me about a time when...")

Document the technical specifics

Note the technologies you used, the architecture you worked within, the problems you hit and how you solved them. Even things that felt routine, running a migration, debugging a slow query, refactoring a module, are worth capturing.

A year from now, when an interviewer asks about your experience with Rails or PostgreSQL or whatever you used, you want to be able to say "I used it in a real project where it did X" with specifics.

Take screenshots and save links

Before your internship ends, take screenshots of what you built. Save links to merged PRs. Note the organization's name and your supervisor's contact information. These are easy to lose track of once the internship is over.

What to Do Week by Week

Here's a rough weekly rhythm that works:

Week 1: Get oriented. Set up the development environment, read the existing codebase, introduce yourself to the team, and establish a clear project brief. Don't write significant code yet. Read first.

Week 2-3: Start building. Make small, focused changes. Ask questions before getting stuck, but not before trying. Establish your weekly check-in rhythm with your supervisor.

Week 4-5: Deliver a first working version of whatever you're building. Get feedback. Iterate. Ask your supervisor for mid-point feedback.

Week 6-7: Polish and document. Ship something deployable. Write up what you built and why. Start thinking about how to present it in your portfolio.

Final week: Tie up loose ends. Ask for your reference. Update your resume log. Thank the people you worked with and keep those relationships warm.

When to Walk Away

Not every unpaid internship is worth finishing. Here are signs that the exchange has broken down:

You're not getting real work. If you're answering emails, making coffee, and doing tasks that have nothing to do with software, you're being used for labor without the experience side of the exchange. That's not what you signed up for.

There's no one available to work with you. If your supervisor is consistently unavailable, you're getting no feedback, and no one is reviewing your work, you're not learning. You're working alone, which you could do at home with more useful projects.

The project has been cancelled or shelved. This happens. If the thing you were building is no longer needed, ask to be reassigned to something with real stakes. If there's nothing, consider whether the remaining time is worth it.

You're being asked to do things outside your original scope in ways that benefit the org but not you. Some scope expansion is fine. But if you find yourself doing work that's clearly useful to the organization but adds nothing to your experience or portfolio, that's worth addressing directly.

Walking away from an internship is not a failure. Finishing an internship that isn't serving you at the cost of eight weeks you could have spent differently is.

The Test: What Did You Walk Away With?

At the end of any internship, paid or not, you should be able to answer:

What did I build? (Specific, with a link or screenshot)
What specific skills did I use or develop?
Who can speak to my work? (Name, contact info, what they'll say)
What would I do differently next time?

If you can answer those four questions clearly, the internship was worth your time.

For more on how to turn this experience into a strong application, see the guide on getting real software engineering experience.

If you're exploring nonprofit internship opportunities specifically, this guide on nonprofit software internships covers what to look for and how to approach them.

If you want structured support turning your early experience into job offers, here's how the Globally Scoped program works.