Interview Playbook / Developer Tools & Infrastructure

How GitLab Interviews in 2026: Process, Questions & What They Score

HOW TO READ THIS PLAYBOOK

Compiled from 17 public sources: candidate interview reports, coaching guides, and GitLab's own hiring pages. Interview processes change and vary by role, team, level, and region. This is one well-documented shape of GitLab's interviews to prepare against, not a script of what your interview will be. Confirm specifics with your recruiter. SupaCV is not affiliated with or endorsed by GitLab.

Medium confidenceLast verified SEP 202617 sourcesSources

GitLab is an all-remote DevSecOps platform company, and this dossier covers the track it is best known for: software engineering (backend and frontend individual contributors). GitLab publishes an unusual amount of its hiring process in its public handbook and in its job description library, so most of the process detail here comes from GitLab itself rather than from candidate hearsay. The engineering path runs: a short written assessment, a 30 to 40 minute recruiter screening call, a 90 minute technical interview built around a merge request you review asynchronously beforehand, a 45 minute behavioral interview with an Engineering Manager, and a 60 minute interview with a Director of Engineering, then references and offer. GitLab does publish an evaluation framework: its CREDIT values (Collaboration, Results for Customers, Efficiency, Diversity, Inclusion & Belonging, Iteration, Transparency), and its interviewer handbook states that interviewers use behavioral STAR questions to assess how a candidate's values align with GitLab's before scoring on a scorecard. Non-engineering tracks differ: the Customer Support track, also documented publicly, uses a take-home assessment, a 40 minute screen, a 90 minute technical break-fix interview, and two 60 minute behavioral panels. Question wording below comes mostly from coaching and aggregator sites rather than from GitLab, so treat the exact phrasing as indicative and the themes as reliable.

The Process

  1. 1

    Application and short written assessment · varies

    You apply through the GitLab jobs page with resume, LinkedIn and answers to vacancy-specific questions. Engineering job descriptions state that selected candidates are then invited to complete a short written assessment; the candidate handbook lists Assessment as required only for certain roles. No duration is published for the engineering assessment. For comparison, the Customer Support track publishes 6 calendar days to complete its written take-home.

  2. 2

    Screening call with a recruiter · 30 to 40 minutes

    Engineering job descriptions say 30 minutes with a Global Recruiter; the candidate handbook says screening calls run between 30 and 40 minutes, with some specialist roles needing more, and the Customer Support track publishes 40 minutes. Content covers motivation, experience against the listed skills, salary expectations, relocation, visa sponsorship and notice period. The handbook warns that a no-show without advance rescheduling is a disqualification.

  3. 3

    Asynchronous merge request review (preparation for the technical interview) · up to 1 hour of your own time, delivered at least 24 hours before the call

    GitLab sends a merge request link for a small self-contained application at least 72 hours ahead. The handbook asks you to spend up to an hour reviewing it as you would any project contribution, to finish the asynchronous review at least 24 hours before the call, and to leave a note on the platform when you are done. The merge request comes from a curated bank of exercises; GitLab states it no longer uses live or real issues for this. AI use is explicitly encouraged.

  4. 4

    Technical interview · 90 minutes

    A video call with screen sharing, with a Backend Engineer or Backend Engineering Manager for backend roles and a Frontend Engineer or Frontend Engineering Manager for frontend roles. You walk the interviewer through your review findings and then write code to improve the merge request. GitLab states it evaluates how you communicate asynchronously, your knowledge of the technology, and how well you collaborate with a team member, with questions tied to the qualifications listed for the role. GitLab says it is open-minded about an alternative assignment if a candidate objects to the format.

  5. 5

    Behavioral interview with an Engineering Manager · 45 minutes

    Published verbatim in the backend and frontend job descriptions as a 45 minute behavioral interview with an Engineering Manager. GitLab's interviewer handbook describes behavioral questions using the STAR method plus situational questions, with roughly 80 to 85 percent of the time on interviewer questions and 5 to 10 percent left for the candidate's questions. One candidate report describes this stage as a 60 minute manager round covering work history and behavioral questions, so length varies by team.

  6. 6

    Team interviews (peers or panel) · varies

    The candidate handbook lists a Team Interviews stage that may consist of behavioral, panel and/or technical interviews, and tells candidates to ask their recruiter which type they will get. Engineering job descriptions do not always list a separate peer round, but one candidate report describes a 60 minute round with two teammates on teamwork and collaboration, and the Customer Support track publishes a 60 minute behavioral panel with two Support Engineering Managers. Whether you get this stage depends on the team.

  7. 7

    Director of Engineering interview · 60 minutes

    Published verbatim in the backend and frontend job descriptions as a 60 minute interview with a Director of Engineering. One candidate report describes this leadership round as including open-ended system design discussion; the Customer Support equivalent is a 60 minute Senior Manager or Director interview with a behavioral focus.

  8. 8

    References and optional TMRG connection · varies

    Three references are required, at least one of them a past manager, collected towards the end of the interview stage. An optional conversation with a Team Member Resource Group member is offered. One candidate report puts the reference check at roughly a week.

  9. 9

    Offer and background screening · varies

    The recruiter discusses the offer, and the background check is initiated either alongside references or after the offer depending on your location. No published turnaround time. GitLab notes that for R&D positions technical feedback stays valid for up to 6 months if you reapply to the same job family, and that candidates can be declined at any stage.

