Running Production-Grade Software Internships (Not Sandbox Projects)

A common shape for a software internship is a sandbox: a toy app, a scoped side project, something that will never see a real user, built so a student can learn without any risk to the actual product. The problem with that structure is what it fails to teach. Syntax and basic patterns, sure. But nothing about what it means to open a pull request against a codebase other people depend on, nothing about a senior engineer asking why a query is written the way it is, nothing about the moment an assumption that worked in the sandbox turns out wrong against real data. We have run our internship program the other way: interns work on scoped, reviewed pieces of our actual production branches, with a named engineer directly responsible for their ramp-up.

This is not a sandbox with better marketing. Interns from Rathinam Technical Campus, a technical college near us in Coimbatore, have written code that shipped. The difference from a typical junior contribution is the scaffolding around it: what they touch is chosen deliberately, what they submit is reviewed the same way any engineer's code is reviewed, and the scope of what they are trusted with widens only as they demonstrate they understand not just how to write the code, but why the system is built the way it is.

What "production-grade" actually requires

The core structural decision is pairing, not a rotation. Each intern has one senior engineer who owns their onboarding, reviews their pull requests, and is the person they ask when something does not make sense. A rotating cast of mentors sounds more collaborative on paper, but in practice it means nobody is actually accountable for whether the intern is learning the right things, and the intern spends more time re-explaining context to a new mentor than actually building.

Starting narrow, on purpose

The first tasks we give an intern are deliberately small and low-risk: a bug fix with a clear reproduction, a UI change with an obvious visual outcome, a test suite that is missing coverage for a case we already understand. The point of starting there is not that the work is unimportant — it genuinely ships — but that it lets us calibrate how someone works before handing them something where a mistake is expensive. A pull request against a real branch also comes with real review comments, often several rounds of them, which is a different experience than a grading rubric and a much better teacher of what production code actually needs to look like.

As that trust builds, scope widens: a feature slice with a defined interface, then a small service boundary, then eventually something closer to what a junior full-time engineer would own. What never changes is the review discipline — every change an intern makes goes through the same pull request process as everyone else's, with the same expectation that the reviewer actually reads it rather than rubber-stamping it because the author is a student.

What we screen for before we screen for skill

We do not select interns primarily on prior project portfolios, because a polished personal project is not a strong signal of how someone handles being told their code has a problem. What we actually look for in the first conversation is how someone responds to a question they don't immediately know the answer to — whether they think out loud, whether they ask a clarifying question instead of guessing, whether they can say "I don't know, let me check" without treating it as a failure. Technical fundamentals matter and we do check for them, but they are the baseline, not the differentiator. The differentiator is whether someone is going to be teachable once they are inside a codebase with real constraints and a reviewer who will push back.

The parts that make it uncomfortable, and why we keep them

A real review process means an intern's pull request sometimes gets several rounds of change requests, and that is not a comfortable experience for someone used to grades that reward a finished submission. We keep it anyway, because softening the review defeats the entire premise — the value of working on production code is precisely that the standard does not lower for the author. What we do adjust is pacing and scope, not rigor: we give an intern more time on their first few pull requests than we would give a full-time engineer, and we make sure the senior engineer reviewing is explaining the why behind a comment, not just leaving "fix this." A comment that only says what is wrong teaches nothing; a comment that explains why the current approach breaks under a specific condition is the actual lesson.

We also run short retrospectives at natural breakpoints — after someone's first shipped feature, for example — where the conversation runs both directions. We ask what confused them and what they wish someone had explained earlier, and we have changed how we onboard the next intern based on that feedback more than once. Treating the internship as something we are also learning to run better, rather than a fixed program we execute the same way every time, has mattered more to the quality of the experience than any single process decision.

What "graduating" a scope looks like in practice

One concrete example: an intern started with a handful of narrowly scoped bug fixes in a form validation module, each reviewed line by line with comments explaining why the existing pattern was written the way it was. A few pull requests in, once the reviews had shifted from correcting fundamentals to smaller style notes, we handed over a self-contained feature — a new field type in that same module — with a defined interface but no step-by-step spec, and let them design the approach before reviewing it. That is the actual signal we use to widen scope: not time served, but review comments changing in kind, from "this is wrong" to "this works, here is a cleaner way to express it." When the second kind of comment becomes the norm, we know the next scope increase is reasonable rather than a leap of faith.

What we would tell another small team trying this

The honest caveat is that this only works if the senior engineer doing the mentoring has real slack in their week — pairing and detailed review comments take time that would otherwise go into their own output, and pretending that cost does not exist is how internship programs quietly become sandboxes again, because a reviewer under deadline pressure reverts to rubber-stamping. If your team is already stretched thin, running this well probably means fewer interns at a time, not more corners cut on review. We would rather run one internship properly than three that drift into the sandbox pattern we were trying to avoid in the first place.

The other thing we would say plainly: this is slower, week to week, than letting an intern build an isolated side project nobody has to review carefully. A sandbox project can run entirely on the intern's own schedule, with feedback only at the end. Ours requires a senior engineer's attention on a rolling basis for the length of the internship. We think what interns actually learn is worth that cost, but it is a real cost, and a team deciding whether to run something like this should weigh it honestly rather than assume production-grade mentorship is free just because it produces better outcomes.

We are not listing this as a formal service, because it is not one we currently offer to outside organizations — it is how we run our own team, described honestly rather than dressed up as a program with a name. If you are building something similar at your own company, or you are a student in Coimbatore curious about how this actually works day to day, we are happy to talk about what we have learned running it. That is a lower-key conversation than a sales pitch, and we would rather be upfront about that than imply a formal offering that does not exist yet.