The best way to apply for a position with GitLab is directly through our jobs page, where our open positions are advertised. If you do not see a job that aligns with your skillset, please keep your eye on the jobs page and check back in the future as we do add roles regularly. Please be advised that we do not retain unsolicited resumes on file, so you will need to apply directly to any position you are interested in now or in the future.
You will be redirected to a new page hosted by Lever, our Applicant Tracking System (ATS), where you can read the job description. If the position interests you, click "Apply for this Job".
You will be asked to fill out basic personal information, provide your resume and cover letter, and answer any application questions, as well as answer a voluntary Equal Employment Opportunity questionnaire.
Once you have finished, click "Submit Application" at the bottom.
Typical Hiring Timeline
An applicant should expect to wait 2-3 business days between each step of the process. An applicant, at any time, is welcome to contact the People Ops team member they are working with for an update on their candidacy.
The employment team does a first round of evaluations. Disqualified candidates will be sent a note informing them of the rejection. There are templates in Lever to assist, but messages can be tailored as appropriate. Place yourself on the receiving end of the message. If more information is required to make the determination, feel free to specifically ask for it (e.g. a cover letter). (If you don't see the templates, you probably haven't linked your email account to Lever yet.)
Pre-screening Questionnaire: Many applicants will be sent a pre-screening questionnaire by the employment team relating to the position to complete and return to the sender.The questionnaire and answers will be added to the candidate's Lever profile.
Team members who review the pre-screening questionnaire answers should refer to the GitLab private project that holds guides on how to review each of the questionnaires. Candidates who receive an assessment should be moved to the "Assessment" stage in Lever.
Candidates that have satisfactory assessment results may be invited to a screening call.
If the applicant qualifies, a member of the employment team will conduct a screening call using Lever.
A member of the employment team will move the applicant to the "screening call" stage in Lever.
Our recruiters will do a screening call; depending on the outcome of the screening call, the employment team or manager can either reject an applicant or move the applicant to the interview stage in Lever.
Technical interview (optional): As described on the Jobs page, certain positions require technical interviews.
Further interviews: Additional interviews would typically follow the reporting lines up to the CEO. For example, the technical interview may be conducted by an individual contributor, with subsequent interviews being conducted by the manager / team lead, executive team member, and then the CEO. See below for sample questions. The candidate should be interviewed by at least one female GitLab team member.
References: The employment team will conduct references for promising candidates. This process can start at an earlier stage, but should happen before an offer is made. At minimum two references should be completed - one to a manager, the other to a colleague. Move the candidate to the "Reference Call" stage in Lever, and ping the relevant person from People Ops to get it going.
Hiring package: After reference calls are completed successfully, the employment team submits the employee approval package to the CEO and Hiring Manager.
When the manager or CEO makes the offer, this can be done verbal during the call with the applicant, but is always followed quickly with the written offer as described in the section on preparing offers and contracts.
People Ops will draft a contract based upon the written offer that was extended.
Manager follows up to ensure that the offer is accepted, and that the contract is signed.
We conduct screening calls for all positions. This call will be completed by our recruiters.
Questions include:
Why are they looking for a new position?
Why did they apply with GitLab?
What is their experience with X? (for each of the skills asked in the position description)
Current address? (relevant in context of comp, and in case of contract we will need that information)
Full legal name? (relevant in case an offer would be made)
How do they feel about working remotely and do they have experience with it?
Compensation expectation.
Notice period needed
Do they require a visa/residence permit to be able to work for GitLab?
STAR questions and simple technical questions may also be asked during the screening call if applicable.
At the end of the screening call applicant should be told what the timeline is for what the next steps are (if any). An example message would be "We are still reviewing applications, but our goal is to let you know in 3 business days from today whether you've been selected for the next round or not. Please feel free to ping us if you haven't heard anything from us by then."
Moving Applicants Through The Process
Remember to inform applicants about what stage they are in. So, for example, if in the hiring process for the particular position / team you've agreed that there will be four stages, be sure to inform the applicant of where they are in the process during each call / stage: "You are in stage X and will be moving to stage Y next." Some brief feedback from the previous stage can also be included to help the candidate gauge their progress.
The process can differ from team to team and from position to position. If an applicant submits a resume to a particular open position and is being considered for another open position, send a short note to update and approve with the candidate, as well as inform them that their process may be slightly different or delayed.
Recruiters will schedule the next person in the process. Someone on the recruiting team will move candidates forward to the next person in the hiring process if the candidate has received positive feedback.
Compensation is discussed at start and end but not in between. Compensation expectations are asked about during the screening call. If the expectations seem unworkable to the manager or recruiter (based on what had been approved by the compensation committee at the creation of the vacancy), then the recruiter can send a note to the candidate explaining that salary expectations are too far apart. If expectations are aligned, then the topic of compensation should not re-surface until an offer is discussed internally. Following this guideline avoids conflating technical and team interviews with contract discussions and keeps the process flowing smoothly.
If the manager has a question about compensation, please ping the People Operations Specialist for review. If the question needs to be escalated, the People Operations Specialist will add the Chief Culture Officer to the conversation.
The CEO authorizes all offers.The manager proposes a suggestion for an offer (including bonus structure if applicable, etc., using the global compensation framework) as an internal comment in Lever and informs the CEO on its details depending on what is applicable.
Be aware that the visibility of internal comments in Lever are only available to certain team members.
If you would like to receive less or more notifications from Lever, go to your Setting pane in Lever, and scroll down to "Slack notifications" and "Email notifications" to manage your preferences.
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 both will have to make the decision if you want to work with this person. This is an effort to provide a set of guidelines to make interviewing a bit less traumatizing.
Note: So you are about to interview folks for a job at GitLab? Please take a moment to carefully read this document on keeping it relevant and legal, including a self-test(please note this document is internal to GitLab while we edit it to make it fit for general audiences). For example, if there is a gap in employment history on a CV, you can 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.
Before The Interview
Screening - writing a good resume is an art, and not many people master it. When you read a resume look for evolution rather than buzzwords, and if something sparks your curiosity, ask.
If the process is taking too long, apologize and explain what is going on. It is really frustrating to not hear anything from the other side, and then resume conversations like nothing has happened. Show respect for the time of the candidate.
If the process ends at this stage, be kind, and if the interviewee asks for feedback, give honest constructive feedback that explains why we have made our decision.
During The Interview
There is an unbalanced power relationship during the interview. The interviewer is in a powerful position. They will decide if this candidate will get an offer or not. Be mindful of this. Be as friendly and approachable as you can. Be frank about what is going on, explain how the interview is going to be 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, don't expect perfect answers. Every person is different and they will express things differently, they are not listening to your train of thought so they will say things differently than what you expect, work on approaching to what they are trying to say rather than demanding them to approach to you. Once you have an answer validate your assumptions by explaining what you understood and allow the candidate to correct your story.
Don't go checking for perfect theoretical knowledge that the interviewee can google when needed, or give a problem that took you 2 months to dominate yet you expect your interviewee to master in a 30 minutes conversation. Be fair.
Aim to know, at the end of the interview, if you want to work with this person.
Interview for soft skills, really, do it. Pick some behavioral questions to get data on what has the candidate done before and how their behavior aligns to the company values. We are all going to be much happier if we all naturally agree on how things should be.
Consider having more people interviewing with you, different people see and value different things. More data helps making better decisions and ends up being a better use of interviewing time for both the candidate and the company.
Always let the interviewee ask questions at the end, and be frank in your answers.
Technical Interview Considerations
Try to get a real sample of work (which we already do for developers by working on GitLab issues). 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.
Be mindful of the background of the candidate, someone who knows 10 languages already (and some languages in particular, Perl for ex), may pick up Ruby in a second 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 Developer position requires Ruby experience, for example.
Consider including non-engineering people to ask soft skills questions. Because technical people should be capable of talking to non-engineering people just fine, we should assess it.
Candidate Performance Evaluation
The goal of behavioral (STAR) 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.
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, Result. Ask for an overview, an executive summary, of the case at hand. Avoid lengthy answers from the candidate at this stage.
Some things to pay attention to:
What the candidate chose to highlight in the case as important
Is it clearly explained? Is the story well told? If it is a technical story and the interviewer is a non-technical person, 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 hear 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 having 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 idea/solution and the 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:
What was the goal to achieve or the problem to overcome? What was the expectation? Was the goal defined from the get-go?
How was the result measured? Why was it measured that way?
What steps or process was followed to achieve the result? List them together with the candidate
Who else was working with the candidate? Was the candidate working alone?
What role did the candidate have in the team, if not alone on the project? Was the candidate in charge of specific tasks? Who decided on task assignment? What was their impression of the tasks? How were the tasks decided on?
For the tasks discussed above, understand if there were resources who 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 are you looking for, 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 OK. 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, just be sure to have a few questions as a backup.
These questions should be aligned with our company values. What we are looking for is understanding how this candidate behaves, and if this behavior matches the one we look for in our company values.
For a brief explanation about how behavioral interviews work refer to this video (GitLab's internal use only)
Interview Feedback
Always leave feedback, this will help everyone to understand what happened and how you came to your decision. In Lever, when interviewing a candidate, please leave feedback in the custom feedback forms created in Lever. Currently, most roles do not have custom feedback forms, so we are using the "General feedback" form for most candidates. Part of the feedback form will ask for a score - please do leave a score for each candidate.
Scoring can be defined as follows:
4 - Very likely to hire (meets most requirements, aligns with values)
3 - Semi-Inclined to Hire (may meet some requirements, has some yellow flags)
2 - Not likely to hire (meets few requirements, has many yellow flags, may not align with values well)
1 - Would not hire (does not meet requirements, red flags, not aligned with values)
Rejecting Applicants
At any time during the hiring process the applicant can be rejected.
The applicant should always be notified of this. The employment team is primarily responsible for declining candidates.
If the applicant asks for further feedback only offer frank feedback. This is hard, but it is part of our company values.
All feedback should be constructive and said in a positive manner. Keep it short and sweet.
Feedback should always be applicable to the skill set of the position the candidate applied and interviewed for.
Feedback and rejection should always be based on the job requirements.
If you feel uncomfortable providing feedback for whatever reason, reach out to People Ops for assistance.
Suggested feedback format: "The reason we don't think you're the best match for this position is __ . We are impressed with your skill in __ . That we decline you doesn't mean that you are not a good fit for this position. We receive over 1000 applications per month and have to decline almost all applicants. Both Facebook and Twitter rejected the founder of Whatsapp https://thehustle.co/whatsapp-founder-got-rejected-by-both-twitter-and-facebook-before-19-billion-buyout. We don't think we'll do any better and look forward to hearing from you after landing a better job or starting a successful company. Thanks for your interest in working at GitLab." This format can be used as a guideline to help candidates understand our decision, but can be personalized/customized to fit each situation. Personalization in communication with candidates is encouraged.
If people argue with the feedback that we provided:
Do not argue with or acknowledge the validity of the contents of the feedback.
Share their feedback with the people involved in the interviews and the decision.
Template text: "I've shared your feedback with the people involved in the interviews and the decision. We do not expect to revert the decision based on your feedback. In our hiring process we tend to error on being too cautious. We rather reject someone by mistake than hire someone by mistake, since a wrong hire is much more disruptive. Organizations can reject people with great potential http://thehustle.co/whatsapp-founder-got-rejected-by-both-twitter-and-facebook-before-19-billion-buyout so please don't be discouraged from seeking a great job."
The employment team will send out an inquiry to all candidates to gather feedback after they have exited the hiring process. The feedback survey should be sent out within 2 days after the applicant has been notified of the rejection or hire.
People Ops will review all feedback and use it to improve the hiring process.
Hiring Package
The employment team will create an employee approval package for CEO for each candidate in Lever after their interview with an executive and their reference checks are completed. The CEO will review the approval package and tag the candidate as Approve, Question, Interview, Decline.
Approve = Make the offer
Question = Discuss offer with hiring manager
Interview = Proceed with final CEO interview
Decline = Decline candidate
Leave a secret comment in Lever with below hiring package template filled out and cc the hiring manager and CEO. Ping the CEO in chat with "Hiring approval needed for [Position]" with a link to the Lever comment.
Request approval for the following hire
Level and position:
Interviewers and their score:
Flags raised:
Location:
Candidate's salary expectation beginning of process:
Suggested Comp and stock options:
Comp Calculator url:
Hiring manager:
In case of interview is it OK to make the offer as CEO:
Getting Offers and Contracts Ready, Reviewed, and Signed
Offers made to new team members should be documented in Lever through the email thread between the person authorized to make the offer and the applicant.
Email example is in the "Offer letter" template in Lever. When using the template:
include the People Ops alias in the cc (when you are ready for a written contract to be made), and
change the subject line of the email. The default subject line in Lever is "{position name} - GitLab", but when making multiple hires for the same position, this can cause confusion in a Gmail inbox that collects conversation threads based on subject line. So for example make it "{first name of applicant} - offer for {position name} at GitLab" (this can be done via the Lever email template).
Note: the number of proposed stock options must always be mentioned specifically, even when it is 0.
One person from People Operations will reply-to-all to everyone in the thread (including the applicant) to confirm that they will make the contract. Speed matters: if you are in People Operations and you can tackle this, then raise your hand and hit reply-all.
This person from People Operations
checks all aspects of the offer:
was it approved by the CEO?
do the contract type and entity make sense?
is it clear how many (if any) stock options this person should receive?
is all necessary information (start date, salary, location, etc.) clearly available and agreed to?
makes the contract based on the details found in the Lever platform, using reply-all to gather any missing pieces of information,
has the contract reviewed and approved by another member of People Ops as a quality check. The People Ops team member who did not create the contract will conduct the quality check. Backups for approval are the People Ops Generalist, then the People Ops Specialist, and lastly the Chief Culture Officer.
stages the contract in HelloSign and emails offer to the signing parties, cc People Ops
When the contract is signed, the People Ops team member should move the candidate in Lever to the "Hired" bucket, which is only accessible to Lever Super Admins. Thanks to an integration between Lever and BambooHR, it will automatically add an entry for the new team member in BambooHR. However, in the automatic move, "self-service" is switched off in BambooHR by default, so this must be switched on explicitly within BambooHR.
This same person from People Operations files the signed contract in the appropriate place, and starts the onboarding issue.
Candidates will start the onboarding process no more than 30 days before her/his start date.
Note for People Operations:
the type of contract required (employee or contractor; BV or Inc) is clarified by the guideline on the Contracts page.
Onboarding info for the People Ops system, BambooHR, can be found on the People Ops page.
CEO Interview Questions
The questions are available in a Google form which can be used to save time during the actual interview. All candidates are asked to fill out the form when they are scheduled for an interview with our CEO to discuss during their call with the CEO.
Reference Calls
As part of our hiring process we will ask applicants to provide us with two or more references to contact. These reference calls are completed by our employment team following these guidelines.
Background Checks
Team members in the certain positions must partake in a background check, which covers criminal and employment history.
Candidates who are in Support Engineering, Customer Success, People Ops, Finance, Sales (client-dependent), and the Executive team will be sent the link to the background check after the offer stage. The new team member may start with GitLab prior to the returned check, but their continued employment will be contingent on a clear returned check.
