GSoC mentor 2019-2026

I was a Google Summer of Code contributor in 2017-2018, and a mentor every year since 2019. Seven cycles. Ten-plus students. Most shipped; a few didn’t. Each cycle taught me something about engineering culture. Here is what I’ve learned about mentoring students through a real OSS project.

The contract

GSoC is a three-month structured contribution to an open-source project. The student writes a proposal, gets accepted, works on the project, and ships at the end. The mentor’s job is to ensure the student succeeds — not to write the code for them.

The success rate, across my cohorts, has been about 70%. The failures usually aren’t technical; they’re communication or calibration failures.

What separates the students who shipped from those who didn’t

The students who shipped, in seven years, shared three habits:

1. They asked questions early. When stuck, they raised it within a day, not a week. The week-long silences were the tell that things were going sideways.

2. They proposed before they implemented. A two-paragraph “I’m going to do X this way” gave me a chance to redirect before they spent a week building the wrong thing. The ones who shipped wrote these proposals weekly.

3. They reviewed their own code before submitting. A PR review from me was a check; a PR review by themselves before submission caught most of the issues I would have raised. The compounded saving over a summer was huge.

The students who didn’t ship usually:

• Disappeared for a week and re-emerged with broken work that needed major rework.
• Asked vague questions (“how do I implement this?”) instead of specific ones (“I’m thinking of approach A versus B; here are the trade-offs I see — what am I missing?”).
• Spent the first month “setting up their dev environment” rather than shipping a small first PR in week one.

The pattern was almost binary. I could usually tell by week three who would ship.

What I do differently as a mentor

Over seven cycles, my mentoring style has shifted:

Week 1: Land a tiny PR

Every student’s first task, regardless of project complexity, is to land a 10-line PR that adds a comment or fixes a typo. The goal is not the PR; it’s that they’ve experienced the entire review-and-merge loop within their first week.

Students who can’t land a 10-line PR in week one usually can’t land a 1000-line one in week eight.

Week 2: A small but real feature

Something they can finish in 3-4 days. Something whose acceptance criteria are clear. This builds confidence and tests their estimation skills (a thing that takes 3-4 days for an experienced contributor often takes a student 2 weeks; the estimation calibration starts here).

Weeks 3-10: The main project

Broken into 2-week chunks with clear deliverables. Each chunk ends with a working state — not “implementation in progress.” This means designing for incremental milestones from the start.

Week 11: Documentation

The student writes docs for what they shipped. Not at the end as an afterthought — explicitly as a phase. The docs are usually better than the docs the maintainers would have written because the student remembers what was confusing.

Week 12: Handoff

The student writes a “next steps” doc covering what’s done, what isn’t, and what they’d do next. This makes the work durable; the maintainers can pick up where the student left off without spelunking.

The communication scaffolding

The single biggest improvement to my mentoring was setting up explicit communication scaffolding:

• Weekly written check-in. 200-word email from the student every Friday: what I did, what I’m stuck on, what I’ll do next week. Forces reflection; gives me a paper trail.
• Asynchronous-first. Slack / email rather than synchronous calls. Students from different time zones get equivalent access.
• Office hours. One 30-minute video call per week, opt-in. Some students never used them; some used them every week. The pattern usually matched the student’s pace.

The students who shipped used the scaffolding consistently. The students who didn’t ship either skipped check-ins or sent them as one-line “going well” messages that revealed nothing.

What I cannot do

There are limits to what mentoring can fix:

• I cannot make a student work consistently. If they’re juggling GSoC with university exams or a part-time job and they can’t manage the time, the work suffers.

• I cannot teach motivation. Some students arrive intrinsically curious about the project; others arrive treating it as a resumé line. The first kind ships; the second kind usually doesn’t.

• I cannot patch over a wrong project fit. If the student’s background and the project’s needs don’t match, three months isn’t enough to close the gap. Better to redirect early than fight through.

The hardest part of mentoring is recognising these limits and adjusting — sometimes the right call is to scope down the project; sometimes it’s to fail the student at midterm rather than push to the end.

What students get out of GSoC

Beyond the stipend and the resumé line:

1. A real open-source contribution graph. The PRs they merged are visible to every future recruiter who looks. A visible contribution to a real project beats most internal project descriptions.

2. Code review by experienced engineers. For most students, GSoC is the first time their code is reviewed at the level they’ll experience in industry. The feedback loop matters.

3. An OSS community. They’re now known to the project’s maintainers. Future opportunities — internships, full-time roles, ongoing contributions — come from these connections more often than from cold applications.

4. A piece of work they can talk about in interviews. A real, shipped, public contribution that they can show, walk through, and explain trade-offs about. This is rare for early-career engineers and disproportionately valuable.

What I get out of mentoring

Seven cycles in, the benefits to me:

• Pattern recognition for early-career talent. I can now pretty accurately predict in weeks 1-3 whether a student will ship. That recognition transfers to hiring and team-building contexts.
• Improvement in my own code review. Reviewing student code forced me to articulate what I cared about and why. My reviews on professional codebases got better because of it.
• An ongoing connection to early-career engineers. Students who shipped often stay in touch; some have become professional collaborators. The network effect compounds.

The time cost is real — maybe 4-6 hours per week for three months per cycle. The benefit, sustained over seven cycles, has been disproportionate to the cost.

If you’re a senior engineer considering mentoring: do it. Your own engineering improves; you contribute to an ecosystem you benefit from; you build connections that pay back for years. The biggest barrier is usually the imposter feeling that you’re not qualified. Trust me — if you’ve shipped production code, you’re qualified.