hackathon-mentoring

Hackathon Mentoring

You design the mentor programme for one hackathon edition: how much coverage the field needs, who supplies it, how a stuck team reaches it, what mentors are told before they start, and how coverage rotates across the hacking window.

Read the published brief before designing anything. Two things in it drive every menu below:

• The challenge tracks, which name the expertise that has to be on the floor.
• The sponsor-integration depth, which measures how hard a promise the event has already made.

samber/dev-event-organizer-skills@hackathon-brief-design states the boundary from its own side: it names this skill as the owner of mentor coverage, including for a sponsor's API, and confines itself to stating that mentors exist.

Treat every ranking below as a default, not a law. Re-rank each menu after the interview against what this event already holds: a returning mentor crew, a sponsor whose staff are contractually committed, a hacking space of one room, an organizing team who all know the sponsor's API.

A mentor is not a volunteer, and not a judge

Treat a mentor as its own role, never a volunteer subtype. MLH's documents state the parity outright: its Code of Conduct names "Sponsors, judges, mentors, volunteers, organizers, MLH staff, and anyone else participating in the event" as parallel categories, and its organizer guide gives mentors their own recruitment channel, their own chat channel and their own role marker rather than routing them through a general volunteer sign-up.

That is an identity claim, not a mechanics claim. Borrow the staffing arithmetic rather than rebuilding it. The coverage rule in samber/dev-event-organizer-skills@event-volunteers - "do not leave your post until you have confirmation of a replacement" - applies to a mentor shift unchanged.

samber/dev-event-organizer-skills@event-volunteers owns:

• Bottom-up roster sizing from posts and hours.
• Arrival buffers.
• Sign-up confirmation.
• The no-show and replacement protocol.
• Shift-linked recognition.

This skill owns what that skill has no concept of:

• Expertise tagging.
• Coverage depth by topic.
• The request mechanic.
• The help-versus-build briefing.

Judges are not mentors, and samber/dev-event-organizer-skills@hackathon-judging already says so from its side, in those words: mentors "help teams build during the hacking window", while "judges evaluate finished projects afterwards". The word "briefing" names two different documents across the two skills: a jury briefing there, a mentor briefing here. Write mentor briefing wherever a reader could confuse them.

Mentor conduct policy and enforcement are not yours. Mentors sit inside samber/dev-event-organizer-skills@event-code-of-conduct's existing pipeline like every other named role; do not draft a second one. Yours is narrower and lives inside the mentor briefing: the help-versus-build boundary, and the power dynamic between someone who knows the stack and someone who has been awake for twenty hours.

The mentor-judge conflict, stated from one side

A mentor who materially helped a team, then judges that team, is a conflict samber/dev-event-organizer-skills@hackathon-judging already owns from its own side. It states that "a mentor who helped a team build cannot score that team neutrally" and routes the case into its existing recusal ladder: "apply the recusal rule to every team that person mentored". That skill owns the rule and the recusal mechanics.

This skill owns only the input data: a mentor-team contact log recording which mentor spent meaningful time with which team, available when the judge pool is assembled.

• Keep the log whenever a confirmed mentor is also on the judge list (Q5).
• State the rule declaratively: a mentor who materially helped a team recuses from judging that team.
• Route the mechanics to that skill rather than deriving a competing ladder here.

One half of the handshake is still missing on that side: the recusal rule reaches for "every team that person mentored" without naming where that list comes from. This log is it, and it should be named there when that skill next revises.

Quantities to refuse, and the one published ratio

Never invent quantities for:

• Mentor-to-participant ratios.
• Evidence linking mentor availability to completion or satisfaction.
• Unblock latency targets.
• Mentor-to-shift staffing formulas.

These numbers feel safe to invent precisely because nothing on the day contradicts them. Argue from the mechanism instead: a blocked team with no route to help abandons the build.

One published ratio exists. Joshua Tauberer's hackathon.guide states (under At Themed Hackathons) "ensure that there is at least one subject matter expert + workable project for about every four non-expert participants". Its purpose is project supply, not mentor staffing.

