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.
We don't use the word "job" to refer to a job family or vacancy because it is ambiguous.
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:
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.
Equal Employment Opportunity
Diversity & Inclusion is one of GitLab's core values and
GitLab is dedicated to providing equal employment opportunities (EEO) to all team members
and candidates for employment without regard to race, color, religion, gender,
national origin, age, disability, or genetics. One example of how put this into practice
is through sponsorship of diversity events
GitLab complies with all applicable laws governing nondiscrimination in employment. This policy applies to all terms and conditions of employment, including recruiting, hiring, placement, promotion, termination, layoff, recall, transfer,
leaves of absence, compensation, and training. GitLab expressly prohibits any form of workplace harassment.
Improper interference with the ability of GitLab’s team members to perform their role duties
may result in discipline up to and including discharge. If you have any complaints, concerns,
or suggestions to do better please contact People Business Partner.
Reread the job description multiple times. Read it forward and read it in reverse to catch mistakes. Ask your team to review it. Poorly written job descriptions will not attract candidates.
Check your job description for gender coding, so you can attract diverse candidates.
Consider recording a video describing the role and adding it to the job description.
Optimize job postings
Select the geographic regions via analyzing where the candidates are that have the skills you seek and what the comp ratio is for that region using the trends feature via using features of LinkedIn recruiter. An example for Ruby on Rails developers can be found in this sheet - accessible internally only. If you don't have LinkedIn recruiter access, reach out to your recruiter to find out how to be granted access.
Search in LinkedIn Recruiter to determine if your job is listed correctly and in the geographic regions you want to find candidates (LinkedIn doesn't have a no-location/remote feature). Some candidates may be interested in remote jobs but may only be searching in their geographic region. If you find problems with this, reach out to your recruiter to resolve. To do this in LinkedIn Recruiter:
Do a search for the candidates with the skill(s) you are seeking
Click on "View search insights"
Click on "Location"
If the results are not granular enough for your needs (for examples shows "India" rather than the regions in India), do a search for each country separately.
Don't spend much time on reviewing your job listings on Glassdoor or Indeed. They haven't proven to be effective tools for finding candidates for GitLab.
Promote jobs
Encourage your team and team's stakeholders to promote the jobs via social media posts (LinkedIn, Twitter, etc.).
By generating sharable links from Greenhouse (through the "Share Jobs with your Social Network" option on your dashboard) referrals will be tracked back to the team member who shared them.
Source candidates
Encourage your team and the team's stakeholders to refer candidates. It is recommended that the team member use Greenhouse to refer the candidate (rather than the candidate applying and putting the team member's name in the referrer field). Doing so allows the team member to view/track the candidates interviewing process status.
Do a source-a-thon with your team to help the sourcing team find more candidates.
Optimize the recruiting process
Encourage interviewers to use Calendly with the recruiting scheduler to schedule interviews. Doing so reduces the number of steps the candidate and GitLab needs to do to schedule an interview. Using a paid account is encouraged so that multiple different meeting lengths can be scheduled.
Review all candidates weekly in Greenhouse to confirm that no tasks have been dropped. This can happen due to the number of hand-offs between people and due to the large number of steps to be managed by the recruiting team.
Coordinate with other interviewers to ensure that the interview process covers a range of scenarios and minimizes duplication of questions.
If there is a reasonably high likelihood of a candidate passing the next scheduled interview, ask the coordinator to schedule the next interview after the currently scheduled one. That parallelizes the process and reduces the total time to vet candidates.
Optimize the reference check process
Do reference checks via audio or video rather than email. This tends to provide more useful feedback on candidates. Using a 15 minute Calendly meeting to coordinate this is recommended.
Encourage the candidate to tell their references that they will be hearing from you. This increases the likelihood that they will respond.
In the email to the reference, include the candidate's full name and purpose of the email (to schedule a reference call). This also increases the likelihood that they will respond.
Reference checks should be done by the hiring manager (not the manager's manager) so that the manager is fully invested in the decision.
Optimize the offer approval process
The items below should be verified before the justification is completed as they are among the common reasons for an offer approval to be rejected or delayed.
If the candidate has less management experience for a management role than what we generally expect, be sure to explain why they are still a great fit in the justification.
If the hiring manager did not do the reference checks, explain why in the justification (as the hiring manager should be invested in the decision to hire).
Confirm the candidate meets the longevity requirement.
Confirm that all questions in all Greenhouse interview forms are not left empty. If some are left blank, it may give the reviewer the impression that that the hiring process was not followed.
If any interviews are listed but were not performed, ask the recruiter to delete the interview record.
If the candidate has a side-job (consulting or similar), explain in the justification section how it was determined that this side-job will not interfere with the candidate's responsibilities at GitLab.
Validate that the "nice to have" attributes have been evaluated and that there are >=5 with a yes vote represented in the justification so that this requirement can be confirmed.
Confirm there is at least one "strong yes" vote from someone in engineering.
