Find the list of the current mentors for this year’s cohort on Skylab’s Staff Page > Mentors.
With the extreme level of difficulty in Orbital (Artemis), teams may opt to be guided by a mentor on their project. Mentors are often external guests from industry that represent key companies in industry and local start-ups, but can also come from the School in the form of senior students, including Orbital alumni. Mentors can play many different roles, including giving project ideas, suggesting implementation stacks, introducing mentees to the real-world of industry, networking mentees to other alumni and potential job prospects.
Teams opting for mentorship must complete Orbital. Teams must not drop from the programme partway; this is because mentorship involves the mentor who has sacrificed his/her time to mentor the team. Teams that fail to complete Orbital to the satisfaction of the mentors will not earn certification for Orbital even if they would ordinarily qualify for beginner (Vostok) level certification.
This page details the responsibilities for both mentors as well as mentee teams. Teams and mentors should read both descriptions to be in sync with each others’ expectations.
The Matching Process
For a good relationship to bloom from a mentor partnership, we need mentors and mentees to reach an agreement on the mentorship. Both prospective Orbital mentee teams and prospective mentors fill out their expertise and preferences before the formal start of Orbital in May. For mentee teams, this is done on the registration form, where we collect interest areas (“tags”) about the team members and the project idea. Mentors will also fill out some expertise similarly.
After obtaining preferences from both prospective mentors and mentee teams, on the first day of the Liftoff workshop during the evening, we will have a mentor-mentee matchup session where teams and mentors will have a chance to meet each other and find which teams and mentors seem like a good match. Both sides will then need to express a ranked preference for members of the opposite party. Orbital staff will match up both in the intervening week, with the goal of finalising the mentor-mentee pairing within one week. To ensure your best chance of matching, include all members of the opposite party that you don’t mind being matched to. Because mentorship needs to see agreement in both directions, either prospective mentors and mentee teams may not receive a successful match. The teams and their mentors need to agree on their undertaking formally in email.
The matching session will first see mentors give a short 1 slide introduction about themselves, and then allow the teams and mentors to rotate among each other to allow for a quick, max 5 minute introduction to each other. Where possible, we will try to offer both teams and mentors a shortlist of potential good matches based on the registration form interest areas.
Once the mentor-mentee relationship is agreed upon, the below commitments are made.
Find the list of the current mentors for this year’s cohort on Skylab’s Staff Page > Mentors.
Mentorship is the Orbital pathway to link new, talented SoC students to industry. SoC recruits and involves senior students and members of the industry to mentor students as a way to show students the real-world possibilities of their degree and the software engineering pathway.
Mentors are obligated to make themselves available to the mentee teams, via any form of contact that is mutually agreed on by the teams. This can include face-to-face meetings, virtual synchronous meetings (i.e., via Slack, Skype, or other IM) or simply by email. Nominally, the minimal time for mentorship is one hour a week. However, mentors are encouraged to interact more with the student teams if they would like.
Mentors should provide guidance to the team in the form of pointers or advice on what technology stacks, libraries or projects are suitable for the team’s skill level. Mentors can also given larger-context advice and stories to mentees, including sharing their experiences with business development, differences between start-up and corporate workplaces, expectations in different development roles, and lessons in management and communication. Mentors can strengthen the notions of key software engineering practices and patterns to students such as testing, specification, documentation, source code control and general team communication, but also workflow and agile concepts; students in Orbital typically have not been trained or taught software engineering prior to Orbital. Mentors will be given access to the project’s deliverables through their accounts on Skylab, Orbital’s administration platform.
Mentors are allowed to influence the project idea, scope, and execution — ideally, they should be vested parties in the idea of the project itself and be passionate about the team’s idea. In certain circumstances, the mentor may propose projects to prospective teams who don’t have a project idea of their own, but these should be suggested with care. We find that teams feel most driven if the team members have created something entirely for themselves. The teams are the center of attention in Orbital.
Mentors should not be answering detailed, technical questions about projects. Orbital is a self-directed independent project, and as such, student teams need to display initiative to investigate and solve these difficulties on their own.
Mentors are reminded that mentee teams are not interns. Interns are paid staff, working in a particular job scope, while Orbital teams are working on their own summer projects at the speed and pace that they feel comfortable with. Mentors should not obligate students to perform tasks that are beyond the scope of the project directly. It is expected that mentors and mentees form a good working relationship that may transcend the Orbital project, but for the purposes of Orbital, mentorship should only involve advice and direction directly affecting the team’s project and its evaluation. Good mentorship is its own reward, but we find that good mentors are appreciated by their teams and end up contributing back to mentors indirectly eventually. We realise that some mentors come on board the mentorship programme to get to know good students in our school to eventually recruit; we feel this is quite possible and encourage it — however, mentors need to convince students that staying and working for them (perhaps as part of SoC’s various internship programmes) is worthwhile compared to their other opportunities.
Mentors are not formally evaluated, but mentors who are evaluated by their teams as not performing their meeting and advisement duties will be reconsidered for invitation in the next Orbital iteration. Mentors may attempt to mentor more than one team at a time, and may choose to meet with multiple mentee teams in one meeting.
Mentors looking to contribute to Orbital more can consider tutoring, where mentors assist to teach students in either the Liftoff (300+ students, mandatory recorded introductory lessons) workshop, or in one of the five Mission Control sessions (10-40 students, optional recorded workshops, covering alternative technologies and intermediate topics). Contact our staff for details. Such lecturing vehicles may also give you a chance to market your company/idea or other call to actions among the Orbital student body.
The Orbital Experience
Mentors should be familiar with the Orbital’s programme and its workflow. The summer project is driven solely by the students team’s own efforts to complete their project. Orbital basically scaffolds the project with three milestones, roughly one month each, with a corresponding peer-reviewed milestone at the end of the month. The first milestone (early June) is for ideation, in forming the project scope. The second milestone (early July) is for prototyping, and hopefully finalising the technology stack used to implement the project core. The final milestone (late July) is for refinement, extension and testing, where students rush to finish most of the project. Teams need to create short videos for each milestone and share it with their peer reviewers through Skylab. The final project presentation to you and their peers will come during the Splashdown closing ceremony (late August).
It also helps to understand the level of coding experience that students have when attempting Orbital. Orbital is typically a 1st year School of Computing programme for their first summer, when most students do not yet have enough exposure to capture a desirable internship; successful self-initiated projects in Orbital serve to “level up” student’s résumés for subsequent summers. Many students have little programming background; and may have only taken a introduction to programming methodology course as their sole programming experience: many may have not written programs longer than 30-50 lines, that just mean to test basic algorithmic concepts.
They may have little exposure to library use, coding via web examples, with version control, IDEs and with the general alphabet soup of acronyms and buzzwords that characterises the real-world development landscape. Expect them to take a lot of time to work on their own to brush up on simple concepts, but mandate that they keep you abreast of their projects. Keep these characteristics in mind when helping teams scope their project. We recommend that students complete a as-basic-as-possible proof-of-concept first: it’s easy to always extend a project, but hard to complete an overblown project.
The overall timeline for mentoring is thus:
- Preparing a single ppt or pdf slide detailing your mentorship profile (Samples on Slack; please do join the Orbital staff Slack team to keep in the loop of relevant discussions). These will be orally presented in #2, limited to 3 minutes, to ensure that the session does not run too long.
- Attending the matching session in person if possible. Please do let us know if you cannot come; this will impact how likely a team will take up your mentorship.
- Expressing interest in which teams that you’d might like to mentor within the week of the session.
- If assigned a team, correspond with them and set regular meeting times.
- Mentor them through the three milestones of ideation, prototyping and extension. Monitoring their deliverables in Skylab as needed.
- Attending Splashdown in August to see your team’s final performance.
By agreeing to be mentored, mentee teams are making a serious commitment to try to complete one of Orbital’s advanced certification. Mentors will normally be giving advice about the overall strategy for the project, especially technical advice about pointers to technologies or general troubleshooting (however, detailed technical bug fixing problems are generally the responsibility of the student groups themselves), but may also give advice on other non-technical (soft skills) advice such as giving feedback, project presentation and report writing. Mentors complement the role of student Advisors (volunteer Orbital alumni) who work as giving “official” project feedback to student teams. Do note, however, that mentors are not screened by Orbital staff, and that mentors are accepted into the mentorship programme for volunteering.
Mentees have the responsibility of continually updating and meeting with their mentors on a regular basis about their project progress, meeting with the mentor in the manner and time/date of convenience to the mentor. It is highly advised the student teams give their mentors an update every week, on a set day of the week, unless otherwise previously negotiated. Where possible, a face-to-face meeting should be done at least for the first and last meet ups.
Mentors will be associated with the team in Skylab, and will be able to view the project milestones and submissions. Mentors that feel that their mentee teams are not contributing enough towards meeting their intermediate or advanced certification may feed back to the Orbital staff for close monitoring.
Mentees should drive the meetings with their mentors and request what they need from the mentors. Sample requests could include asking mentors to suggest a technology stack, to suggest how to revise the project scope, to suggest features or technology to implement a feature, to help with testing and recruiting testers, and to review specific parts of the documentation for the project (not code-level review, but project README, log, Splashdown poster, oral pitches, and videos for the project).