The ratio scopes narrowly:

• Themed hackathons only (one problem domain).
• Counts non-expert participants, not teams.
• Describes domain experts inside projects, not floating mentors.

Use it as evidence that expertise, not headcount, is the scarce quantity. Never convert it into a mentors-per-participant formula.

Interview

Ask one question at a time, multiple-choice where possible. Questions 1-4 and 6-9 exist because the menus turn on them: no default can be picked for the user without those answers.

1. Is the event in person, digital or hybrid; how many rooms does the hacking space occupy; and does the hacking window run through the night?
2. Which challenge tracks does the published brief name, and at what sponsor-integration depth - named funder only, optional bonus challenge, required for one track, or the sponsor's technology as sole substrate?
3. Is the event themed, with organizer-supplied problems, or open, with participants bringing their own?
4. Who is already committed to mentor: community members and alumni, a sponsor's technical staff, or both - and is any sponsor staffing commitment already written into a signed agreement?
5. Is any confirmed mentor also on the judge list?
6. Do prizes carry cash value, and does any sponsor fund one?
7. Have these mentors mentored before, and is this a one-off edition or a recurring event?
8. What is the effort ceiling: organizer hours before the event, whether anyone will coordinate mentors live during the window, and whether a shift grid already exists from the volunteer plan.
9. By what date must the roster close and the request mechanic reach participants? Channels have lead times and the mechanic has to be published before the window opens, so this date constrains both rather than expressing a preference.
10. What already exists that the default ordering assumes away: last edition's mentor list, a university department or user group that would send several people, a sponsor whose staff are already on site for a booth, an organizing team who has built against this API before.

Name which answer moved which rung as you re-rank:

• A close roster date (Q9) promotes community and alumni only, since a warm list answers in days while a sponsor staffing negotiation runs weeks. It demotes the expertise-matched roster, whose tagging and alignment pass are the last work to finish.
• A recurring event (Q7) promotes the boundary-plus-scenario-walkthrough briefing, written once and reused across editions rather than paid for again.
• A low effort ceiling (Q8) demotes the request channel with organizer routing, whose cost is a standing job for the whole window rather than a one-off setup.

Workflow

1. Run the interview, after reading the published brief.
2. Set coverage depth against the tracks, not against a headcount. A sole-substrate sponsor integration raises that track's bar from "a mentor is available" to "a mentor is guaranteed on the floor whenever that track is being worked": the brief's own fallback sentence assumes the platform actually gets support.
3. Pick the recruitment channels and open them with the lead time the roster deadline demands. Load references/coverage-and-recruitment.md.
4. Tag every confirmed mentor with what they actually know, in the brief's own vocabulary: one tag per challenge track, plus the sponsor technology by name. A tag nobody can match to a track does no routing work.
5. Hand the roster to the shift machinery you do not own. Sizing, buffers, confirmation and the replacement protocol belong to samber/dev-event-organizer-skills@event-volunteers. You supply the constraint it schedules against: which expertise must be present in which hours.
6. Choose the request mechanic and publish it in the same place teams read the brief, before the hacking window opens.
7. Brief the mentors. Load references/mentor-briefing-and-request-mechanic.md.
8. Record contacts during the window, meaning which mentor spent meaningful time with which team, whenever a mentor is also judging (Q5). Hand that log to samber/dev-event-organizer-skills@hackathon-judging.
9. Close out. Record which tracks ran short of coverage and at which hours, then hand the mentor list to whoever recruits next edition.

Present the design section by section for validation before the window opens: coverage depth, recruitment channels, expertise tags, request mechanic, briefing. A request mechanic changed mid-event is a mechanic half the field never learns.

If your harness has persistent memory, record the expertise tags against the tracks they covered, which hours ran short, the request mechanic used and how it failed, and the mentors who would come back.

Mentor coverage depth

Four rungs: no mentor programme, on-call from organizers, rostered mentor shifts, and a roster matched to the brief's tracks by expertise.

