Ops Hiring Process

1. You are here:
2. Engineering
3. Development Department
4. Ops Sub-department
5. Ops Hiring Process

On this page

• Hiring Process
  • Step 1. Identify hiring need
  • Step 2. Kickoff
  • Step 3. Setup job in Greenhouse
  • Step 4. Reviewing Candidates
    • Reviewing your Requisitions
    • Reviewing Evergreen Requisitions
  • Step 5. Sourcing
  • Step 6. Screening
  • Step 7. Continuous check-in
  • Step 8. Schedule interviews
  • Step 9. Perform interviews
  • Step 10. Complete feedback
  • Step 11. References
  • Step 12. Justification

We are running with some limited capacity in the recruiting team and we are asking hiring managers to cover all steps in the hiring process. Please prioritize your time in the following order when spending time on recruiting:

1. References & Justifications
2. Filling in scorecards/feedback
3. Sourcing/Reviewing applications

Hiring Process

The process for Ops is a mix of the current hiring manager (HM) tasks and the talent acquisition (TA) tasks. We use Evergreen Requisitions as a single pipeline for inbound applications to similar roles. In addition, each hiring manager will use a separate Greenhouse requisition for their specific role. The Evergreen Req will be used in conjunction with the team-specific req to track candidates end to end through the hiring process.

Step 1. Identify hiring need

Identify hiring need

1. Work with Product Manager as they are DRI of headcount planning, Finance, and Talent Acquisition to include vacancy in the hiring plan.
2. Create or Review the Job Family

Step 2. Kickoff

1. Create Kickoff
2. Request a GitLab Hiring Plan ID (GHPID) from Director of Engineering, Ops (@sgoldstein)
3. Once the GHPID has been requested the assigned recruiter will create a kickoff issue in the gl-talent-acquisition/req-intake project and mention you on it. Once the kickoff issue is created confirm that:
   1. There is a separate kickoff issue for each req you are hiring (each unique GHPID). For identical roles, one kickoff issue can just be a link to another, but having a separate issue for each req is valuable for tracking purposes.
   2. The kickoff issue has the ~section::ops label applied so we can track in this board (confidential) and use it as the single source of truth (SSOT)
   3. If you have not received a kickoff issue within 3 business days of requesting the GHPID escalate this by mentioning @sgoldstein in the #doe-ops slack channel.
4. Complete Kickoff
5. Add the new vacancy to the handbook https://gitlab.com/gitlab-com/www-gitlab-com/-/tree/master/data/team_members/vacancy

Step 3. Setup job in Greenhouse

1. Work with TA to open the vacancy in Greenhouse
2. Setup scoreboard
3. Publish job ad internally. External job ads will be posted from the corresponding Evergreen requisition.
   1. [Optional] Add additional questions to the application, such as number of years of Rails experience, or qualities relevant to your role
4. Add your own manager as a hiring manager in the req
   1. Job Setup (tab) > Hiring Team (left nav)
   2. Click Edit under Hiring Managers and add your manager
      1. If your manager's name doesn't show up, it's likely that they don't have any permissions to view this role currently.
      2. Scroll down to the section Who can see this job? and grant your manager Job Admin: Hiring Manager permissions
      3. Return to the previous step, and now you can edit the list of Hiring Managers and add them
5. Ensure you have hiring manager access to the Evergreen Requisition for your role

Step 4. Reviewing Candidates

Reviewing your Requisitions

1. Review applications in the requisition you are the hiring manager for.
2. If you are interested in a candidate, move them into the Qualified stage, where the TA will also review prior to setting up a screen.
   1. :warning: TA is trialing Greenhouse automation with some requisitions where candidates automatically receive an email to book a screen with them when they're moved into Screening. Please confirm with TA whether this automation is set up for your role.

Reviewing Evergreen Requisitions

1. Review applications in the applicable Evergreen requisition
2. If you are interested in a candidate, move them into the Qualified stage and tag your TA to request a screening (see Step 6)
   1. Note: Candidates will stay in the Evergreen requisition until they have completed screening and technical interviews, at which point they will be transferred to team-specific requisitions.
3. Do not reject applications in the Evergreen requisition unless the applicant's location is a country where hiring is restricted

Step 5. Sourcing

In addition to reviewing candidates in the Evergreen req, you may also wish to do sourcing for your team-specific role. The main purpose of sourcing is to Identify and engage top talent.

1. Get a recruiter LinkedIn account and setup
2. Setup LinkedIn for sourcing, for example:
   1. Create your own templates
   2. Create projects for each of your open positions or make sure you are invited to
3. Search for candidates
   1. If you are getting support from a sourcer, follow the steps to review inbound applications
4. Reach Out. Consider using the templates listed in the resources. Make sure to ask for contact details of the prospect, you will need this in the next step.
5. Add prospects to your team-specific requisition in Greenhouse. In the prospect's profile, click in the three dots, and click on export to ATS.
6. After importing to Greenhouse, edit the profile (under Details tab, there is an edit button) to include the email and any other contact information. This is important because Greenhouse automatically sends an email to the candidate when is moved from prospect to candidate to fill a form which includes the CV to be uploaded there.

