Conducting a GitLab Interview

1. You are here:
2. Hiring
3. Conducting a GitLab Interview

On this page

• Conducting a GitLab Interview
  • Interview Training and Preparation
  • Best practices
    • Before The Interview
    • Confidentiality
    • Interview Shadowing
    • Illegal Interview Questions
    • During The Interview
    • Considerations for Interviews With Technical Applicants
  • Candidate Performance Evaluation
    • Behavioral Questions
    • Career Change Drivers
  • Interview feedback
    • All divisions but Engineering
    • Engineering division
    • Level Categories in Engineering Scorecards
  • Frequently Asked Questions (FAQ)

Conducting a GitLab Interview

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.

Interview Training and Preparation

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.

When you shadow an interviewer, you will receive a scorecard to provide interview feedback. This is a great opportunity to add your feedback and compare notes with the Recruiting team and/or the interviewer you're shadowing. To ensure it's clear you're shadowing to the hiring team, please add a note in the "Key Takeaways" section that you were shadowing the interview, and don't choose a rating (Yes/No).

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.

Best practices

Before The Interview

1. Ensure you've read the description of the role you're going to be interviewing candidates for. This can be found in the job family page.
   • If you have any questions about the scope of the role, the team, or the responsibilities of the position after you've read through those resources be sure to reach out to the Hiring Manager with your questions.
2. Open up the interview kit in Greenhouse. In the interview kit, you’ll be able to view the candidate’s resume, the description of the interview you’re expected to lead, the scorecard you’ll be evaluating the candidate against, and the suggested questions you ask during the interview.
   • Look out for key criteria to focus on in the scorecard. These will be highlighted in yellow and these are the areas you must evaluate the candidate against at this stage of the interview process.
3. You can read through the cover letter, portfolio, or application form responses submitted by the candidate when they applied by navigating to the candidate’s Greenhouse profile if you have Hiring Manager level access. You can navigate to their profile by following the link from their name in the interview kit. These additional resources will only be available if they were required to be supplied when the application was made or a candidate opted to submit additional information. If you do not have Hiring Manager access, your interview kit will contain a resume for review.
   • When reading through the candidate's application materials please remember that writing a good resume or cover letter is an art, and not many people master it. When you read through these materials, look for evolution rather than buzzwords, and, if something sparks your curiosity, prepare to ask about it during the interview.
4. Make sure you're up to date on our latest headcount, notable awards, messaging, and other facts about working at GitLab. Take a look at these talent brand resources to help guide your conversation with candidates.

Confidentiality

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.

Interview Shadowing

Shadowing as a new interviewer at GitLab is an important part of interview training as we continue to grow. Once you have completed the steps in the Interview Training Issueyou may organise shadowing by reaching out to the specific Hiring Manager, Recruiter or the Talent Acquisition team.

Interview shadowing is only available to full time GitLab team members. Under no circumstances should an outside third party be invited to shadow or interview a candidate.

The reasons why we don't allow third party interview shadowing:

• An interview is a confidential discussion where a candidate should feel comfortable sharing their professional achievements and experience. If we invite third parties to an interview this would be a breach of candidate confidentiality and would impact the overall experience a candidate would have to interview with GitLab. We could potentially miss out on hiring great candidates as they may be hesitant sharing information that could impact whether the interviewer provides positive or negative feedback regarding their recommendation to hire.
• Even if the candidate is asked and indicates in the interview that it's ok for the third party to attend, or the third party has signed an NDA, the candidate may not be in a position to feel like they have a choice whether to provide their consent. They may feel as if they have been forced to allow the third party to attend, which negatively affects the candidate experience.
• GitLab wants to ensure that each candidate has a fair and unbiased interview process. Having a third party present undermines these efforts.

Illegal Interview Questions

• Be aware of the kinds of questions you can and can't ask. For example, if there is a gap in employment history on a CV, you may ask the candidate what they did during that time to keep their skills current. You may not ask why they were absent from work as it may be related to a medical or family issue, which is protected information.
• Refrain from any personal, icebreaker-type questions. There are laws that prohibit discrimination based on any lawful activity, so asking a candidate about personal interests or hobbies could elicit information about the candidate that an employer finds undesirable yet is still legally protected.
• Refrain from asking any questions related to protected classes (for example: age, race, gender, gender identity, religion, sexual orientation, marital or family status, pregnancy status, national origin, ancestry, physical or mental disabilities).
• Protected classes differ based on the country of the candidate, but we default to the strictest country definitions. Therefore, even if sexual orientation is not a protected class where your candidate lives, we will consider it protected at GitLab in our interview criteria.
• To find out more about discrimination laws specific to the country of a candidate you're interviewing, you can reach out to the legal-employment and/or talent acquisition team.
• Asking questions related to any of the protected classes is not only illegal, but shouldn’t be asked to determine if someone is qualified for a role.
  • Some examples of illegal interview questions include:
    • So you mentioned you live with your partner earlier, are you married?
    • How old are you by the way?