• value (teams unblocked, the sponsor's technology actually reachable, every track covered): expertise-matched roster > rostered shifts > on-call from organizers > no mentor programme
• effort before the event (recruiting, scheduling, expertise tagging): expertise-matched roster > rostered shifts > on-call from organizers > no mentor programme
• organizer attention consumed during the window: on-call from organizers > no mentor programme > rostered shifts > expertise-matched roster
• efficiency: rostered shifts > expertise-matched roster > on-call from organizers > no mentor programme

Dominance check: clean only by construction, and by-construction is never a pass. Value and pre-event effort are rank-identical, so one mechanism blocks all six pairs, not some of them: whichever rung of a pair is higher on value is strictly higher on pre-event effort too, and fails the test before the third axis is consulted.

The third axis diverges genuinely and still rescues nothing. A pair needs value ≥ and both costs ≤, and the effort half is already lost in every pair. Zero strict-dominance relations exist, the check catches no misordering here, and the efficiency line rests entirely on the arguments below.

Carry the organizer-attention axis anyway, because it is not rank-identical to inverse effort. Inverse pre-event effort would order these no mentor programme > on-call > rostered > expertise-matched; organizer attention orders them on-call > no mentor programme > rostered > expertise-matched. The top two swap, and that swap is the finding: on-call is the second cheapest rung to set up and the single most expensive one to live through.

The same swap is why the cheap rung is not the safe one. On-call looks free because nobody is recruited. What it does is route every technical question to the people also running the schedule, at the hour the schedule is hardest to run.

MLH's guide points the other way, asking volunteers to "stay alert on Discord to look for hackers who need help and push them to the above-mentioned mentorship channel", routing questions away from generic staff toward a named mentor pool.

• Rostered mentor shifts - the default. Recruiting and a shift grid cost a one-off before the event, and the grid is machinery samber/dev-event-organizer-skills@event-volunteers already provides, so the marginal work is a mentor list rather than a scheduling system. It buys the one thing on-call cannot: a named person who is there because that is what they came to do.
• Expertise-matched roster - the starved option: top of value and top of pre-event effort, so efficiency never picks it first. The added work is a tag per mentor and an alignment pass against the track hours. Promotion condition, keyed to Q2 and Q3: the brief commits a sponsor technology at required for one track or deeper, or the event is themed and its problems come from one domain. Below that, general technical coverage is what teams actually consume.
• On-call from organizers - legitimate where the organizing team genuinely holds the field's expertise and is small enough to answer without dropping the run of show. Its cost lands during the window, the moment with no slack in it.
• No mentor programme - a real, rankable rung rather than a strawman: an open-theme event where participants bring their own projects and no sponsor technology is named may need none, and Tauberer's guide describes exactly that shape of event. Delete it, from this menu and from the axis lines above, as soon as the brief names any sponsor technology at required-for-one-track depth or deeper (Q2). At that point the brief has promised support the event has not staffed, and parking the option at the bottom quietly leaves that promise unfunded.

Coverage arithmetic, expertise-tag vocabulary and the escalation path when no mentor covers a needed skill are in references/coverage-and-recruitment.md.

Recruitment source

Four rungs: community members and alumni only, a sponsor's technical staff only, a mixed pool, and a mixed pool plus a written engagement rule telling sponsor staff not to pitch or recruit while mentoring.

• value, expertise coverage across the brief's tracks: mixed pool with a written rule == mixed pool > sponsor staff only > community and alumni only
• value, participant trust that the person helping is not selling: mixed pool with a written rule > community and alumni only > mixed pool > sponsor staff only
• effort (two recruiting channels, negotiating a sponsor commitment, writing the rule): mixed pool with a written rule == mixed pool > sponsor staff only > community and alumni only
• compliance cost, as the review each rung triggers and the reversibility it costs: sponsor staff only > mixed pool > mixed pool with a written rule > community and alumni only
• efficiency: community and alumni only > mixed pool with a written rule > mixed pool > sponsor staff only

Dominance check: clean by care. Exactly one strict-dominance relation exists. The mixe

...