# Recruitment Overview

This document provides a overview of why and how we do recruitment at UBC Launch Pad.

# Goals

We have an application and interview process to join Launch Pad because software engineering is inherently a collaborative process — one that requires every contributor to work well with each other. We want to make sure that every member is commited and has the support required to do so, regardless of what their skill level is. For the most part, this support comes from our leads, who also have to put in a great deal of effort to manage teams, plan projects, provide technical guidance, organize events, liaison with sponsors, and more. Given the small number of people at Launch Pad who have the background, time, and willingness to do all this, we sadly can’t accept and adequately support everyone who applies.

That said, a major goal of Launch Pad is to support beginners and people from a wide range of backgrounds. We want to continue to iterate on our process (for example, our questions and criteria) to make sure that Launch Pad membership is as diverse and inclusive as possible.

# Technical Roles

When recruiting for techncial roles, we aim to categorize applicants into the following categories:

Beginner: 1st or 2nd year student OR course project OR simple project (hackathon) OR tutorial project
Independent: Completed 1 internship OR a non-course "advanced project"
- An advanced project meets the following criteria:
  - long-term (for example, at least 1 month between the first to most recent commit)
  - is non-trivial and the product of tangible effort (up to judgement)
  - demonstrable use programming paradigms (even as simple as loops)
Experienced: (2 internships OR outstanding project) AND nails technical question AND interest in mentorship

To provide support to our less experienced members and ensure a productive environment for everyone, when recruiting we aim to have:

around 40% of members be "beginners".
at least 20% of members (including leads) be "experienced".

Each lead typically leads 1 team. We aim for a club size of 8 developers (excluding the lead) per team, to accomodate for members potentially leaving throughout the semester.

# Design Roles

When recruiting for design roles, it is important to note that most teams will consist of only 1 designer, sometimes 2. Because of this, experience levels of designers per team may vary. Our definition experience levels are as follows:

Beginner: 1st or 2nd year student OR student from any major/faculty with interest in UX AND 1 simple case study
Experienced: 1-3 comprehensive case studies OR 1 or more UX design internships AND interest in mentorship

Both of the above experience levels require at least 1 case study or showcase of design work (for example, a PDF or word document).

To provide support to our less experienced members and ensure a productive environment for everyone, when recruiting we aim to have:

around 60% of the design team be "beginners".
at least 40% of design team (including lead) be "experienced".

# Process

Usage of social media should accompany each round of recruitment to encourage people to apply. For example, in the past we've done a "leads feature" campaign (2020), where we introduced each lead in a series of social media posts.

A few things to note:

Make sure to follow the steps for a social media campaign as guidance, especially regarding setting up the Google Drive folder correctly, to make sure we have reference material in the future.
Do not use the word "hiring", as we do not provide pay - "recruitment" is a more accurate and less intimidating term.

# Applications

All materials pertaining to accepting applications (Google Forms, spreadsheets, and so on) should be tracked in the Recruitment folder (under Leads).

# Accepting applications

Applications are generally accepted through Google Form submissions.

Create a folder under Recruitment for the recruitment season (for example, YYYY MM).
Make a copy of the template forms provided in the Recruitment folder and make the appropriate adjustments relevant to the recruitment season.
Enable responses under the "Responses" tab of the form.
Make the appropriate website updates:
1. docs.ubclaunchpad.com: make sure our role description pages are up to date, with links to the relevant Google Forms at the bottom of each page.
2. ubclaunchpad.com: configure recruitment status.

# Closing applications

Disable responses under the "Responses" tab of the form.
Make the appropriate website updates:
1. docs.ubclaunchpad.com: remove links to application Google Forms from the role description pages
2. ubclaunchpad.com: configure recruitment status.

# Screening applicants

To screen applications, we provide a set of criteria, each to be graded on a 0-2 scale from "unsatisfactory" to "excellent" relative to the applicant's skill level so that we can try to achieve the experience distributions described in our recruitment goals. These scores are used to determine the candidates to interview.

For most of our entry roles (developers, designers, and strategy), we have the following criteria:

C1: Willingness to learn (self-drive, taking time outside of classes and work to learn and build things)
C2: Passion and interest (for example, comprehensiveness of answer to "tell us about a project", even if not technically comprehensive)
C3: Rate the best of the provided items from the OR/AND's from the relevant skill bucket they fall in

Once applicants have been screened, decide on a score threshold for each skill level and send out interview offers and decision updates to candidates. See emails (in Leads) for email templates, and please remember our feedback policy.

# Interviews

Our interview processes are documented in the private Leads repository. This includes guides, questions, scoring criteria, email templates, and more.

Members of Launch Pad who are not leads may be temporarily granted access to the Leads repository so that they can access our interview documentation.

Once applicants have been interviewed, decide on a score threshold for each skill level and send out offers and decision updates to candidates. See emails (in Leads) for email templates, and please remember our feedback policy.

# Feedback

Unfortunately, we do not provide feedback regarding a decision for either the screening or interview phase of a candidate's application process. This means we can not provide specific answers to questions like:

"Why did I get rejected?"
"How could I have answered X question better?"
"Should I have brought up Y, Z in response to X question?"
"Who graded me?"

However, feel free to provide more general advice to candidates that reach out, such as resume pointers or things the candidate can do to round out their skills.