# What Glean’s engineering interview actually tests

Source: https://www.techinterview.org/post/3233476794/glean-engineering-interview/
Updated: 2026-07-20 · techinterview.org

The part of Glean's loop that catches people off guard is the practical coding assignment. It's not a whiteboard exercise or a timed array sprint. You get roughly two hours to build something that actually runs, and the interviewers care about how much working code you produce and whether it hangs together. Candidates who spent all their prep grinding puzzle problems tend to freeze here, because the skill being measured is different: can you scaffold a small system, make reasonable calls fast, and leave it in a state a teammate could read.

Glean sells enterprise search and an AI assistant that sits on top of a company's own data, so its engineering interview tilts toward retrieval, ranking, and the messy reality of permissions. Once you understand what the product has to do, most of the questions stop feeling random.

## What Glean actually builds, and why the interview reflects it

Glean indexes a company's documents, messages, tickets, and code across connectors to apps like Google Drive, Slack, Confluence, Jira, GitHub, and Salesforce, then answers questions over that corpus. Two constraints shape almost everything. The index has to stay reasonably fresh across a hundred-plus source systems, and every result has to respect the permissions of the person asking. If you can see a document in Drive and your coworker can't, Glean has to enforce that at query time, per user, without leaking so much as a title or a snippet.

That one requirement, permission-aware retrieval at scale, is why the system design round keeps circling back to access control. It's the hard part of the product, and it's the part interviewers can tell whether you've thought about.

## The round structure

The loop is fast by big-company standards, usually three to five weeks start to finish. It opens with a recruiter call, then a hiring manager screen that runs about forty-five minutes on your past projects, why Glean, and whether the role fits. A technical phone screen follows: sixty minutes, mostly coding, with a short design conversation attached. Clear those and you get the virtual onsite, four or five rounds in a single block that can run four to five hours.

| Interview round | Format and length | What Glean is really testing |
| --- | --- | --- |
| Recruiter screen | Phone, ~30 min | Background, motivation, level and comp fit |
| Hiring manager screen | Video, ~45 min | Past projects, ownership, why Glean specifically |
| Technical phone screen | Video, ~60 min | One coding problem plus a short design discussion |
| Onsite coding (two rounds) | Video, ~45 min each | Medium-level problem solving, clean code, stated complexity |
| Onsite system design | Video, ~60 min | Search and retrieval architecture, permission-aware ranking |
| Practical build assignment | Hands-on, ~2 hours | Shipping a large amount of working code under time pressure |
| ML / RAG round (ML track) | Video, ~60 min | RAG pipeline design and how you evaluate retrieval quality |
| Behavioral | Video, ~45 min | Collaboration, handling ambiguity, working across a team |

## The coding rounds, and what "medium" hides

The algorithmic rounds sit in LeetCode-medium territory, with a hard or two showing up for senior candidates. Nothing exotic. Expect graph traversal, hashing, interval work, string parsing, the usual families. What separates a pass from a fail is rarely whether you find the optimal solution. It's whether you state your time and space complexity without being asked, catch your own edge cases, and write code someone could actually merge.

A few shapes that come up:

- Parse and evaluate a nested structure, such as a mini expression grammar, a config format, or a query filter.

- Deduplicate or merge ranked lists, which maps directly to combining results from several search backends.

- Group or bucket items under a constraint, the kind of thing that becomes a real feature two weeks into the job.

Talk through the tradeoff before you type. If you reach for a heap, say why a heap and not a sort. The interviewers are reading your judgment as much as your syntax.

## The system design round is a search problem in disguise

Ask three Glean candidates about their design round and at least two will describe some version of "design a search system over a company's documents." The prompt sounds open-ended, then narrows toward the parts Glean lives in every day.

Strong answers start by splitting indexing from serving. On the indexing side you're crawling connectors, normalizing wildly different document types, chunking text, and building both a lexical index and vector embeddings, because production search at this scale is hybrid: BM25-style keyword matching catches exact terms and names, semantic vectors catch meaning. A ranking layer reconciles the two. On the serving side, a query fans out to those indexes, candidates get merged and reranked, and permissions get applied.

Where do you enforce access control? That's the question they push on. Filtering after ranking is simple and wrong at scale, because you can rank a thousand documents and throw away nine hundred the user can't see, wasting the work and sometimes returning a near-empty page. Filtering during retrieval is faster but forces you to keep an access-control representation inside or beside the index, which then has to update the moment someone's permissions change. Neither is free. Being able to name that tension, and pick a side with a reason, is most of the round.

Freshness is the other lever. A document edited in Drive should surface in results within minutes, not on the next daily crawl, so you'll want to reason about change events versus full recrawls, and what happens when a connector goes down for six hours and comes back with a backlog to replay.

## The ML and RAG round, if you're on that track

Applied ML and AI-engineering candidates get an extra round centered on retrieval-augmented generation, since that's the engine behind Glean's assistant. This is not a research interview. Nobody's asking you to derive attention from scratch. They want to know whether you can make a RAG pipeline work and, more to the point, whether you can tell when it's failing and why.

Good ground to have ready: chunking strategy and why chunk size trades recall against precision, when to rerank retrieved passages before handing them to the model, how you would measure retrieval quality separately from generation quality, and how you keep a model from confidently answering out of documents the user was never allowed to see. That last one ties straight back to the permissions theme, which is not an accident.

If you can describe evaluating a RAG system with something better than vibes, offline retrieval metrics, a labeled question set, human review of a sample, you'll stand out, because most candidates wave their hands at the eval and move on.

## The practical assignment, and how to not blow it

Back to the assignment, since it's the round people underprepare for. You get a scoped problem and a couple of hours to build a working solution, sometimes a small service, sometimes a data-processing task with a real interface. The bar is a lot of functioning code, not a pristine fraction of one.

Candidates who do well pick an architecture in the first ten minutes and commit. They write the simplest thing that runs end to end, then improve it, rather than polishing one perfect component while the rest stays empty. They drop a comment or two on the decisions they would revisit with more time. Get something working early and keep it working. A half-built elegant abstraction reads worse here than a plain solution that handles the input.

## Compensation and how to read the offer

Glean is a late-stage private company that has raised at a multibillion-dollar valuation, most recently in the several-billion range during 2025, so offers pair a competitive base with equity that is still private-company stock. That distinction matters more than the headline number. Public-company RSUs you can value and sell on a schedule; Glean's equity is worth whatever the next liquidity event says it's worth, which could be a strong IPO or could be a longer wait. Ask about the current preferred price, the strike if you're getting options, and the vesting schedule, then weight the equity accordingly instead of treating the paper figure as cash. Bands move with the market, so check a current source like Levels.fyi against your specific level before you anchor on anything.

## How to spend your prep time

With two weeks, put the bulk of it on system design for search and retrieval, because that's where Glean is most distinctive and where generic big-tech prep helps least. Be able to sketch a hybrid index, defend where you enforce permissions, and reason about freshness. Keep your medium-level coding sharp so it isn't the thing that trips you, and do at least one timed build so the practical assignment isn't the first time you've shipped working code against a clock. For the ML track, get concrete about RAG evaluation. The through-line across every round is the same: Glean is a search company wearing an AI-assistant coat, and the interview rewards people who can reason about getting the right document to the right person, fast, without surfacing something they were never allowed to see.