Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Conducting a GitLab Interview

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

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, which will be assigned by the the Candidate Experience team, or as a part of the Becoming a GitLab Manager issue template. 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.

Please remember that your personal meeting room that is used for scheduling interviews should not have passwords on them but should have the waiting room enabled.

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 where possible. 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.

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. 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.
    • 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.

Illegal Interview Questions

During The Interview

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

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:

  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.

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
Engineering division
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license
View page source — Edit in Web IDE — please contribute. Creative Commons License