GitLab interview, decoded.

The stages are the handbook's own list: application, screening call, an assessment for certain roles, a technical interview for certain roles, team interviews, references with an optional TMRG connection, offer and background screening. The engineering detail is from the technical interview page, last updated 19 August 2026.

GitLab's six values spell CREDIT, and candidates who arrive with a story for each report better outcomes in the team interviews.

• Collaboration: helping others is a priority, and anyone can chime in on anything
• Results for customers
• Efficiency: the boring solution, written down
• Diversity, inclusion and belonging
• Iteration: the smallest thing that can ship, then the next
• Transparency: public by default, including the hiring process this guide quotes

The screening questions are published verbatim; the technical round has no question list because it is a merge request.

GitLab's technical interview is a merge request, and the handbook describes it in enough detail to prepare exactly. You get the link at least 72 hours out, spend up to an hour reviewing asynchronously, finish a day early and say so, then spend 90 minutes on a call walking through the review and improving the code together. It is graded on three things the handbook names: asynchronous communication, knowledge of the technology, and collaboration. Here is how to do each part.

• The asynchronous review: write it like a colleague's: Read the whole MR before commenting. Then leave comments the way GitLab's own code review guidelines ask: specific, kind, with the reason and a suggestion, marked by severity (blocking, should, could, nit). Cover correctness, tests, naming and edge cases, and say what is good as well. The handbook's first criterion is asynchronous communication, and this is the only artefact of it.
• Finish early and leave the note: The handbook asks for the review complete at least 24 hours before the call and a note on the platform saying when you finished. Both are observed: a late review reads as poor async habits at a company that runs on them.
• The walkthrough: order your comments: Open with the one thing that would block the merge, then the shoulds, then the nits, and be ready to say why for each. Where the interviewer disagrees, argue it or concede it cleanly; the collaboration criterion is scored from this conversation.
• The live coding: improve the MR, do not rewrite it: You will be asked to write code that improves the merge request. Pick the improvement with the best ratio of impact to time (a failing case, a missing test, a clearer function), do it in small commits, run the tests, and narrate. GitLab's iteration value is the smallest useful change first.
• AI is encouraged, with a guideline: The handbook encourages AI in the interview process and links its guideline. Use an assistant the way you would at work, say when you are, and be able to explain any line it wrote; the technology-knowledge criterion is yours to demonstrate, not the model's.
• If you object to the format: The handbook says the MR is self-contained and from a curated bank, not live work, and that GitLab is open-minded about an alternative if a candidate objects to what they see as unpaid work. Raise it with the recruiter early rather than resenting it on the call.

Practise on GitLab itself: pick two open merge requests in a GitLab project in your language, review each in an hour as if it were the interview, then make one improving commit against your review. Read GitLab's code review guidelines page first; the round is graded against the habits it describes.

Levels.fyi medians for GitLab software engineers, read 22 September 2026, across locations, since GitLab pays by a published formula: a benchmark for the role and level multiplied by a location factor for your metro area, shown in a public calculator in the handbook. Two people at the same level in different cities are paid differently by design, and the screening call asks whether the range fits before anything else happens. Equity is listed stock. Run the calculator for your city and level before the screen; the handbook does.

1. 01Read GitLab's handbook pages on the hiring process, the technical interview and code review guidelines; the loop is graded against them and they are public.
2. 02Review two real merge requests in a GitLab project in your language, one hour each, with severity-marked comments and a note when done; then make one improving commit.
3. 03Prepare answers to the published screening questions, including why you joined and left your last three roles and what you want next.
4. 04Have a story for each CREDIT value, especially iteration and transparency.
5. 05Run the compensation calculator for your location and level, and decide before the screen whether the range works.
6. 06Expect scheduling across time zones; send availability for two weeks at once, as the handbook asks.

This guide covers GitLab's engineering loop; sales, support and other departments follow the same stage list with their own interview pages in the handbook. For management and leadership roles the loop is similar but the bar shifts to people, delivery and strategy, so pair it with the leadership interview prep hub. The bar for your exact role comes from the role-by-role guides, and the prep that actually transfers is spoken, so run a mock interview before the real one.

• 01GitLab handbook, technical interviews (updated 19 August 2026)the merge request format: a self-contained MR in a small app for the role from a curated bank, the link at least 72 hours ahead, up to an hour to review, complete 24 hours before with a note, the 90-minute call walking through the review and writing code to improve it, the three stated purposes, AI use encouraged, and the alternative-assignment note.
• 02GitLab handbook, candidate handbook pagethe stage list, the 30-to-40-minute screening call and its published example questions, offers set on market pay rather than pay history, team interviews as behavioural, panel and technical, the optional TMRG connection at the reference stage, and scheduling across time zones.
• 03GitLab handbook, valuesthe six CREDIT values as named.
• 04GitLab handbook, guide to all-remoteover 1,500 team members in more than 65 countries at the time of writing, and the remote manifesto.
• 05Levels.fyi, GitLab software engineerthe intermediate, senior and staff medians, read 22 September 2026.
• 06GitLab, second quarter fiscal 2027 resultsrevenue of $286.3 million, up 21 per cent, for the quarter ended 31 July 2026.
• 07GitLab, Form 8-K (11 May 2026)the reduction in force announced to realign the operating structure.
• 08Revelio Labs, GitLab headcountabout 2,700 employees as of March 2026.
• 09TechPrep, GitLab's interview process 2026the two or three behavioural interviews with the hiring manager and a director, the CREDIT-story advice, and the three-to-six-week timeline.

Interview processes change. This reflects widely-reported and sourced conditions as of 2026 — confirm specifics with your recruiter, and treat it as a map rather than a guarantee.