Editorial practice groupings, not verified official interview questions or endorsements.
Public GitLab prep guide
Prepare with five practice prompts shaped by GitLab handbook pages and by public frontend accounts from 2018 to 2025: a short written assessment, a recruiter screen, a merge request you review on your own time and improve live in a 90-minute session, then behavioral and director interviews.
The format is official, but the exercise details come from accounts, most of them reviews re-hosted on Taro, and GitLab now draws merge requests from a curated bank. Some candidates met a manager or director before the technical round and some roles closed mid-loop, so confirm the order and the exercise with your recruiter.
Study priorities
GitLab publishes the loop itself. After a short written assessment and a 30-minute recruiter screen, you receive a merge request on a small, self-contained application at least 72 hours before a 90-minute call, review it for up to an hour, and finish the review a day before. In the call you walk the interviewer through your comments and write code to improve the merge request. A 45-minute behavioral interview and a 60-minute interview with a Director of Engineering follow.
Public accounts describe the merge request as a small Vue app with an API call, data operations and conditional rendering, with Jest unit tests in one 2024 account, broken HTML and plain JavaScript to convert to Vue in a 2020 account, and a mobile layout to fix in another. What helped was a prioritized list of improvements the candidate could explain and then implement: correctness first, then repeated API calls, then layout and tests. GitLab welcomes transparent use of AI in technical assessments, as long as you can explain your prompts and decisions.
Reported interview process
GitLab publishes one frontend loop for every level: a short written assessment, a recruiter screening call, a merge request you review on your own time and then improve in a 90-minute technical interview, a behavioral interview and an interview with a Director of Engineering. Public accounts from 2018 to 2025 describe the same order.
Stages and durations come from the GitLab handbook; exercise details come from accounts dated 2018 to 2025. Sources last checked Oct 2026.
| Stage | What happens | Who | Evidence |
|---|---|---|---|
| Written assessment | A short written assessment after applying. Older accounts describe open-ended technical questions answered in writing, such as what happens in the browser while a page loads. Practice: How browsers parse and render | Selected applicants | Official page and 3 reports |
| Recruiter screening call | 30 to 40 minutes on video: background, motivation, experience with each listed skill, location, notice period and salary range. | All candidates | Official page and 2 reports |
| Merge request review | A self-contained merge request on a small application arrives at least 72 hours before the call; up to an hour of review, finished a day ahead. Reports name Vue, HTML, CSS, Haml and Jest unit tests. Practice: Fix an async race | Frontend engineers | Official page and 4 reports |
| Technical interview | 90 minutes on video with screen sharing: walk through your review, then write code to improve the merge request, with a frontend engineer or a frontend engineering manager. Practice: Build a spy function | Frontend engineers | Official page and 3 reports |
| Behavioral interview | 45 minutes with an engineering manager: STAR questions, sometimes with high-level technical questions. | All candidates | Official page and 3 reports |
| Director interview | 60 minutes with a Director of Engineering on past experience and values, with a few technical questions in some accounts. | All candidates | Official page and 2 reports |
| References and offer | Three references, at least one a past manager, and a background check before the offer. | Candidates who pass | Official page and 2 reports |
Full-stack candidates get two technical interviews, each on its own merge request.
| Stage | What happens | Who | Evidence |
|---|---|---|---|
| Recruiter screening call | About 30 minutes on motivation, experience with Ruby on Rails and Vue, and compensation. | All candidates | 3 public reports, 2020–2025 |
| Backend technical interview | 90 minutes on a merge request reviewed before the call and improved during it; Ruby, Rails, testing and database topics. | Full-stack engineers | 2 public reports, 2022–2025 |
| Frontend technical interview | 90 minutes on a second merge request that needs Vue, HTML and CSS changes; JavaScript, Vue.js and testing. | Full-stack engineers | 3 public reports, 2020–2025 |
| Manager and director interviews | About an hour each on behavioral and situational questions, values and how you work. | All candidates | 2 public reports, 2020–2025 |
Role lenses
These lenses come from GitLab job postings and its frontend development guide. Choose the one closest to the role and keep the reasoning framework-neutral.
The Senior and Staff frontend postings open in October 2026 sit on a team that owns core repository capabilities, from Git command-line operations to web-based code exploration, and the job family page asks for comfort with the GitLab code review process.
Practice focus: Rendering large diffs and file trees, review threads with optimistic updates, keyboard navigation, and performance budgets you can measure.
The Staff posting asks to lead modernization of a monolith or legacy frontend architecture toward modular, reusable and independently deployable systems, and the frontend guide describes a Rails and Haml app with Vue and GraphQL as the first choice for API calls.
Practice focus: Incremental migration plans, choosing between Apollo, Pinia and component state, GraphQL data loading, and tests that protect behaviour during a refactor.
Representative practice prompts
For each prompt, read the requirement first, comment by impact, implement the most important change in small steps, and test the failure cases. Each prompt links to the public report it is modelled on and to a practice page.
Prompt 1
You receive a merge request on a small Vue app that fetches a list, transforms it and renders it conditionally. Review it in about an hour, leave prioritized comments a day before the call, then walk through them and implement the most important fixes in a 90-minute session.
Practice version modelled on a reported round: Public report: Taro front end engineer loop with a 90-minute live session, 2024
Asynchronous communication in review comments, knowledge of Vue, HTML and CSS, and how you collaborate while changing code someone else wrote.
Common miss: Leaving a handful of vague comments, or spending the session on cosmetic changes while a repeated API call or a failing test stays in place.
Practise a Vue component with an API call (Premium)Prompt 2
The merge request calls the same endpoint every time a button is clicked. Explain the cost in a review comment, then change it so the data loads once and is reused, with loading and error states still correct.
Practice version modelled on a reported round: Public report: Taro front end engineer merge request round, 2024
Spotting redundant network work in review, choosing where data should load, and keeping UI states honest after the change.
Common miss: Caching the data but losing the error state, or fixing the click handler while leaving the same call in a watcher.
Fix an async race in a fetch helper (free)Prompt 3
The merge request has invalid HTML and a view that breaks on narrow screens. Correct the markup, use Flexbox and media queries so the layout matches a mobile mock, and justify each change in a comment.
Practice version modelled on a reported round: Public report: Taro frontend developer merge request round, 2020
Semantic HTML, CSS layout skill, and whether your review explains why each change matters to users.
Common miss: Patching the mobile view with fixed widths and absolute positioning, which breaks at the next screen size.
Practise a responsive Flexbox navbar (free)Prompt 4
The merge request changes how a component loads its data, and its unit test still passes. Write a test with a spy on the API call that fails on the bug and passes on the fix, then say what the test protects.
Practice version modelled on a reported round: Public report: Taro front end engineer loop with a 90-minute live session, 2024
Testing behaviour rather than implementation, using mocks and spies precisely, and explaining the value of a test in review.
Common miss: A test that only checks the component renders, which passes with or without the bug.
Build a spy function like Jest mocks (free)Prompt 5
In writing, describe what happens in the browser from typing a URL to a painted, interactive page, in as much detail as you think is useful, and name one performance risk at each step.
Practice version modelled on a reported round: Public report: Taro frontend engineer written questions, August 2019
Depth of browser knowledge and clear technical writing, which the asynchronous review round also depends on.
Common miss: A list of terms without the order of events, or an answer that stops at the DOM without reaching rendering.
Review how browsers parse and render HTML (free)Public mini walkthrough
The handbook suggests up to an hour of review, finished at least a day before the call.
Start from the issue or description: what should change for the user, and what would prove it works.
Pull the branch, start the app, run the tests, and note anything that fails before you read the code.
Bugs and broken requirements first, then performance such as repeated API calls, then accessibility and layout, then style.
Choose two or three fixes you can finish in the session and say why they come first.
Small commits, tests after each change, and a running explanation of the trade-offs.
Close with what you did not change and why, as you would hand it to the author.
Actionable preparation
Every day ends with code, a test, a written artifact, or a question you can use in the real process.
Read the GitLab code review guidelines and the technical interview page, then write a review checklist ordered by impact.
Deliverable: A one-page checklist you will use on the real merge request.
Vue fundamentals for the exercise: lifecycle hooks, computed values versus watchers, props and events, and where data loading belongs.
Deliverable: A small Vue component that loads data once and renders loading, error and empty states.
Review a deliberately flawed change, from an open-source project or your own old code, with prioritized written comments.
Deliverable: Ten review comments, each with a reason and a suggested change.
Implement your top review suggestions against a timer while narrating, then run the tests.
Deliverable: Notes from a 45-minute self-run session: what you finished and what you would leave for a follow-up.
HTML and CSS repair: fix invalid markup, then match a mobile mock with Flexbox and media queries.
Deliverable: A before-and-after page that holds at 360 pixels.
Unit tests: mock an API module, assert call counts and rendered output, and make a test fail before the fix.
Deliverable: Three tests that would catch the refetch bug.
Behavioral and director preparation: stories on iteration, a production bug, a disagreement and asynchronous collaboration; then write the browser page-load answer.
Deliverable: Five STAR stories and a one-page written answer.
Preparation FAQ
No. They are FrontendAtlas practice versions. GitLab says the merge request is self-contained and drawn from a curated bank of technical exercises, so yours will differ; the practice here follows the published format and what public accounts describe.
Public accounts from 2019 to 2024 describe Vue, HTML and CSS, with Haml in older ones and Jest unit tests in a 2024 account; one 2024 account says Vue 2. The job family page asks for experience with Vue or another modern JavaScript framework. Ask your recruiter which stack the exercise uses.
The GitLab guidelines say transparent use of AI is welcome in technical assessments if you can explain your prompts and technical decisions, that you should not read from AI-produced answers in interviews, and that you should disclose which tools you used.
Not in the published frontend loop or in the recent accounts. Two older senior accounts, from 2019 and 2021, describe an extra round of frontend theory questions such as CORS and optimizing a slow-loading list, and a 2019 account had a 10-minute linked-list exercise.
In October 2026 the two frontend-titled postings, Senior and Staff, are listed in Bangalore, India. GitLab says all its roles are remote with location-based eligibility for some, and its candidate page says it cannot proceed if you need visa sponsorship, unless you already hold a work permit in the Netherlands.
Free public practice
These public pages cover the request handling, layout, testing, document head, browser rendering and Vue lifecycle skills used by the practice prompts.
Public interview reports and official context
These links support the public context used by the guide. Their notes state what each source can and cannot establish about preparation.
Official page, last modified March 2026. It lists the six hiring steps with durations and interviewers, from the written assessment to the director interview, and the requirements, including Vue or another modern framework and automated tests.
Official page, last modified August 2026. It describes the merge request sent at least 72 hours ahead, the 90-minute call to walk through the review and improve the code, the curated bank of exercises and the encouragement to use AI.
Official page, last modified August 2026. It describes screening calls of 30 to 40 minutes, team interviews, three references with at least one past manager, the visa rule and the six-month wait before reapplying.
Official guidelines by stage: transparent AI use is welcome in technical assessments, interviews should not be read from AI-produced answers, and candidates should disclose the tools they used.
A re-hosted Glassdoor review with a placeholder date and no offer. It establishes a 30-minute recruiter call, a merge request done in Vue.js with unit tests in Jest, a 90-minute live session and feedback on JavaScript, CSS and Vue performance.
A re-hosted Glassdoor review with a placeholder date and no offer. It establishes the merge request sent two days ahead as a simple Vue 2 app with an API call, and the candidate caching data, cutting API calls and adding media queries.
A re-hosted Glassdoor review from 2020, when the exercise was a pull request in the GitLab codebase. It establishes broken HTML, plain JavaScript to convert to Vue, and unit tests and a CI pipeline that failed; the current exercise is self-contained.
A re-hosted Glassdoor review that ended after the written answers. It establishes one written question, what happens in the browser as it loads a page; the current written questions are not public.
A first-person full-stack account that ended in an offer, with interviews in early 2025. It establishes a 90-minute frontend technical interview on JavaScript, Vue.js, testing and frontend practice next to a separate backend one, and a 60-minute hiring manager round.
Official posting first published in September 2026. It places the role on a team that owns core repository capabilities and lists Vue, React, Angular, TypeScript or JavaScript as helpful; it says nothing about the interview.
Published by GitLab
GitLab publishes these pages itself. They describe the process and expectations in the company's own words; they do not list interview questions, and FrontendAtlas is not affiliated with GitLab.
| Page | What it covers | Checked |
|---|---|---|
| Frontend Engineer job family (GitLab handbook) | The six hiring steps for every frontend level: a short written assessment, a 30-minute screening call with a recruiter, a 90-minute technical interview with a frontend engineer or manager, a 45-minute behavioral interview, a 60-minute interview with a Director of Engineering, and the offer; plus the requirements, including Vue or another modern framework and automated tests. | Oct 2026 |
| Technical interviews (GitLab handbook) | The merge request format: a self-contained merge request on a small application sent at least 72 hours before the call, up to an hour of review finished a day ahead, then a 90-minute video call to walk through the review and write code to improve it; exercises come from a curated bank, and AI use is encouraged. | Oct 2026 |
| Candidate handbook page (GitLab handbook) | The stages for all roles, screening calls of 30 to 40 minutes and the questions recruiters ask, team interviews that can be behavioral, panel or technical, three references with at least one past manager, the visa rule and the waiting period before reapplying. | Oct 2026 |
| Using AI in the interview process | What GitLab expects by stage: transparent AI use in technical assessments with prompts and decisions you can explain, no reading from AI-produced answers in interviews, cited AI research in take-home answers, and disclosure of the tools used. | Oct 2026 |
Full company practice
This public guide is complete enough to plan a focused week. Premium unlocks the Vue debounced search component and the wider premium library for the Vue, testing and code review skills the loop relies on.