Mentoring guidance

A guide to leading and supporting peer learning using our coursebook

This is a live document that mentors are encouraged to feedback on.

Please read these notes and check with the course facilitator before your week starts with any clarifications, questions and/or thoughts.

To do before your week

  • Make sure you’re an owner of the cohort’s GitHub organisation.
  • Decide who will lead which bits of your week - Refer to the day by day checklist below for a detailed breakdown of your responsibilities.
  • Read your week’s workshops and solutions, as well as learning objectives. These may have changed after your cohort!
  • Check in with the course facilitator. They are there to support you before, during and after your week.
  • Have a look at the cohort’s most recent projects, and read their most recent SGC in GitHub > fac# > cohort > retrospective >
  • Read their cohort expectations at GitHub > fac# > cohort >
  • Read the cohort’s user manuals - find these as issues raised on the GitHub > fac#> user-manuals.

Being a good mentor

  • This is their classroom (Zoom, their Slack channel, Space4). Please be respectful of their space and time.
  • Making offhand announcements like “it’s going to get a lot tougher” or “this will be super easy in a few weeks” builds unnecessary expectations based on your own experience. Do your best to frame it as your experience, and only when asked directly about it.
  • Avoid saying “you’ll learn that later” or “this will be useless once you learn x”. And avoid offering negative opinions about any material covered during your week - your job is to present the curriculum and allow them to come to their own conclusions.
  • When someone brings you a problem, ask questions before giving an answer. It’s better if you can empower them to find that answer within themselves rather than giving it to them.
    • Consider asking them to take a step back and explain why they are trying to do a certain thing (rather than how). This will ensure they’re focussing on the problem and not their solution.
    • Have you asked the other members of your team?
    • Have you asked anyone from other teams? [If you know a team that has worked through the same problem, point them to that team]
    • What did you google for?
  • Respond positively to questions. Asking questions is scary, so help people to feel comfortable and try to encourage that behaviour.
  • They should always be in control of the keyboard and mouse (don’t type for them). Very occassionally, you might need to write something (e.g. pseudo code). Avoid temptation by using a notepad / Zoom chat.
  • Draw things out! Keep a notepad and pen with you and prepare yourself to draw out the problems/solutions to visually aid your explanations.
  • If you don’t know the answer that is completely okay! Be honest about not knowing. The best thing to do is find out the answer with the other person. Google it and then you can both learn something new. Ideally this also signals to the person you are mentoring that it is okay not to know something.
  • Help break big problems down into small ones, especially if they seem like they’re feeling overwhelmed. They need to be shown they can figure it out on their own, you are just there to guide them. Write down the steps & encourage them just to focus on one step at a time.
  • Let them stumble. We learn by making mistakes, getting frustrated, and working through a problem in our own way. Be supportive, and encourage them to explore.
  • Don’t say no when you think they are not doing something right - and be open to the fact that their way could also be right. Be gentle, approach it in a thoughtful way. You can try asking them to explain the steps that they’re taking. If you give them the answer, you’re taking away an opportunity for them to learn.
  • Work collaboratively with the cohort. If you have two or more people, you should work with all of them. Don’t focus all your attention on one of them. Encourage those who have figured it out first to then show this to the others.

Note: People may be frustrated with you, especially at the beginning of the course, because they may assume you are here as a teacher that can always provide answers. You can clarify that your role as mentor is to work through problems together.


You are ultimately responsible for timings, which will be up to date in the course schedule before your week. As Zoom host, you can broadcast messages (e.g. “Rooms closing in 60 seconds”), and close rooms - which starts the 60 second timer. The clearer and sharper you are with timings, the happier everyone will be. Please try not to compromise timings during the week, e.g. shortening SGCs, since each part is important for different reasons.


Make sure the cohort is getting regular breaks, from their screens and chairs. When you come back together after a workshop, suggest 3-5 minutes to turn off their video, stretch, go for a walk, get water, etc.

Day by Day Checklist

This is a generalised checklist that is applicable for each week.

Some weeks may have an extra project day on tuesday - treat this the same as wednesday and thursday.

Please reach out to the CF if you have any specific questions about your week.



  • Check if you are on the rota, you can find this on the cohort’s#sst channel or the github organisation under cohort/
  • Remind the CF to make you co-host if they have not already.


  • Create breakout rooms(if the CF is unavailable).

  • Set these to “allow participants to choose room”. Pairs can be found in cohort/pairs-and-teams/

  • Keep an eye on #help-and-solutions in the Discord! Discord allows per channel notifications so you can mute the rest of the server while allowing notifications from this channel.

  • Keep any communication with the CF/other mentors public if possible - in the #mentors channel.

  • Notify learners on Discord or by broadcast before entering breakout rooms to avoid disrupting their focus or unexpected surprises!

  • Remind the cohort to come back 20 mins before the scheduled end of the workshop, to discuss solutions.

  • Close breakout rooms for discussion time.

  • Facilitate discussion - pick someone to share their screen using the name picker.

  • Make sure to pick someone new for different sections of the workshop.

  • Do your best to get one person from each pair to contribute something.

  • Make time on Thursday to go back through each workshop and raise issues (or pull requests!) from your first hand feedback.

Lunch - make sure everyone stops at 13:00 and is back at 14:00!

Tech Spikes

  • Share your screen and talk through the project and tech spikes for the week.
  • Create 1 breakout room for each project team, and an additional breakout room for each spike topic.
  • Instruct the cohort to first go into their project teams, then pick a spike topic each. Everyone who picked the same spike topic then moves into the breakout room for that topic.
  • Remind the cohort to begin preparing spike presentations at 17:15.


Spike Presentations

  • The CF usually facilitates these, but be prepared to facilitate if needed.
  • Allow 12 mins each : 8 for presenting and 4 for questions.
  • Think up some questions in case no one has any. Prioritise questions from people who may not always ask questions, your CF can help with this in preparation for your week.

Workshops - same as above

Tech for Better

  • Gregor and the CF will facilitate these sessions.
  • Feel free to ask questions to the Product Owners drawing from your TFB experience. Remember that we’ll prioritise the cohort’s questions.

Wednesday & Thursday


  • Create two breakout rooms per project to allow learners to split up into pairs.
  • Be available on Discord, wednesdays and thursdays are usually more unstructured but the cohort will need help with their project work.

Role circles (from week 2)

  • Make a breakout room for each role (QA, UX, Scrum, Devops).
  • Bring the cohort back and recreate project breakout rooms once done.


Code Review

  • Pick one project to code review and raise issues from 10:00 to 10:45.
  • Be complimentary, keep it focused around the acceptance criteria and learning objectives for the week, of course highlighting improved ways of writing code, especially concerning topics covered in previous weeks.
  • Ideally keep it brief and where appropriate link to resources (MDN, W3, etc).
  • You will review two weeks: your week and the week after.
  • For more info, refer to our code review guidance

Project Presentations

  • The CF may be available to facilitate these, but be prepared to facilitate if needed. Keep an eye on timings.
  • These will be 12 minutes each and no more than 18 minutes total incl questions.
  • All that being said, allow extra time for technical difficulties.


  • Feedback from mentors can be very useful for the cohort and FAC staff during SGC.
  • You may find it helpful to keep a personal record of things to bring up at SGC throughout the week, as thinking of SGC points on the spot can be challenging.
  • You may be asked to facilitate or take notes for SGC if you are mentoring one of the earlier weeks. Members of the cohort will be facilitating/note taking in later weeks however.

Feedback form

  • The CF will send you a feedback form at the end of the week, please do fill this in!