01 Company claim
The documented mechanism
GitLab's public candidate handbook lists the interview stages in order: application, recruiter screening call, an assessment and a technical interview (each required for certain roles), team interviews, references with an optional TMRG conversation, and then offer and background screening. For the technical interview, the candidate receives a self-contained merge request to a small application built for the interview at least 72 hours in advance. They review it asynchronously and finish at least 24 hours before a 90-minute call. On the call they walk the interviewer through the review and write some code. GitLab says the exercise checks asynchronous communication, technical knowledge and collaboration. References are combined with interview scores and team feedback; they are not the only factor in the decision.
02 Kept apart from the practice
Reported outcome
Self-reported by GitLab: the technical interview page says most candidates respond positively to the test and feedback. It gives no figures.
03 Read before copying
Confounders and limits
GitLab is an all-remote company that builds the merge-request tooling it uses for the exercise. That makes a code-review work sample unusually close to the real job for GitLab and lowers the setup cost. The handbook describes intended process, not measured hiring quality. GitLab also says the technical interview 'can be quite costly for us', so the format takes real interviewer time.
04 Over time
Known revisions, reversals or failures
Documented revision in the source: the technical interview page says GitLab 'no longer' asks candidates to work on live or 'real' issues. It now sends a self-contained merge request drawn from a curated bank of exercises. The same page says candidates who object to what they see as unpaid work should get an open-minded response and possibly an alternative assignment.
05 Editorial interpretation — not a company claim
WeCaseStudy interpretation
WeCaseStudy interpretation: GitLab's version of an async work sample is time-boxed (up to an hour of review), uses a synthetic task instead of real work, and is paired with a live debrief. That pairing tests both the output and how the candidate explains it. The move away from real issues suggests that unpaid-work concerns are a practical design constraint, not just a theoretical one.
06 What transfers
Adaptation boundaries
A smaller company should not assume it can build and maintain a bank of curated exercises. Each one is a fixed cost to design and calibrate. The async format suits roles whose daily work is async and written, which describes GitLab. It may not transfer to roles that are mostly synchronous. The handbook does not say which roles get a technical interview or an assessment, so don't read it as a universal stage.
Claims and their sources
Each material claim has its own type, source, location and review state. A documented policy is not proof that everyone follows it; a vendor describing its own product is vendor-reported.
| Claim | Type | Source and location | Review |
|---|
| CLM-0006 GitLab's candidate handbook lists the interview stages as application, screening call, assessment (certain roles), technical interview (certain roles), team interviews, references and TMRG connection, and offer and background screening. | Documented practice | Candidate Handbook Page | The GitLab Handbook (Company handbook)
Section 'Interview Stages': "The interview process consists of the following stages" | Source checked — source checked 2026-10-17 |
| CLM-0007 For some positions, GitLab's technical interview centres on a merge request to a small application created for the interview, sent at least 72 hours before the call, with the review to be completed at least 24 hours beforehand. | Documented practice | Technical Interviews | The GitLab Handbook (Company handbook)
Section 'Technical Interview Guide': "a merge request to a small application created for the interview" | Source checked — source checked 2026-10-17 |
| CLM-0008 GitLab says the follow-up 90-minute call has the candidate walk through their review and write code, and that its purpose is to see how they communicate asynchronously, their technical knowledge, and how they collaborate. | Documented practice | Technical Interviews | The GitLab Handbook (Company handbook)
Section 'Technical Interview Guide': "see how you communicate asynchronously" | Source checked — source checked 2026-10-17 |
| CLM-0009 GitLab says it no longer asks candidates to work on live or 'real' issues in the technical interview, and that the merge request now comes from a curated bank of exercises. | Documented practice | Technical Interviews | The GitLab Handbook (Company handbook)
Section 'Alternative Assignment Considerations': "we no longer request that they work on live" | Source checked — source checked 2026-10-17 |
| CLM-0010 GitLab states that most candidates respond positively to the technical test and feedback, and that the test is not a way to get free contributions. | Self-reported outcome | Technical Interviews | The GitLab Handbook (Company handbook)
Section 'Alternative Assignment Considerations': "Most of our candidates respond positively to the test" | Source checked — source checked 2026-10-17 |
Cite this record
We Case Study. "GitLab: Handbook-published interview stages, plus an asynchronous merge-request review as the technical work sample". Decision Lab practice record, version 1. https://wecasestudy.com/decision-lab/practices/gitlab-async-technical-interview
Please cite the original company sources listed above for the facts themselves; this record is a structured, scoped summary of them.