Evaluation Framework

CREDIT values

CollaborationResults for CustomersEfficiencyDiversity, Inclusion & BelongingIterationTransparency

GitLab publishes its six core values, which spell CREDIT, on the public values page of its handbook, and the item names above are copied from that page's headings (re-verified word for word on a fresh fetch during this adversarial pass, including the comma after Diversity and the ampersand before Belonging). GitLab's interviewer guidance ties them to hiring: interviewers are told to interview for soft skills through behavioral questions that reveal alignment with company values, using the STAR method (Situation, Task, Action, Result) on the basis that previous behavior is the most effective indicator of future behavior, plus situational questions on hypothetical scenarios. Scoring happens on a Greenhouse scorecard within 24 hours, with Pros and Cons sections required. Standard divisions score Strong Yes, Yes, No, Strong No; the Engineering division scores against a normal distribution and adds separate Level categories to check seniority alignment. Two cautions. First, GitLab does not publish a per-value interview question bank, so the mapping of individual questions to values below is only made where a question plainly names or describes a value, or where it matches a real named sub-value on the official values page (verified this pass: for example "Be respectful of others' time" is a genuine sub-value under Efficiency, which supports rather than invents the Efficiency tag on the time-management question). Second, GitLab's own values page carries dozens of sub-values under each of the six; only the six top-level names are treated as the framework here.

Sample Interview Questions

Values and behavioral (CREDIT)17 questions
  • Why do you want to work at GitLab?
  • How do your values align with GitLab's principles of transparency, iteration, and collaboration?
  • What does transparency mean to you in a workplace?
  • Can you describe a time when you demonstrated transparency or ownership in your work?
  • Describe a time when you helped resolve a disagreement on your team.
  • How do you handle disagreements or conflicts within a team?
  • How do you handle feedback you may not agree with?
  • Tell me about a time you made a mistake. How did you handle it?
  • How would you break down a large feature into something you can deliver quickly?
  • How do you deal with technical debt?
  • Describe your approach to managing technical debt in a long-term project.
  • Tell me about a time when there was change at work and how you handled it.
  • Describe a challenging problem you faced in your last role.
  • What motivates you to do your best work?
  • How do you ensure your work aligns with company values?
  • What would your previous supervisor say about your character?
  • How do you foster innovation in a remote team?
Remote and async working7 questions
  • How do you adapt to working in a fully remote environment?
  • Tell me how you manage yourself when working across different time zones.
  • How do you ensure effective communication and collaboration with team members in different time zones?
  • What do you think makes a great remote team?
  • What experience do you have with remote work or distributed teams?
  • How do you manage your time when you have multiple priorities?
  • How do you stay up to date with new technologies or industry trends?
GitLab product, Git and CI/CD13 questions
  • What is the difference between a merge request and a pull request?Basic GitLab vocabulary; worth knowing before a round built around a merge request.
  • What is the difference between Git and GitLab?Tests basic conceptual knowledge distinguishing the Git version control tool from the GitLab platform.
  • How do you resolve merge conflicts in GitLab?Tests practical Git conflict resolution skill within GitLab's merge request workflow.
  • Explain the steps to create and merge a Merge Request in GitLab.Tests hands on familiarity with GitLab's merge request workflow end to end.
  • Describe the process of creating a new feature in GitLab.Tests familiarity with GitLab's feature branch and merge request workflow.
  • How would you configure a CI/CD pipeline in GitLab using .gitlab-ci.yml?Tests hands on knowledge of GitLab CI/CD pipeline configuration syntax.
  • What is a GitLab Runner, and how is it used?Tests basic knowledge of what a GitLab Runner is and its role in CI/CD job execution.
  • Describe the steps you would take if a GitLab runner is stuck in a pending state.Tests GitLab Runner troubleshooting: tags, availability, and executor configuration.
  • What are GitLab Runners, and how would you troubleshoot their connection issues?Tests GitLab Runner connectivity troubleshooting: registration tokens and network access.
  • What are some best practices for securing CI/CD pipelines?Tests CI/CD security awareness: secrets handling, permissions, and pipeline hardening.
  • How do you integrate GitLab with Kubernetes or Docker?Tests knowledge of GitLab's container and Kubernetes integration for deployments.
  • Explain how you would set up a deployment pipeline for a containerized application.Tests ability to design a CI/CD deployment pipeline for a containerized workload.
  • Can you explain how you'd troubleshoot a failed CI/CD pipeline?Tests CI/CD debugging method: reading pipeline logs, isolating the failing stage, and diagnosing root cause.

