GitLab · Primly Community

GitLab machine learning engineer interview: not what I expected, in a good way

ml_mike · 6 replies

Did the GitLab MLE interview loop last quarter. Sharing because MLE interview reports for non-FAANG companies are scarce and I had to piece this together from old threads.

Quick context: I was interviewing for a role on their AI/ML team that works on features like code suggestions (think Copilot for GitLab). Coming from a recsys background so this was a slight pivot.

The loop

Phone screen with a data scientist on the team: 45 min. Background questions, then a medium-difficulty algorithm question (nothing ML-specific, just LeetCode-style). I think they were checking baseline coding ability.

Technical screen with an ML engineer: 60 min. Two parts. First: review a short Python snippet with some bugs and inefficiencies, explain what's wrong and fix it. Second: design a simple ranking model from scratch for a hypothetical feature. We talked about training data, features, loss functions, evaluation metrics. No GPT magic needed, just solid ML fundamentals.

Onsite: 4 rounds.

Round 1: ML system design. Design a code completion suggestion system. This is obviously in their product. You need to think about latency (inference needs to be fast or developers hate it), model size tradeoffs, how to handle context windows, and how you'd evaluate quality (BLEU is bad for code, so what else). I mentioned user feedback signals and they seemed interested.

Round 2: Coding. Two problems. One data structure question, one more ML-flavored: implement a simple precision/recall calculator and explain when you'd prioritize one over the other.

Round 3: Behavioral/values. Used STAR for everything. They asked about iterating quickly on a model that wasn't performing and about disagreeing with a PM over a feature direction. GitLab's iteration value shows up here.

Round 4: Hiring manager. More of a chat. He asked what I found most interesting about ML for dev tools specifically.

Overall

The technical bar felt like 'solid senior IC,' not bleeding-edge researcher. They're building product features, not publishing papers. If you can design pragmatic ML systems, debug Python confidently, and think about product context, you're in range.

Comp: L5 equivalent, US remote, roughly $190k base. Equity refreshes annually.

6 replies

ds_dmitri

The BLEU-is-bad-for-code point is sharp. Did they want you to propose an alternative metric or just acknowledge the problem?

ml_mike

Both. I mentioned pass@k (from the Codex eval work) and test-pass rate as more meaningful metrics. They seemed happy with that direction. Shows you're thinking about what actually matters for developer experience.

corp_refugee

The 'building product features not publishing papers' framing is the real differentiator between applied MLE roles and research roles. If you come from a research background and haven't shipped production ML, you need to close that gap before this loop.

infra_ines

Latency in code suggestion is genuinely hard. Did they get into specifics like model quantization or serving infra, or stay at the design pattern level?

ml_mike

Design pattern level mostly. I mentioned quantization and they acknowledged it but we didn't go deep. The focus was on the system design: caching, streaming responses, context management.

market_realist

190k base for L5 remote is pretty solid for a non-FAANG, especially in this market. Did you negotiate or was that first offer?