Interviewing is hard for both sides. In less than one hour, you both need to get to know each other and make a decision about whether or not you would want to work with this person. The following is an effort to provide a set of guidelines to make interviewing a bit less traumatizing for all involved parties.
New internal interviewers will partake in interviewing training, our new pilot with SocialTalent that is invite-only, or as a part of the Becoming a GitLab Manager issue template. Current team members can also create their own interview training issue using the interview_training
template in the Training project.
As part of the training, team members will shadow an interviewer and be shadowed by one in order to make sure all GitLab team-members are following our interviewing processes and creating an excellent candidate experience. The interviewer who will work with the team member should be aligned with either their timezone or the role they'll be helping interview for. Feel free to ping @gl-talent-acquisition
in your training issue or review our talent acquisition alignment page if you are not sure which interviewer to contact, or send a message in the #talent-acquisition
channel in Slack.
Interviews should not be recorded. For interview training, we encourage our GitLab Hiring Managers to conduct mock interviews internally, or have no more than one GitLab team member at a time shadowing live interviews.
If you need to shadow interviews to complete their interview training issue, you reach out to the assigned recruiter for your department based on the talent-acquisition alignment.
It is typically expected for new hires to focus on and complete their onboarding for at least two weeks before being part of an interview team for any vacancies. There may be extenuating circumstances where a team member needs to participate in interviewing sooner than this, but they should always complete the interviewing training and discuss the vacancy thoroughly with their manager and the recruiter prior to being on an interview team.
Please avoid in-person interviews. In-person interviews or meetings are reserved for candidates if an offer is approved or if the candidate is hired. Anyone wanting to do in-person interviews should reach out to People Business Partners to discuss beforehand and have a clear reason which should be documented in their Greenhouse profile.
Read about how to organize your calendar on the Interviewer Calendar Maintenance page.
Remember, interviewing candidates is everyone's job as part of our collaboration value! You may be asked to participate on an interview team, as we continue to hire great talent.
Please note the importance of confidentiality in the interview process for both internal and external interview processes. Candidates should not be discussed outside of the hiring manager management chain and direct interview team. It is important to respect the privacy of all candidates who apply for positions at GitLab, whether they are internal or external.
All feedback should be recorded in Greenhouse and/or discussed live with the hiring manager and/or interview team as applicable.
Tips On How To Prepare For Your Technical Interview
The goal of behavioral questions is to get the candidate to share data on past experiences. Previous behavior is considered the most effective indicator of how a person is going to act in the future. It is important to remember that skills and knowledge can be learned easier than habitual behaviors can be changed, especially when candidates are unaware of the impact of the undesired behaviors.
The questions are usually in the form of:
"Can you tell me about a time when…?"
The kind of answer that we are looking for is to get a story that is structured following the Situation, Task, Action, and Result (STAR). Ask for an overview, an executive summary, of the case at hand. Try to avoid lengthy answers from the candidate at this stage.
Some things to pay attention to:
There is no right answer; what matters here is to listen to the candidate and gather data on how they are telling the story.
Once you have your notes, tell the candidate what you understood, repeat the story, and let them correct you as needed.
After gaining a high-level understanding of the case, we will want to dive deeper into the details. The objective of this step is to understand and detail the exact contributions a candidate has made to an effort which led to results. We will take a reverse approach to the STAR question structure presented earlier.
The key to analyzing each of the reverse-STAR steps is to ask What, Why, How, and Who at each step of the process. This will let the candidate paint a very clear picture of the situation, their ownership of the idea/solution, and their decision process in key pivotal moments. Reverse the order of the STAR structure, and drill up from results to the situation as a whole. Find the answer to the following questions:
These questions can be quite unbalancing and can increase the stress during the interview. Again, be kind and help the candidate understand what you are looking for, and provide an example if one is needed when you notice the candidate is blocked.
It can also happen that the candidate does not have a story to share with you; that is okay. It's just another data point that should be added to the feedback (I failed to get data on …). Just move to the next question and be sure to have a few questions as a backup.
If it is relevant to the topic or competency that you are assessing, you can use Career Change Drivers to understand what motivated the candidate to make transitions in their career. Understanding this ensures that the candidate is positioned to be successful in the role they are interviewing for.
Walk through the candidates resume in reverse chronological order. For each role ask:
In Greenhouse, you will use an "interview kit" when interviewing a candidate, which has text for feedback and scorecards for skills and values.
We want to highlight the strengths and weaknesses of the candidate in an easy to absorb, standardised way. Every scorecard must include Pros and Cons. This helps the talent acquisition team gather data that will be presented to the candidate in the form of feedback.
The bottom of the feedback form will ask for an overall recommendation on if you want to hire this person or not; please do leave a score for each candidate, and read our handbook page discussing the scorecards and best practices.
Scoring is defined as follows:
Strong Yes
- Very likely to hire (meets most requirements, aligns with values)
Yes
- Semi-inclined to Hire (may meet some requirements, has some yellow flags)
No
- Not likely to hire (meets few requirements, has many yellow flags, may not align with values well)
Strong No
- Would not hire (does not meet requirements, red flags, not aligned with values)
The scoring definitions for GitLab's Engineering Division are defined differently than the rest of the company. Rather than scores representing the probability of a hire, they are meant to reflect the candidates interview performance. This allows us to expect scores to fit the normal distribution. The probability densities of Strong yes
and Strong no
should be greater than one standard deviation away from the mean.
Strong Yes
Yes
Yes
: All must-haves criteria that were evaluated in the interview were presentNo
: One, or more, must-have criteria that were evaluated were found to be missingStrong No
No
More info on engineering hiring practices.
Whereas the scoring definitions company-wide describe the probability of hire, the scoring definitions in the Engineering Division are meant to reflect the candidate's interview performance. To further support the ability to utilise interview results to hire across all levels, we have added a 'Level' category to R&D scorecards.
In this category, the interviewer can define the level the candidate scored on, and add details on why they scored a candidate on the particular level. The added value of this category is that the interviewer can score the candidate on multiple levels (ex. the Senior level and the Intermediate level).
This scorecard feature will increase sharing of candidates that, for example, may meet the 'must-have' criteria on an Intermediate level position but did not meet all of the 'must have' criteria on a Senior level. The dual score, when applicable, will help recruiters and hiring managers with candidacy decisions. Interviewers should use the notes section to capture the why behind their score and provide any additional detail that is directly relevant in assessing leveling.