GitLab's AI Interview Policy: What's Allowed at Each Stage

Most companies leave candidates guessing about AI. GitLab wrote the rules down, stage by stage, and then published a working group page admitting its own technical interview is aging badly. That makes it one of the few places where you can plan from primary sources instead of forum rumors.

Source note: everything below comes from GitLab's own pages, namely "Using AI in the interview process" on about.gitlab.com, and the Candidate Handbook, Technical Interviews and AI-Native Hiring Working Group pages on handbook.gitlab.com (read October 2026). Those pages don't describe your specific loop, so confirm details with your recruiter.

The Rules, Stage by Stage

GitLab's page doesn't give one yes-or-no answer. It gives four, one per stage.

• Application materials. You may use AI for your résumé or cover letter, but the information must accurately represent your qualifications and skills.
• Take-home assignments. You're welcome to research with AI, but you must cite it and give answers in your own words, "reflecting your original synthesis and perspective."
• Technical assessments. The wording is "similar to how you'd work at GitLab, transparent use of AI is welcome," with the expectation that you can explain your prompts and technical decisions and don't present AI-produced content as your own.
• Interviews. "Please engage without reading from AI-produced answers." GitLab says it wants your interpersonal skills and authentic perspective.

Then comes the part that's easy to skim past: a short list of what GitLab expects from you. Disclose when you've used AI and which tools you used. Be prepared to discuss how you collaborate with it. And "misrepresentation of skills or qualifications may result in disqualification."

So the policy isn't really "AI yes or no". It's "AI yes, hidden AI no". The line sits at disclosure and at whether the words coming out of your mouth are yours.

What GitLab Says It Does With AI

The same page covers the employer side. GitLab says it does not use AI for decision making in hiring and that decisions are made by human team members. It lists where it does use AI: drafting job descriptions and interview questions (reviewed by hiring teams), drafting sourcing messages that recruiters personalize, analyzing recruitment metrics, and, with appropriate consent, summarizing interview feedback.

The Technical Interview: A Merge Request, Not a Whiteboard

For some roles, the Technical Interviews page describes a format that is unusual in 2026:

1. You get a merge request at least 72 hours before the call. It targets a small application built for the interview and tailored to the role. It's self-contained, so you shouldn't need to hunt for context.
2. You review it like a real contribution. GitLab encourages up to an hour. Finish at least 24 hours before the call and leave a note saying you're done.
3. The call is 90 minutes of video and screen share. The interviewer asks you to walk through your review, and you also write some code to improve the merge request.

The stated purpose is to see how you communicate asynchronously, what you know about the technology and how well you collaborate with a team member. The page also says the interview no longer uses live or "real" issues, and that it draws from a curated bank of exercises.

And the page has one line on AI: "We encourage the use of AI in the interview process," pointing to the guidelines above.

The Part Worth Reading: A Working Group Admits the Exercise Is Dated

GitLab's handbook also hosts an AI-Native Hiring Working Group page (status "Proposed", started 2026-04-04, target end 2026-05-15). Its problem statement is blunt: the current merge-request review exercise has candidates spot issues, comment on violations and implement fixes, but "AI coding assistants can now surface 90–99% of common code issues." That means the process "primarily measures skills that AI has commoditised."

What it proposes instead, as a starting point to be piloted rather than a confirmed process:

• An async merge-request assessment before the interview, keeping GitLab's strongest signal (written communication in an MR) while assuming AI use.
• A synchronous design-and-implementation session of about an hour. You'd use GitLab's own Duo assistant to design and iterate on a greenfield problem while thinking aloud.
• A synchronous codebase-navigation session of about an hour. You'd implement a feature in an existing codebase, using Duo to explore and plan.

Its guiding principles tell you what would be scored: design judgment, clear communication of intent, iterative problem-solving, code comprehension, validation discipline and awareness of AI limitations. It also says candidates would get temporary Duo access so nobody is judged on their personal tool setup, that it doesn't want to use time pressure as a deliberate evaluation tool, and that it wants to see "AI as amplifier, not crutch."

Treat this as direction, not schedule. The page is marked Proposed, and I could not find a published outcome. Interview with the format your recruiter actually describes.

How to Prepare

What follows is based on those pages plus our own suggestions, which are marked.

For the async merge-request review (current format):

• Read the whole diff first, then comment. Written comments are what's being evaluated, so make them specific, kind and actionable.
• If you use AI to help spot issues, check each claim yourself and note in your comments where you used a tool. The disclosure expectation applies.
• Leave the completion note on time. It's a small thing GitLab explicitly asks for.

For the live call:

• Be ready to defend every comment you left, in your own words. A review you can't explain out loud is the failure mode the "don't read AI-produced answers" rule is aimed at.
• Don't read from a second screen. Whether or not a tool could catch it, GitLab has told you what it wants, and the downside it names is disqualification.

For an AI-native format, if you're offered one:

• Think aloud while you direct the tool. The proposal says the interviewer watches how you direct the AI and how you evaluate its output.
• Our suggestion: practice 60-minute sessions where you must build a small service from scratch, then explain every decision. A mock interview round is a decent way to rehearse the explaining part, because that's where leaning too hard on a tool shows.

GitLab sits at the transparent-use end of the spectrum. Other companies split differently: see Canva's AI-assisted coding interview, Datadog's published AI guidelines and OpenAI's policy, or the side-by-side in which companies allow AI in coding interviews.

FAQ

Does GitLab allow AI in interviews?

Yes, with conditions by stage. AI is welcome for résumés, take-home research (cited, in your own words) and technical assessments (transparent, with you explaining your prompts). In live interviews, don't read from AI-produced answers.

Do I have to tell GitLab I used AI?

Yes. The page asks you to disclose when you've used AI and which tools, and warns that misrepresentation can lead to disqualification.

What is GitLab's technical interview?

For some roles, a self-contained merge request you review asynchronously (link sent at least 72 hours ahead, finish 24 hours before), followed by a 90-minute video call where you walk through your review and write code.

Is GitLab changing its technical interview because of AI?

A public working group proposes it. The page is marked Proposed and says the current exercise mostly measures skills AI has commoditised. I found no published final decision.

Does GitLab use AI to make hiring decisions?

Its page says no. AI may help draft job descriptions, questions and outreach, and with consent summarize feedback, but humans decide.

How many interviews does GitLab have?

The Candidate Handbook lists application, screening call, an assessment and a technical interview for certain roles, team interviews, references, and offer. What applies to you depends on the role.

---

Author · Alex Chen. Career consultant and former tech recruiter. Spent 5 years on the hiring side before switching to help candidates instead. Writes about real interview dynamics, not textbook advice.