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.
  • Read your week’s workshops and solutions, as well as the project and 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.
  • Decide who will lead which bits of your week - Refer to the day by day checklist below for a detailed breakdown of your responsibilities.
  • Have a look at the cohort’s most recent projects, and ask the course facilitator about any relevant feedback from the previous week’s SGC.
  • Read their cohort expectations at GitHub > fac# > cohort > expectations.md.
  • 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.

Timings

You are ultimately responsible for timings, which will be up to date in the course schedule before your week.

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 or extending a session, since each part is important for different reasons.

For any remote days: As Zoom host, you can broadcast messages (e.g. “Rooms closing in 60 seconds”), and close rooms - which starts the 60 second timer.

Breaks

Make sure the cohort is getting regular breaks, from their screens and chairs. In between longer activities, suggest 3-5 minutes to 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 vary slightly.

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

Monday

Workshop Discussions

The cohort will have completed the workshops independently on the previous Friday. Discussion on Monday happens in two stages - in small groups of 3 for 80 minutes, and then a larger group facilitated by mentors for 40 minutes. Talk through their solutions, and facilitate discussion - prompt the learners to explain what they did!

Morning Challenge

Introduce the Morning Challenge - share your screen and give a brief description of the exercise.

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.

Projects

  • Introduce the Project and Spike - share your screen and give a brief description of the exercise

Tuesday & Wednesday

Projects

  • On remote days, create two breakout rooms per project to allow learners to split up into pairs.
  • Be available on Discord, Tuesdays and Wednesdays are usually more unstructured but the cohort will need help with their project work.

Role circles (from week 2)

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

Code Review

  • Please code review the cohort’s projects and raise issues from 16:45 to 17:45 on Wednesdays.
  • 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

Thursday

  • You aren’t expected to be available on Thursdays, but feel free to attend project presentations if you’re free!

Friday

  • You aren’t expected to be available on Fridays. The cohort will be working independently on the following week’s workshops.

Feedback form

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