Most of the teams I mentor before hackathons are in other cities, so the mentoring happens over calls squeezed between their build sprints. Remote mentoring fails when it is unstructured; it works when the team knows exactly when the mentor appears and what to bring.
Three fixed check-ins
- Scoping call, before the event or in hour one. Twenty minutes. Output: one sentence for the problem, one for the user, one for the demo path, roles written down. I ask the scoping question until the team can answer it.
- Midpoint call. Fifteen minutes of screen-share on the walking skeleton. I look for a real end-to-end path, however ugly, and for anything being built that is not on the demo path.
- Mock pitch, two hours before freeze. The full three minutes with a timer, then Q&A using the questions judges ask, then one strength and one fix.
Rules that make calls useful
- The team shares their screen, not their slides. I want to see the running thing.
- One person talks per topic — the person who built it.
- Questions between calls go in one shared document with context, not as a stream of messages. I answer in batches.
- I do not write code. I point, ask and suggest. The learning stays with the team, and the rules stay intact.
The shared scoping doc
One page: problem, user, demo path, roles, checkpoints, what has been cut. The team updates it; I read it before every call. It is the single most effective tool for remote mentoring because it forces decisions into writing.
For organisers
Remote mentors work well when the schedule publishes their slots and teams can book them. Assign two or three teams per mentor at most. I mentor and judge remotely for student hackathons anywhere in India; write to pranjulrathour41@gmail.com or see the invite page.
— Pranjul Rathour, GenAI Engineer from Kanpur, India. Open to GenAI roles, hackathon judging, mentorship sessions and guest talks at any campus: pranjulrathour41@gmail.com.