# What the Sourcegraph engineering interview actually tests

Source: https://www.techinterview.org/post/3233476857/what-the-sourcegraph-engineering-interview-tests/
Updated: 2026-07-26 · techinterview.org

The first thing to get straight in 2026 is which company actually sent you the recruiter note. Sourcegraph and Amp were one org until late 2025, when they split. Sourcegraph, now led by Dan Adler, kept the code-search and code-intelligence platform along with Cody Enterprise. Amp, the agentic coding tool, became its own company under Quinn Slack and Beyang Liu. The loops diverge from there, and plenty of candidates prep for the wrong one because nearly every write-up published before the split treats them as a single company.

This is about the Sourcegraph side, the enterprise code-intelligence platform. If you're talking to Amp, the coding-agent questions and the eval-heavy product rounds are a different animal, and you should ask your recruiter which codebase you'd be working in before you spend a weekend prepping the wrong material.

## The shape of the loop

Sourcegraph runs a fairly standard-looking loop with two twists. The technical bar leans on reading code rather than sprinting through algorithm puzzles, and there's a writing sample buried inside the behavioral round whether or not anyone labels it that way. The company built its reputation on a public handbook and an async, writing-first culture, so how you argue in prose gets weighed alongside how you write Go.

| Interview round | Typical format and length | What the interviewer is checking |
| --- | --- | --- |
| Recruiter screen | Around 30 minutes, phone | Motivation, async and remote fit, comp expectations, which team and product |
| Technical phone screen | Around 60 minutes, one coding problem | Idiomatic Go or TypeScript, clean error handling, code a reviewer can follow |
| Take-home or second coding round | 4 to 6 hour take-home for senior and up, or live pairing | A working solution plus a clear written design note |
| Code-intelligence design | Around 60 minutes, discussion | Search indexing, code navigation at scale, incremental indexing tradeoffs |
| Product and craft round | 45 to 60 minutes | Real, critical opinions on AI coding tools and developer experience |
| Values and behavioral | 45 to 60 minutes | Driving decisions through writing, async collaboration, disagreement handled in an RFC |

Timings move around by level and team. Senior and staff candidates usually get a take-home or a longer design conversation in place of a second live coding round. New-grad and junior loops skew toward a classic data-structures screen.

## The code-intelligence questions they actually like

Sourcegraph's whole product is answering questions about code at scale, so the interesting technical rounds circle back to that domain. A common opener: walk me through what happens between the moment you type a symbol into code search and the moment results render. A strong answer touches the index, the query planner, ranking, and streaming partial results back to the browser before the full scan finishes.

The search internals matter. Sourcegraph's search backend, Zoekt, builds a trigram index. It breaks every file into overlapping three-character sequences and records which documents contain each one. When you search for a literal or a regex, it intersects trigram posting lists to skip files that can't possibly match, then runs the real regex only on the survivors. If an interviewer asks why trigrams instead of a suffix array or a plain word-based inverted index, they want you to reason about the tradeoff: trigrams handle substring and regex queries over code, where there are no clean word boundaries, at the cost of a larger index and some false-positive candidates you still have to verify.

Code navigation is the other half. Go-to-definition and find-references across a ten-million-line repository don't spin up a language server on demand; they read a precomputed index. Sourcegraph moved from LSIF to SCIP, its own protocol, for exactly this. Expect questions about incremental indexing. How do you avoid re-indexing an entire monorepo on every push when one file changed, and how do you keep results correct while an index is half-updated? Talking sensibly about commit-level granularity, dependency graphs, and serving results that are stale but clearly labeled while a fresh index builds will get you further than naming any specific tool.

A few problems phrased close to how they come up:

- Design incremental code indexing for a monorepo that takes thousands of commits a day.

- Rank which files to feed a model as context for a question about an unfamiliar repository.

- Given a parsed AST, resolve a symbol to its definition across file boundaries.

- Make regex search over a billion lines return its first results in under a second.

## Go, and why they read your error handling

The backend is Go, the web frontend TypeScript and React. Coding rounds usually let you pick your language, but the backend teams want idiomatic Go: context propagation through the call stack, channels used deliberately rather than as decoration, graceful shutdown, and error wrapping a reviewer can trace back to the source. A working solution that swallows errors and leaks a goroutine scores worse than a slightly slower one a teammate could read and trust. One recurring live exercise hands you a small service that leaks goroutines under load and asks you to find and fix it, which is really a check on whether you understand cancellation and the lifecycle of a worker.

Keep it plain. Don't over-abstract a twenty-line problem into three interfaces and a factory. They review a large volume of pull requests every week, and they can tell who writes for the reviewer and who writes for themselves.

## The product round wants your real opinions on AI tooling

Somewhere in the loop, usually the product or craft round, you'll get asked what you make of the current crop of AI coding tools: Cody, Copilot, Cursor, and the agent wave including the Amp product that just left the building. This is not small talk. Sourcegraph builds developer tools for a living and wants engineers who use them with a skeptical eye. Come in with a specific take. A task where an agent saved you an hour, and a case where it invented an API that doesn't exist and cost you two. Naming the failure modes reads as far more credible than enthusiasm.

## The writing test hiding in the behavioral round

Because so much of the company's coordination happens in documents and issue threads, the values round probes whether you can operate without a manager tapping you on the shoulder. Questions run toward specifics: describe a technical decision you drove through writing rather than a meeting, or a time you disagreed with a design in an RFC and what you actually wrote. A vague "we collaborated closely" answer lands flat. They want a concrete example where your written argument changed an outcome.

If there's a take-home, the write-up counts as much as the diff. A short, clear design note explaining what you chose and what you deliberately left out will do more for you than one more feature. Treat the README as part of the submission.

## Remote work and the comp question after the split

Sourcegraph grew up remote-first, and its hiring materials still lean that way, but location policies across the industry have moved a lot since 2023. Ask your recruiter whether the specific role is remote, hybrid, or tied to a hub, and get the answer in writing before you fall for the job description.

Comp is where the post-split situation gets real. Sourcegraph is private, so an offer is base plus equity in a business that just reorganized its cap table. The cash tends to be competitive for a mid-size infrastructure company and generally sits below the top of the FAANG band; the equity is the part that needs thought. Ask for the strike price, the current 409A valuation, the vesting schedule, and how the split affected any existing grants. Check [levels.fyi](https://www.levels.fyi/companies/sourcegraph/salaries/software-engineer) for recent data points rather than trusting a single figure, since private-company numbers move and public ranges lag reality. For a sense of the business behind the offer, Cody Enterprise sells at around 59 dollars per user per month, which tells you the money comes from large orgs paying per seat, not individual developers.

## How to prep without burning two weeks

Skip the grind-500-problems plan; it's a poor match for this loop. Spend an evening in Sourcegraph's public handbook and a couple of their engineering posts on search and code intelligence so you can hold a real conversation about trigram indexing, SCIP, and ranking. Write a small tool that greps a codebase and does something mildly clever with the results, so the code-search framing feels natural in your hands. Form an opinion, backed by actual use, on where AI coding tools help and where they produce confident nonsense. And prepare one story about a call you won on the strength of a document, because that round is coming and a rehearsed-sounding answer won't carry it.

The people who clear this loop tend to share one habit. Hand them a messy question about understanding code at scale and they reason out loud, name the tradeoff they're making, and leave behind a paragraph clear enough that a teammate three time zones away can act on it without a follow-up call. That is the actual job, and the interview is built to find it.