Resources:

• Mark Deubel's podcast: Foundtaions - Sourcing Outreach and Guest Show - Sourcing outreach
• Talent Acquisition Reach out templates (private)
• Ops reach out templates (private)
• Sourcing
• LinkedIn training (private)
• LinkedIn boolean search (private)
• Diversity Boolean strings (private)
• Single Search Permutator (private)
• Video training for diversity sourcing (private)

Step 6. Screening

To speed up scheduling screening calls, integrate Calendly with Greenhouse following these instructions. To then use this integration, move the candidate to the 'Screening' stage and select "Schedule with Calendly". There will be a template that will automatically populate and you select your Calendly event in the drop down.

1. Schedule screening calls (3-6 per week)
2. Tag TA on the candidates Greenhouse profile so they can support with screening calls. and work with TA in case they have capacity to do the screening
3. Screening. Don't forget to introduce the TA to the prospect at the start of the team interview stage so they can build a relationship with the candidate and ensure a consistent experience.

Step 7. Continuous check-in

Continuous check-in

Step 8. Schedule interviews

You have two options to Schedule interviews. You can either:

1. Tag TA on the candidates profile and they will organize everything
2. Start the process yourself. To do this:
   1. Move the candidate to the Team Interview stage
   2. Select Request Availability and search for either the "Ruby" or "Golang" technical interview template. This is important as it has specific instructions
   3. Then select Email the Team, choose the CES Scheduling Request Form
   4. In the template, add - 'Technical Interview - Ruby or Go, Ruby or Go interviewers, 90 minutes' under details
   5. x the Confirmed box to confirm you've requested their availability
   6. Send the template and tag TA on the candidates profile to introduce themselves to the candidate

Step 9. Perform interviews

Step 10. Complete feedback

Complete feedback. Ideally the feedback is submitted within 1-2 business days of the interview. If you're unable to submit it within that timeframe, please reach out to the Hiring Manager and/or Recruiter with any early evaluation and when they can expect your feedback by.

Note: There are times when candidates who may not be a good fit in one role could be an ideal fit in another role. In those cases, please note that to the recruiter or share in Slack (i.e. #ops-hiring, #dev-hiring-mgmt, etc.) as it may be helpful for other hiring managers to be aware of to evaluate these candidates.

Step 11. References

1. Request references
2. Complete references

Step 12. Justification

1. Hiring Manager to complete Justification scorecard.
2. Justification scorecard will be reviewed by Director of Ops (or a delegate) for these criteria (see Engineering Hiring Process README for additional detail):
   1. :star: Two "Strong Yes" scorecard ratings minimum.
   2. All must-haves assessed and positive. These should be checked in the Justification scorecard. The ratings should reflect the hiring manager's evaluation of the candidate based on all feedback. They are not an average of scores given by the interview panel.
   3. Majority (e.g. 5 out of 8) of nice-to-haves assessed and positive in Justification. These should be checked in the Justification scorecard. The ratings should reflect the hiring manager's evaluation of the candidate based on all feedback. They are not an average of scores given by the interview panel.
   4. :thumbsdown: Negative scorecards (No, Definitely Not) from interviewers should be explicitly addressed with a brief comment in the Justification.
   5. :x: Any previous GitLab job application rejections must be explicitly addressed in Justification. (Confirm with TA)
   6. :triangular_flag_on_post: Any red flag must be explicitly addressed in Justification.
      1. :page_with_curl: Each flag should have a corresponding item in the "How do we intend on setting this candidate up for success?" section to explain how the Hiring Manager plans to mitigate the flag.

Example justification structure with expected criteria -->

In what specific way(s) does this candidate make the team better? * - Describe each must have category for the role with a summary of how the candidate is a good fit. What flags were raised during the interview process? * - If the candidate was previously rejected, determine the reason they were rejected and describe why and how they are a good fit for the current role. Your recruiter, Senior EM, or Director can help you determine the reason they were previously reject (you may not have access to the other roles in Greenhouse). In cases where they were rejected by another hiring manager who is still employed at GitLab it is good to follow up with that HM to get their input. Include that information in the discussion of why they are a good fit for the current role. - If the candidate had a Thumbs-down scorecard, explain why and elaborate on the reason you, as the HM are still wanting to move forward with the offer to hire them. - Do not list every possible flag, but rather just the important red flags to consider when justifying they are a good hire choice. How do we intend on setting this candidate up for success? * - Expand on each flag described above and how you, as the HM plan to mitigate that flag and set the candidate up for success at GitLab. Is the offer in-plan, and why? (e.g.: critical budgeted hire, backfill, transfer) * - Stating which kind of hire is sufficient, per the referenced examples. Does the candidate meet a simple majority of nice-to-have requirements (5 of 9) for the role? * - Yes, [First Name] met a majority of the nice-to-have requirements.