A hackathon mentor is not a senior developer who fixes your bug, and not a judge who tells you what to build. Having mentored 200+ students through TechVerse Enclave and coached teams before events, I think of the role as three interventions delivered at the right moments.
Intervention one: the scoping question
In the first hours, the most valuable thing a mentor says is: "What is the one thing you will demo, and can you show me a sketch of that screen?" Teams that cannot answer are about to build a platform. The mentor's job is to help them find the single path and let the rest go.
Intervention two: unblock without building
When a team is stuck at hour ten, the mentor asks questions until the team finds the fix, points to documentation, or suggests a simpler approach. The mentor does not type. A mentor who writes the code has removed the learning and, in most rulebooks, disqualified the team.
Intervention three: the mock pitch
Two hours before freeze, run the pitch with a timer and play the harshest judge in the room. Ask the questions in questions judges ask in hackathon Q&A. Then give one strength and one fix, the same way a good judge would.
How teams should use mentors
- Book a slot early for scoping, not late for debugging.
- Bring a specific question and the code or sketch it is about.
- Ask what a judge would think of the demo path — mentors have usually judged.
- Do not ask which idea is better; ask which one you can finish and demo.
For organisers
Schedule mentors in shifts with a visible board, brief them on the rubric, and separate mentors from judges where you can — a mentor who later judges the same team is in an awkward position. I am glad to take either role at student hackathons; organisers can reach me at pranjulrathour41@gmail.com.
— Pranjul Rathour, GenAI Engineer from Kanpur, India. Open to GenAI roles, hackathon judging, mentorship sessions and guest talks at any campus: pranjulrathour41@gmail.com.