• You should stay away from any questions and conversations around protected classes, and focus instead on the job duties. What is important is whether the candidate can be successful in the role and only asking questions relevant to that.
• If a candidate does bring up personal information during an interview related to a protected class, it's OK to acknowledge their comment and get the interview back on track.
  • Some suggestions on steering the interview back to appropriate topics:
    • So, we were just talking about your role’s current responsibilities. How technical are you hoping to stay in your next role?
    • I have a few more questions that I’d love to get to during our call today. Tell me a little bit more about how you’ve achieved quota in the past.
  • This information should not be included in your Greenhouse feedback as it does not pertain to the functions and responsibilities of the role.
  • This information should not be used to determine if you are a yes or a no to their candidacy for the role.

During The Interview

• Show up prepared and on time. (See "Before The Interview" section above)
• Be cognizant of where the candidate is at in the interview process. Are you the first interviewer? Are you the third? Be aware that the candidate has likely repeated themselves quite a bit and has already asked many of the general questions they had about the position in previous interviews.
• Build rapport and put the candidate at ease. Introduce yourself, tell your GitLab story, ask how the candidate is doing- banter/small talk is ok.
• Talk a bit about the role (why it is open, what the job entails, etc.)
• Set expectations on how the interview will run
• As candidates move through the interviewing process, interviewers take notes within Greenhouse. As they move through the process, interviewers have the opportunity to review any specific notes previous interviewers have left for them, although the full feedback notes from previous interviewers are obscured from current ones in an effort to avoid creating bias. Hiring managers, executives, and people ops are able to see all feedback notes at any time.
  • Let the candidate know you are taking notes
  • Be an active listener
    • Concentrate on the candidate - remove all distractions (turn off notifications on your phone, slack, email, etc.)
    • Look at the candidate - make sure to look at your camera - not another screen
    • Try not to interrupt - Validate your assumptions by explaining what you understood, and allow the candidate to correct your understanding of the story.
    • Silence is golden
• Cover the prepared topics/questions without being mechanical
  • Setup the interview plan in Greenhouse ahead of the interview to ensure all the areas you want to cover are in the scorecard
  • Try to cover the prepared topics, but keep the conversation smooth - it is ok to skip around
  • Redirect the conversation as needed - you are in charge of keeping the conversation focused and timely
• There is an unbalanced power relationship during the interview, and interviewers should be mindful of this fact. The interviewer is in a powerful position: they will decide if the candidate will move forward or not. Be as friendly and approachable as you can. Be frank about what is going on, and set clear expectations: tell it like it is. This has the added value of getting people comfortable (over time) and allows you to get much better data.
• Communication is really hard, so don't expect perfect answers. Every person is different, and they may say things differently than what you expect or how you might say them. Work on interpreting what they are trying to say rather than demanding them to explain it to you. Once you have an answer, validate your assumptions by explaining what you understood, and allow the candidate to correct your understanding of the story.
• Don't go checking for perfect theoretical knowledge that the interviewee can google when needed during regular work or expect them to master over the course of a 30-minute conversation a problem that took you 2 months to dominate. Be fair.
• Aim to know if, at the end of this interview, you want to work with this person.
• Interview for soft skills. Really, do it! Pick some behavioral questions to get data on what the candidate has done before and how their behavior aligns with the company values. We are all going to be much happier if we naturally agree on how things should be. You will be asked to evaluate how the candidate's values align with our own in your feedback form, and asking behavioral questions is the best way to assess this.
• Consider having more people interviewing with you since different people see and value different things. More data helps you make better decisions and is a better use of interview time for both the candidate and the company.
• If a candidate discloses outside project(s) or activity(ies), please notify the Recruiter.
• Always encourage the interviewee to ask questions at the end, and be frank in your answers.
• Be willing to discuss what went well and any concerns you may have
• Manage expectations - Discuss next steps and timelines
• Thank the candidate for their time

Considerations for Interviews With Technical Applicants

Tips On How To Prepare For Your Technical Interview

