# 🗳️ Recruitment Overview

This document provides a overview of why and how we do recruitment at UBC Launch Pad (opens new window).

# 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 - see improving recruitment.

# Technical Roles

When recruiting for techncial (developer) 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.

You can learn more about technical roles in the Developer role description.

# 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".

You can learn more about design roles in the Designer role description.

# Strategy Roles

TODO(docs#189 (opens new window))

You can learn more about strategy roles in the Strategy role description.

# 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) (opens new window), 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) (opens new window).

# 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 (opens new window): 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 (opens new window): configure recruitment status (opens new window).

# Closing applications

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

# 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) (opens new window) for email templates, and please remember our feedback policy.

# Interviews

Our interview processes are documented in the private Leads repository (opens new window). 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) (opens new window) for email templates, and please remember our feedback policy.

# Frequently asked questions

# Experience

Lack of experience does not necessarily disqualify a candidate. In fact, we actively seek to recruit members from a wide range of experience levels - please see our recruitment goals for more details.

Historically, due to the sheer number of applications that falls in the lower experience levels, we interview a higher percentage of applicants that fall into higher experience levels, so please do not manipulate your application to fall into a lower experience level!

# Referrals

We do not have a referral process at Launch Pad. Members can advocate on a candidate's behalf, which could mean that the candidate's application gets a closer look during screening, but we strive to stick to the criteria and grading we have laid out in our screening criteria and interview guides (opens new window).

# Decisions

All decisions sent out for either the screening or interview are final, unless a mistake was made by reviewers while sending out decisions. Also refer to our feedback policy.

That said, this does not mean that reviewers at Launch Pad never make an incorrect decision - see improving recruitment.

# 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, Launch Pad members should 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 at their description - keep in mind that this feedback does not necessarily reflect how Launch Pad's decisions are made.

# Improving recruitment

To achieve our recruitment goals, we strive to continue iterating on our recruitment processes. This means in every scenario where something like the following happens:

scoring leads to a seemingly suitable candidate being disqualified
wording of a question causes confusion
a candidate, interviewer, or reviewer has a bad experience

We should investigate what went wrong (for example, why was this person scored incorrectly, or what we could do to clarify a question) so that we can look into improving our process and criteria (for example, by improving scoring guidance, or updating our recommended wording for a question).

These improvements should be submitted as pull requests to our recruitment documentation for feedback and discussion - for all steps up until interviews, that would be in ubclaunchpad/docs (opens new window), and for interviews and final decisions that would be in ubclaunchpad/leads (opens new window) (private to Launch Pad leads).

Feel free to bring up feedback regarding recruitment internally in #ask-leads (opens new window) or reach out via team@ubclaunchpad.com.