Requisitions and Vacancies

1. You are here:
2. Hiring
3. Requisitions and Vacancies

Maintained by:

K

On this page

• Introduction
• Definitions
  • Vacancy structure
• Specialist versus expert
  • Title
  • Headline
  • Add a Video
• Sourcing Support
• Closing a Requisition

Introduction

Definitions

Job families and vacancies are different things and can't be used interchangeably. Hopefully this information will help to clarify the differences.

• A job family is a permanent item; its content is a superset of all vacancies for the job family, and it is created with a merge request. Since it is permanent please don't include text that becomes outdated when we hire someone, for example: "We are seeking".
• A vacancy is a temporary item posted on Greenhouse; its content is a subset of the job family, and it is created by copying parts of a job family based on an issue.

The term “requisition” (req) is used when referring to an open job. The term “vacancy” is used when referring to its open position(s). For example, an open req could have two vacancies. To note, our Applicant Tracking System (ATS), Greenhouse, uses the term “openings” as opposed to “vacancies.” Requisitions and vacancies are maintained in Greenhouse based on our Job Families. A requisition and a vacancy are temporary in that they’ll only be open until the position is filled, whereas a Job Family is a permanent description that applies to existing Team Member’s with that title. Please don't use “vacancy” and “Job Family” interchangeably. The relevant parts of a Job Family are copy-pasted to Greenhouse to open a vacancy.

We don't use the word "job" to refer to a job family or vacancy because it is ambiguous.

Vacancy structure

All vacancies will automatically include the following copy as an introduction:

GitLab's DevOps platform empowers 100,000+ organizations to deliver software faster and more efficiently. We are one of the world’s largest all-remote companies with 1,400+ team members and values that guide a culture where people embrace the belief that everyone can contribute.

This paragraph is pre-populated on our vacancies which means we should avoid re-using this language in the body of the vacancy.

Specialist versus expert

People at GitLab can be a specialist on one thing and expert in many:

• A specialization is specific to a job family, each team member can have only one, it defined on the relevant job family page. A specialist uses the compensation benchmark of the job family.
• An expertise is not specific to a job family, each team member can have multiple ones, the expertises a team member has are listed on our team page.

The example below shows how we describe what someone does at GitLab:

1. Level: Senior
1. Job family: Developer
1. Specialist: Gitaly specialist
1. Location: EMEA
1. Expert: Reliability, Durability

We use the following terms to refer to a combination of the above:

Title

Level and job family as listed on the contract, for example: Senior Developer

Headline

All parts except expertise, as listed on vacancies, for example: Senior Developer, Gitaly specialist, EMEA

Please use the same order as in the examples above, a few notes:

• Level comes before job family.
• Specialist comes after job family and always includes 'specialist'.
• Location comes after specialization.

We preface a title with "interim" when we're hiring for the position.

Add a Video

Adding a video to your job family is a great way for people to get to know more about the role, hiring manager, and GitLab. Hiring managers, if there's not already a video created for your job family or role, consider recording one. Check out the job family video issue for guidance or support, or record your own role-specific video.

Examples:

1. Sales Development Representative job family
2. Product Manager job family
3. Senior Product Manager, Manage (Analytics) vacancy
4. All-Remote Integrated Marketing Campaign Manager vacancy
5. Senior Product Manager, Create (Gitaly) vacancy

Learn more about uploading to GitLab Unfiltered within the Communication section of the Handbook. If you're unable to create a video, please add a video about life at GitLab, like this one.

Sourcing Support

Every role at GitLab should receive sourcing support from the Talent Acquisition Team. To learn more about Sourcing you can visit this page and also reach out to your Talent Acquisition & Sourcing partners. For all positions, the Hiring Team will use available tools to source for qualified candidates. In addition, Managers should also reach out to their own network for candidates and referrals. It is common for candidates to respond more frequently to those who they know are the hiring manager. The best Managers take a proactive role in building their teams, through sourcing directly and tapping their networks for excellent candidates.

The Talent Acquisition Team uses various tools to identify talent by proactively reaching out to candidates for opportunities. In addition, they will partner with hiring managers to participate in sourcing to ensure they are targeting the right skillsets.

The Hiring Manager should always ask their team to suggest referrals for open positions. GitLab team-members can refer candidates through our referral program.

Closing a Requisition

1. The Recruiter will clear the pipeline of candidates in all stages of application and notify the candidates that the position has been either filled or closed.

2. Consider rejecting promising candidates with the reason Future Interest and making them a prospect so we can reconsider them in the future.

3. You can also add various tags to the candidates, which makes it easier to find them in Greenhouse later on if you are recruiting for the same or a similar position.

4. You can also set a reminder for a candidate if you anticipate reopening the role at a later date.

5. The Recruiter will close the position in Greenhouse. Please note that upon closing the vacancy this will cancel interviews but not remove them from calendars. It is best to manually delete any inflight interviews before closing the role.