The first internship can run on memory.
One coordinator knows the student, the mentor, the project, and the next deadline. When progress slows, that person notices. When the scope changes, that person explains why. The arrangement may produce excellent work.
It does not yet produce a program.
As the ICPC Foundation internship initiative grew across projects and seasons, the central problem changed. Matching talented students with useful work remained important. The harder task was making each placement legible enough that another person could review it, operate it, and improve the next cycle.
Start with a contribution
An internship description often begins with a domain: web development, contest problems, publishing, mobile applications, or training. A domain does not tell the intern what finish they own.
I want each placement to begin with a contribution that can be inspected. The contribution may be a released feature, a reviewed problem package, a maintained section of an archive, or a documented operating process. It should matter to a real program and fit within the period available.
The project record names:
- the user or program waiting for the result;
- the first deliverable;
- the reviewer who can accept it;
- the dependencies outside the intern’s control;
- the condition for completion.
This record can change. Without it, a change in scope is indistinguishable from drift.
Make review a scheduled operation
“The mentor will provide feedback” is an intention. The program needs a review path.
Who sees the first draft? How long may it wait? Which decisions can the intern make alone? What happens when the reviewer is unavailable? Which work requires a second check before release?
I prefer a cadence that makes missing feedback visible. A weekly review may be appropriate for a short technical project. A contest problem needs independent solution and data review at defined stages. A publication project may need editorial acceptance before layout begins.
The cadence should follow the cost of late correction. A naming choice in a prototype can wait. A false assumption embedded across a problem package cannot.
Teach through shared work
Individual mentorship does not scale by replacing mentors with lectures. It scales when common instruction removes repeated friction and leaves project judgment with the reviewer.
A weekly masterclass can teach how to write a useful status update, review a technical artifact, test a claim, or close a project. The session should feed the work already in progress. Interns bring an actual decision, use the method, and return with a changed artifact.
The common session also reveals program-level failures. If several interns cannot identify who accepts their work, the problem is not individual initiative. If projects repeatedly stall at access or deployment, the program has found an operating constraint.
Record decisions where the next owner can find them
Chat messages are useful for coordination and poor as the only institutional memory.
Each project needs a small durable record: current finish, owner, latest accepted artifact, open decision, and next checkpoint. The record should live with the program or project, not in one coordinator’s account.
I do not ask interns to document every conversation. I ask them to preserve the facts a replacement would need to continue without reconstructing the season from inboxes.
This is also part of the training. Technical work includes leaving a system another person can operate.
Define completion before the final week
Internships often end by calendar. The student gives a presentation, returns access, and leaves. The project may remain in a state nobody has accepted.
I use explicit finish states:
| Finish state | Meaning |
|---|---|
| Released | The intended user can use the accepted result |
| Handed off | A named owner accepted the artifact and remaining work |
| Closed with findings | The project answered its question without producing a release |
| Incomplete | The intended result and a valid handoff are both absent |
The category is less important than the honesty. A prototype that disproves an approach may be a strong finish. A large body of unreviewed code may not be.
The final review records what changed, what remains, who owns it, and which access or knowledge must transfer.
Measure the system separately from the student
When a placement struggles, the program should not begin by assigning the entire result to the intern.
The contribution may have been too broad. Review may have arrived late. A dependency may have remained blocked. The project may have lacked a real user. The intern may also have made weak decisions or failed to communicate. Those explanations require different changes.
I review the program through operational questions:
- Did the placement begin with an inspectable contribution?
- Was a reviewer available at the required cadence?
- How long did blocked work remain invisible?
- Did common instruction change active project work?
- Did the final state include acceptance or a named handoff?
- Which part still depended on one person’s memory?
Participant feedback and completion counts provide useful signals. The operating record explains what to change.
The goal of the internship is growth through consequential work. The goal of the program is to make that work possible again next season, with more people able to carry it.