Reported problems, listed so you know what to expect. Practice them in your own editor or on the platform you prefer; SupaCV's practice mode coaches how you talk through them.

Coding and system design practice4 questions
  • Design LRU CacheTests hash map plus doubly linked list design for O(1) cache operations; not GitLab's actual round format.
  • Rate LimiterTests system design for rate limiting: token bucket or sliding window algorithms and distributed state.
  • Monthly Active UsersTests SQL aggregation skill counting distinct active users per period; not a confirmed actual interview question.
  • What is your strategy for scaling a CI/CD pipeline to support thousands of daily deployments?Tests open ended system design thinking for scaling CI/CD infrastructure under heavy deployment load.

Reported problems, listed so you know what to expect. Practice them in your own editor or on the platform you prefer; SupaCV's practice mode coaches how you talk through them.

Coach's Tips

Treat the asynchronous merge request review as a graded work sample, because it is one. GitLab says it sends the link at least 72 hours ahead, expects up to an hour of your time, and wants the review finished at least 24 hours before the call with a note on the platform saying you are done. Late or thin comments cost you before you speak a word, and GitLab states it is judging how you communicate asynchronously.

Write review comments the way GitLab writes them: specific, kind, direct, and with the reason attached, not just the correction. The handbook's Collaboration value covers giving feedback effectively, assuming positive intent and no ego, and the technical interviewer is watching you collaborate as well as spot bugs.

Use AI openly if it helps. GitLab's technical interviewing handbook says it encourages the use of AI in the interview process, so explain what you used it for and what you verified yourself rather than hiding it.

Prepare one STAR story per CREDIT value: Collaboration, Results for Customers, Efficiency, Diversity, Inclusion & Belonging, Iteration, Transparency. GitLab's interviewer guidance tells interviewers to use STAR behavioral questions to test values alignment and to score on a scorecard within 24 hours, so make the value you are demonstrating obvious in the Result.

Have an iteration story ready in GitLab's own vocabulary: how you cut scope to a Minimal Valuable Change, shipped a small merge request, and then improved it. Breaking a large feature into something deliverable quickly shows up as a direct question and is the value GitLab talks about most.

Handle the logistics GitLab publishes: ask your recruiter which type each team interview is, since the handbook says team interviews may be behavioral, panel or technical; and line up three references including at least one past manager, because they are collected near the end of the process. Also note that for R&D roles, technical feedback stays valid for up to 6 months if you reapply to the same job family.

Do not assume every candidate's technical round looks identical. At least one public candidate account describes a materially different format (take-home style tasks rather than a merge request review), so confirm the current format with your recruiter rather than over-indexing on any single write-up, including this one.

Common questions

How many stages are in GitLab's interview process?+

GitLab's process has 9 stages, in order: Application and short written assessment, Screening call with a recruiter, Asynchronous merge request review (preparation for the technical interview), Technical interview, Behavioral interview with an Engineering Manager, Team interviews (peers or panel), Director of Engineering interview, References and optional TMRG connection, Offer and background screening.

What framework does GitLab use to evaluate candidates?+

GitLab evaluates candidates against CREDIT values: Collaboration, Results for Customers, Efficiency, Diversity, Inclusion & Belonging, Iteration, Transparency.

What kinds of questions does GitLab ask?+

GitLab's question bank spans 4 categories: Values and behavioral (CREDIT); Remote and async working; GitLab product, Git and CI/CD; Coding and system design practice.

How reliable is this GitLab interview playbook?+

This playbook is medium confidence, compiled from 17 public sources, and last verified September 6, 2026. It describes one well-documented shape of GitLab's interviews, not a guarantee of what any individual loop will look like.

Sources

How similar companies interview

Compare GitLab's process with other Developer Tools & Infrastructure companies in this playbook:

Interviewing at GitLab?

Add it as a Target Role and tailor your resume against the actual job description.

Add GitLab as a Target Role