Glean interview notes, page 3 of 3

Mid-sized

Most of these Glean write-ups come from Software Engineers (15), then Machine Learning Engineers (7) and Data Scientists (4). The most reported rounds are the technical phone screen (23), the system design round (2), the behavioral / leadership round (1) and the take-home assignment (1).

27 interview notes · updated Jul 2026

Glean·Software Engineer·Technical Phone Screen

Jun 2026

Glean coding round, one question the whole time, and it was one of those problems that looks manageable until you actually have to implement it cleanly under pressure. The scheduling logic wasn't hard to reason about but the implementation details piled up fast.

Build a priority-based job scheduler that processes a stream of jobs with arrival times, durations, and priorities. The processor runs jobs to completion without preemption, picking the highest-priority available job at each step. Ties go to the job that arrived earliest. Return each job's start time, finish time, and wait time.

“I knew I needed a min-heap and figured out the key ordering pretty quickly (-priority, arrival_time).”

View Post

Glean·Software Engineer·Technical Phone Screen

Jul 2026

Glean SWE interview with a simulation-heavy coding problem. Two-part question that starts reasonable and then gets extended mid-interview, which I was not expecting.

You have m parallel indexers and a stream of documents, each with an arrival time and a processing duration. Each document has a preferred indexer based on its index mod m. If that indexer is busy, scan forward (wrapping around) and assign to the first available one. If none are free, drop the document. Implement this simulation and return the total documents processed and the indexer that handled the most.
Extend the simulation to find the top k indexers by documents processed, and compute what percentage of all documents (including dropped ones) those k indexers handled.

“The base assignment logic is fine, just modular arithmetic.”

View Post

Glean·Software Engineer·Technical Phone Screen

Jul 2026

Glean software engineering interview that leaned heavily on open-ended test design. The main question was a big ambiguous one about testing a leaf-counting system, which sounds quirky but is actually a pretty serious exercise in how you structure a testing strategy from scratch.

How would you design a testing strategy for a black-box system that takes a tree image or scan as input and outputs a leaf count? Walk through how you'd scope it, what test categories you'd use, how you'd define correctness, and what edge cases or non-functional properties you'd cover.
How would you build a ground-truth dataset at scale when no human can realistically count every leaf on a large tree?
The system is ML-based and gets retrained periodically. How do you build an automated regression suite that catches accuracy drops without producing false alarms every time the model updates?
How would you test that two nearly identical photos of the same tree produce similar leaf counts, and what would you do if they don't?
If the spec only guarantees accuracy within plus or minus ten percent, how do you design pass/fail criteria that are meaningful without being flaky?

“This one took me a minute to even figure out where to start.”

View Post

Glean·Software Engineer·Technical Phone Screen

Jul 2026

Interviewed for a software engineer role at Glean and got hit with a BPE tokenizer implementation question. It's the kind of problem that looks like a coding exercise on the surface but really tests whether you understand how modern NLP tooling actually works under the hood. Took me a while to wrap my head around the non-overlapping pair counting logic.

Implement a Byte Pair Encoding tokenizer class with train, encode, and decode methods. The train method should learn merge rules from a string by repeatedly merging the most frequent adjacent token pair above a given threshold, using lexicographic order to break ties. Encode applies those learned rules in order, and decode reconstructs the original string from token ids.

“This one genuinely surprised me.”

View Post

Glean·Machine Learning Engineer·Technical Phone Screen

Jul 2026

Interviewed for an MLE role at Glean and got a graph/search problem dressed up as a train scheduling puzzle. Took me a minute to see it wasn't just a simple BFS on a static graph because time actually matters here. Decent problem, probably mid-to-hard difficulty.

Given a train schedule where each route is a list of stations indexed by absolute time, write a function to determine if a passenger starting at a given station at time 0 can reach a destination station.
How would you model the state space for this train reachability problem, specifically accounting for waiting at stations?
What is the time complexity of your solution, and what edge cases would you need to handle?
How would you modify the solution to return the actual path taken, not just a boolean?
What changes if trains have arbitrary timestamps instead of route-index-based time?

“The core trap I nearly fell into was treating this like an undirected graph problem.”

View Post

Glean·Data Scientist·Technical Phone Screen

Jul 2026

Glean data scientist interview with a pretty gnarly metric integrity problem. The whole thing centered on MAU calculation breaking down when user IDs get remapped mid-window, which is not the kind of thing you think about until it bites you in production.

If a company rehashes all user IDs on a single day T, and your MAU window spans dates both before and after T, how does naively counting distinct user IDs distort the metric?
What is the maximum possible MAU overestimate as a percentage, and what is the minimum, relative to the true distinct user count over the window?
How would you redesign the tracking system or warehouse modeling so that MAU stays accurate even when user IDs change like this?

“This took me a second to visualize.”

View Post

Glean·Software Engineer·Technical Phone Screen

Jul 2026

Coding round at Glean for a software engineer role. The main problem was implementing the movement logic for 2048, which sounds straightforward until you actually have to get the merge semantics right under interview pressure.

Implement the core move logic for a 2048 board. Given an n x n grid, write a method that slides and merges tiles in a given direction (up, down, left, right) according to standard 2048 rules.
Follow-up: implement an isGameOver() check that returns true when no legal move remains, without necessarily simulating all four full moves.
How would you signal to the caller that the board actually changed after a move, so the game knows when to spawn a new tile?
How would you unit test the movement logic? What invariants always hold across any valid move?

“I started by trying to write separate logic for all four directions and immediately saw how messy that gets.”

View Post