Alumni — Mentoring (as Mentor)#

The Mentorship surface lets alumni offer their time to current students and early-career alumni through programme-driven matching. This guide covers the mentor side of the lifecycle.

Who this is for: alumni who want to mentor through a Bits-run programme. If you are a student looking for a mentor, see mentorship-as-mentee.md under the student role guide.

Where to find it#

  • Browse open programmes: /app/mentorship.
  • Apply as mentor: /app/mentorship/programmes/<id>/apply-mentor.
  • Your matches: /app/mentorship/matches.
  • A specific match: /app/mentorship/matches/<id>.

How matching works (in one paragraph)#

A mentorship programme is a time-boxed cohort. Admins open a programme; mentors and mentees apply during the open window. When the admin runs matching, the engine produces deterministic mentor↔mentee proposals scored by a transparent weighted formula: 2*skills_overlap + 1*audience_fit + 0.5*capacity_remaining. You as the mentor accept or decline first; only after you accept does the mentee see the match. Once both sides accept, the match enters the active state and you can schedule sessions.

Source: backend/internal/mentorship/matcher.go, backend/internal/mentorship/service.go.

Applying#

  1. /app/mentorship lists open programmes you’re eligible for. Eligibility is computed against the programme’s audience_scope JSON (e.g. batch_year_min: 2018, departments: ["CS"]).
  2. Click Apply as mentor on the programme of interest.
  3. Fill the form:
    • Expertise tags — pick from the global Skill catalogue. The matcher uses these directly.
    • Availability hours/month — informational; not used by the matcher today.
    • Bio (short) — ≤ 500 chars. This is what mentees see on the match card.
    • Max mentees — caps how many mentees you can hold. Defaults to the programme’s mentor_capacity_default.
  4. Submit. Your MentorProfile.state is set to applied. Some programmes auto-approve; most require an admin to flip you to approved — see documentation/handbooks/mentorship-operations-guide.md for the operational side.

Accepting (or declining) a match#

When the admin runs matching, you receive a mentorship.match.proposed notification per proposed match. Open /app/mentorship/matches to see them.

Each match shows:

  • The mentee’s display name + a short bio.
  • The match score and a reasons payload (which skills overlapped, which audience axis matched).
  • Two CTAs: Accept and Decline.

State machine (from backend/internal/mentorship/types.go):

proposed → accepted_by_mentor → accepted   (mentee then accepts)
         → declined                         (terminal)

Once you accept, the match flips to accepted_by_mentor and the mentee gets prompted. If the mentee declines, the match returns to declined and you do not get a second pairing automatically — the admin must re-run matching for that programme.

You can decline a proposed match without giving a reason. You cannot un-decline.

Scheduling sessions#

Once a match is accepted (both sides):

  1. Open /app/mentorship/matches/<id>.
  2. Schedule session opens a form: scheduled date/time, duration, modality (in_person | video | chat), notes-visible-to (both | mentor | admin).
  3. Submit. A Session row is created with state scheduled. The mentee gets a notification.

Reminders are sent automatically 24 h and 1 h before the scheduled time (backend/internal/mentorship/reminders.go).

After the session, update the state on the same match page:

  • Completed — happy path. Add an optional progress note (visibility honours the choice you made when scheduling).
  • No-show — mentee did not attend. Recorded for the admin dashboard.
  • Cancelled — either side cancelled; record a brief reason.

Terminating a match#

If the mentoring relationship is no longer working, terminate the match: open the match page → Terminate match → record an optional reason (≤ 200 chars, terminated_reason). The mentee is notified. Both you and the mentee become eligible to be re-matched in the next matching run.

Common issues#

  • “My match dropped before I accepted” — admins can re-run matching while a match is still proposed. The previous proposal is overwritten. This is by design but rare.
  • “I want a longer bio” — bio_short is hard-capped at 500. The product decision was deliberate: longer bios cause selection friction. Use a personal site link if you need more.
  • “The reasons say audience_fit: 0” — the matcher could not find a clear cohort axis between you and the mentee (e.g. neither shared department nor batch decade). The match still went through because the skills overlap was strong enough.
  • “I want to mentor outside a programme” — not supported. All mentoring goes through programmes so admins have a tracking surface.
Backward Students — Mentorship (as Mentee) Students — Groups & Search Forward