1. Try to get a real sample of work, which we typically do for developers during a technical interview. Avoid puzzles or weird algorithm testing questions. Probing for data structures is fine as long as it is relevant to the job the person is going to do.
2. Be mindful of the background of the candidate. Someone who knows 10 languages already (and some languages in particular, Perl for example) may pick up Ruby in a second if given the right chance. Don't assume that someone with a Java background will not be capable of moving to a different stack. Note that individual positions may have stricter requirements; the Backend Engineer position requires Ruby experience, for example.
3. Consider including non-engineering GitLab team-members in the interview to ask soft skills questions. Because technical people should be capable of talking to non-engineering people just fine, we should assess the candidate's ability to do so.

Candidate Performance Evaluation

Behavioral Questions

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. In order to avoid lengthy answers from the candidate at this stage consider briefly explaining the STAR structure before asking your first behavioral question. Stating something like - "These questions are behavioral, so try and structure your response by briefly outlining the situation, describing the task to be performed, outlining the actions you took and explaining the results."

Some things to pay attention to:

• What the candidate chose to highlight in their response as important
• Is it clearly explained? Is the story well told? If it is a technical story and you are a non-technical interviewer, are things being explained in a way that is easy to understand?
• Is there a result or was the story left unfinished? Is it still going on?
• Was the result measured in any way? How does the candidate validate the result matched the expectation? Was there an expectation set to begin with?

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:

1. What was the goal to achieve or the problem to overcome? What was the expectation? Was the goal defined from the get-go?
2. How was the result measured? Why was it measured that way?
3. What steps or process was followed to achieve the result? List them together with the candidate
4. Who else was working with the candidate? Was the candidate working alone?
5. What role did the candidate have in the team if they did not work alone on the project? Was the candidate in charge of specific tasks? Who decided on task assignments? What was their impression of the tasks? How were the tasks decided on?
6. For the tasks discussed above, understand if there were resources that helped the candidate and at what capacity. How were those chosen and why?

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.

Career Change Drivers

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:

• Why did you take the role?
• Why did you leave the role?

Interview feedback

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:

All divisions but Engineering

• Strong Yes - Very likely to hire (meets most requirements, aligns with values)
  • You have no significant questions and are confident (to the best of your knowledge with the information at hand) that the candidate would succeed in the role.
  • Candidates who receive Strong Yes feedback may have later steps in the hiring process parallelized by the hiring manager and should almost always be extended an offer in the absence of negative feedback or concerns.
• Yes - Semi-inclined to Hire (may meet some requirements, has some yellow flags)
  • You think the candidate is qualified for the role, but you are either not certain, or still have some outstanding questions that should be addressed at a later stage.
  • By default, Yes candidates should move forward in the interview process, although hiring managers should use their judgement and look for patterns in any outstanding questions or areas where it's difficult to get insight into a particular candidate. It may be appropriate to reject a candidate who does not receive stronger feedback through our process.
• No - Not likely to hire (meets few requirements, has many yellow flags, may not align with values well)
  • You think the candidate is unqualified for the role, but have some doubts or would be willing to be swayed by some strong feedback from other interviews.
  • Hiring managers should use their discretion to determine whether or not to continue the interview process with any candidate that receives a No vote.
• Strong No - Would not hire (does not meet requirements, red flags, not aligned with values)
  • You are certain this candidate is not qualified and/or not a good fit for the role.
  • Candidates who receive a Strong No vote should almost always be rejected immediately by the hiring manager.

Engineering division

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
  • Extends Yes
  • Meets an unusually large proportion of our "nice to have” criteria for the role
  • Brings interesting qualities that we were not necessarily looking for
• Yes: All must-haves criteria that were evaluated in the interview were present
• No: One, or more, must-have criteria that were evaluated were found to be missing
• Strong No
  • Extends No
  • The candidate demonstrated clear opposition to either our Collaboration, Diversity, or Results values
  • The candidate demonstrated unwillingness to learn our Efficiency, Iteration, or Transparency values

More info on engineering hiring practices.

Level Categories in Engineering Scorecards

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.

Frequently Asked Questions (FAQ)

• My Zoom link isn't working, who can help?
  • This is a common occurrence due to a Zoom configuration issue. You can share a new Zoom link directly via email with the candidate if you notice this problem at the scheduled interview time. The #IT-help Slack channel will be able to guide you on the correct configuration to prevent this issue occurring in the future.
  • The Candidate Experience Specialist team can be reached on slack in an emergency by tagging @ces in your message.