GitLab is one of the world's largest all-remote companies, with team members in more than 65 countries and a public handbook that documents how it works, including how it runs technical interviews. Engineering candidates usually meet a merge-request review exercise rather than a whiteboard puzzle. This page covers what GitLab builds and who it hires, the process candidates commonly report, the technical depth the teams care about, representative problem types, what interviewers score, and a three-week prep plan.
What GitLab builds and who it hires
GitLab's engineers build a single DevSecOps application: source control, merge requests, CI/CD, security scanning, package registries and GitLab Duo AI features. The main application is a Ruby on Rails monolith with a Vue.js front end and PostgreSQL, while performance-sensitive services such as Gitaly (Git storage), GitLab Runner and Workhorse are written in Go.
- Backend engineers: Ruby on Rails and PostgreSQL.
- Frontend engineers: Vue.js and JavaScript.
- Go engineers: Gitaly, Runner and other services.
- Site reliability and infrastructure engineers: GitLab.com and dedicated instances.
What the process tends to look like
| Stage | What happens | How to prepare |
|---|---|---|
| Screening call | A recruiter conversation about the role, location and compensation | Read the job family page and the handbook's hiring pages |
| Technical interview | A merge request to a small app built for the interview arrives at least 72 hours ahead; you review it asynchronously (the handbook suggests up to an hour) and finish 24 hours before a 90-minute video call where you walk through your review and write code to improve it | Review merge requests in the role's stack and write clear comments |
| Behavioral and hiring manager | Interviews on asynchronous work, ownership and results | Stories about written communication and remote work |
| Senior and leadership rounds | Candidates report a leadership interview, and system design for senior roles | One design in GitLab's domain, such as CI job scheduling |
Processes differ by team, level and office and change over time, so treat this as the common shape candidates report and confirm the specifics with your recruiter.
All-remote, handbook-first and the merge request
Asynchronous first. The handbook says the technical interview looks at how you communicate asynchronously as well as your knowledge of the technology and how you collaborate. Write review comments a teammate in another time zone could act on without a meeting: what is wrong, why it matters, and a suggested fix.
Handbook-driven. GitLab documents its processes publicly, so read the hiring pages, your team's engineering pages and the current values before you interview. In November 2026 the handbook's values page described three operating principles, Speed with Quality, Ownership Mindset and Customer Outcomes, built on a Culture of Excellence. Pages change often, so check the live version. Our guide on how to answer questions about working with remote teams helps with the behavioral side.
AI and change. The technical interview page says GitLab encourages AI use in its interview process and links to guidelines; follow them exactly. A handbook working group has also proposed redesigning the technical interview, so confirm the current format with your recruiter.
Representative problem types
These are the kinds of problems candidates describe, not a leaked question list. Practice the category, not the exact question.
- Review a merge request for a bug, a missing test and an N+1 database query.
- Improve a Rails controller or service object during the live call.
- Fix a Vue component that renders stale data.
- Write a Go function that streams a large file without loading it into memory.
- Design CI job scheduling across many runners.
- Add an index and a safe migration for a very large table.
- Explain a code change in writing for an asynchronous reviewer.
What interviewers score
- Working code: a solution that runs, handles edge cases and is readable by the next engineer.
- Practical judgment: the trade-offs you name and the simplest design that meets the requirement.
- Product sense: understanding who the user is and what failure looks like for them.
- Ownership: examples where you shipped, measured and fixed things yourself.
The behavioral side
Technical rounds decide most outcomes, but every GitLab loop also asks about how you work. Prepare a short story for each of these, with a result and what you learned:
- Something you shipped end to end. Cover the user problem, your decisions, what you measured and what you would change.
- A disagreement with a teammate. Show how you made the decision on evidence and kept the relationship.
- Why this company? Connect its product and engineering problems to the work you want to do next.
Structures and sample answers for the common questions are in our software engineer behavioral answers guide.
A three-week prep plan
- Week 1: refresh the stack for your role, whether Rails and PostgreSQL, Vue.js, or Go, using our Ruby on Rails interview questions or Go interview questions, and read GitLab's code review guidelines in the handbook.
- Week 2: review five real open-source merge requests in that stack. For each, write comments that name the problem, the reason and a fix, then make the fix yourself in under 30 minutes.
- Week 3: read the handbook pages on hiring, all-remote work and the current values, prepare written-communication stories, and rehearse walking someone through a review on a screen share.
For practice lists, use LeetCode company-tagged questions and the NeetCode 150 roadmap; for design rounds, read system design building blocks; and compare the practical style of Datadog.
Where CoPilot Interview fits
Most of a GitLab loop is spoken: you explain an approach, defend a trade-off and talk through your past work. CoPilot Interview is an AI interview assistant whose free AI mock interview builds technical and behavioral questions from your résumé and the job description, reads them aloud and scores each spoken answer out of ten, so you can rehearse the explanation as well as the code. The free plan gives 15 minutes a day of live help in sessions of up to 15 minutes, with AI mock interviews included. Online assessments and many coding rounds forbid outside help, so practice beforehand and follow your employer's rules on the day.
Disclosure: CoPilot Interview is our product, so weigh what we say about it accordingly.
Frequently asked questions
What programming language should I use in a GitLab interview?
Ruby on Rails for most backend roles, Vue.js for frontend roles, and Go for Gitaly, Runner and similar services. The merge request is tailored to the position, so it uses the role's stack.
Does GitLab send an online assessment?
Candidates rarely report a separate online assessment. The main technical step is the merge-request interview described in GitLab's public handbook.
How does GitLab's merge-request interview work?
According to the handbook, you receive a link to a self-contained merge request at least 72 hours before the call, review it asynchronously and finish at least 24 hours ahead, then spend 90 minutes on video walking the interviewers through your review and writing code to improve it.
How should I prepare for GitLab coding questions?
Practice reviewing merge requests in the role's stack and writing comments someone could act on without a meeting, then rehearse explaining your review on a video call and improving the code live. Read the handbook's hiring and values pages, because GitLab expects candidates to know how it works.
Can I use AI tools in a GitLab interview?
Only if the instructions you receive say so. Online assessments and live coding rounds generally forbid outside help, and some companies now state their AI policy in the invitation. Use AI to practice beforehand, and follow your employer's rules.
Practice this interview before the real one
The AI mock interview builds questions from your resume and the job description, reads them aloud and scores each spoken answer out of 10. Included on the free plan.
Start a mock interview