Platform Engineer Interview Experience at GitLab – 2026

A recruiter screen focused specifically on comfort with fully remote, asynchronous-first work, since GitLab operates that way by design rather than as an exception. Recruiters ask candidates to describe their current team's actual communication cadence - how much relies on synchronous meetings versus written async updates - and push on vague answers, asking for a specific example of a decision made or influenced purely through written communication with no live meeting involved.

Candidates are given a real, deliberately imperfect pull request 72 hours in advance and asked to leave written review comments before the live round, matching GitLab's reported assessment format exactly. A typical PR modifies a CI pipeline configuration to add a new deployment stage; a strong review flags that the new stage has no explicit timeout, meaning a hung deployment step could block the entire pipeline indefinitely, and separately notes that a hardcoded environment name should be parameterized to avoid duplicating the stage per environment instead of templating it. A thorough reviewer also questions whether the new stage's failure should block the pipeline entirely or only warn, given its stated purpose is non-critical smoke testing.

A live discussion of the submitted PR review, where the interviewer asks the candidate to defend and elaborate on each comment rather than just restating them. On the timeout comment specifically, candidates are asked to propose an actual fix - live-editing the pipeline YAML to add an explicit `timeout` value at the job level, explaining the tradeoff of setting it too short (false failures on a slow but healthy deployment) versus too long (the exact hang risk flagged earlier). The interviewer then introduces a new scenario not in the original PR: what if this deployment stage needed to run across multiple regions in parallel rather than sequentially - the expected response refactors the job definition live using a matrix strategy to fan out the same job across a list of region variables.

A values-fit round covering how a candidate handles disagreement in a code review, expected to be answered with a specific past example rather than a hypothetical - describing a merge request where the candidate disagreed with a reviewer's requested change, and how they responded in writing, laying out their reasoning and proposing a middle-ground alternative rather than either capitulating immediately or pushing back purely on authority. The interviewer specifically references language from GitLab's own handbook about direct, kind communication and asks how the candidate's example reflects or diverges from that principle.

A second, separate hiring-manager round with a noticeably different style from the first, consistent with what other candidates report about interviewer-to-interviewer variation at GitLab. This round tends to focus less on structured STAR stories and more on open-ended discussion of how a candidate would prioritize platform reliability work in a fully async team where a blocking question might not get answered same-day. A strong answer proposes defaulting to a documented, reversible decision made independently rather than waiting on synchronous approval for anything not genuinely high-risk, since waiting idle for an answer is itself a cost in an async-first environment.