Hebbia will not sit you down and ask you to reverse a linked list. The company was founded on the argument that the copy-paste retrieval-augmented generation everyone lifted from 2023 tutorials falls apart on hard questions, and the interview loop is built to find people who can defend that claim with evidence rather than vibes. Show up ready to recite the textbook RAG pipeline and you will have a bad afternoon.
George Sivulka started Hebbia in 2020 while partway through a PhD in electrical engineering at Stanford. The early pitch was document search for finance. What the company became is stranger and more interesting: Matrix, a spreadsheet-shaped surface where each cell can run an agent across thousands of pages, plus an in-house retrieval system the team built after deciding that vector search stapled to a prompt missed the answer on most of the questions their users cared about. a16z led a $130M Series B in 2024, with Index Ventures, Google Ventures, and Peter Thiel also in the round. The buyers are asset managers, banks, and law firms, the kind of customers who notice immediately when a citation points to the wrong paragraph.
Why the product decides what they ask
Most AI startups interview like generic web-app shops with an ML question bolted on. Hebbia does not, because its whole reason to exist is a contrarian bet on retrieval. Their public writing lays it out plainly: they shipped a production RAG system early, watched it fail on a large share of real user queries, and rebuilt information retrieval from scratch around fanning a question out across many documents instead of grabbing the top few chunks. If you understand that thesis, the interview reads as one long probe: can this person reason about why retrieval fails on a 300-page credit agreement, and can they measure whether a fix actually worked?
That framing matters for prep. You are not being tested on whether you can call an embedding API. You are being tested on judgment about messy, high-stakes documents where a wrong answer costs a client real money, and where there is rarely a clean labeled dataset to grade against.
The rounds you’ll see
Public detail on Hebbia’s loop is thin, so treat the shape below as a representative walkthrough rather than a fixed script. It varies by role and by how senior you are, and the company has changed fast as it grew past a hundred people. What stays constant is a bias toward practical problems over trivia and at least one conversation with a founder or senior leader that is really about intensity and fit.
| Interview stage | Who typically runs it | What it is really testing | Usual format |
|---|---|---|---|
| Recruiter screen | Talent team | Motivation, background, comp expectations, why Hebbia over a lab | 20 to 30 minute call |
| Technical phone screen | Engineer | Coding plus reasoning about retrieval or applied ML | 45 to 60 minutes, live problem |
| Applied problem or take-home | Hiring team | Practical ML, retrieval, or systems judgment on a realistic task | Async or timed, role dependent |
| Virtual onsite | Several engineers plus the hiring manager | Depth in retrieval, systems design, evaluation, product sense | Three to five back-to-back rounds |
| Founder or bar-raiser | Sivulka or a senior leader | First-principles thinking, ownership, tolerance for a fast pace | 30 to 45 minutes |
| Live client case (forward-deployed and solutions roles) | AI strategy team | Communicating Hebbia’s value and designing a client workflow | Live exercise |
The retrieval and applied-ML questions
The strongest signal you can send is that you have actually debugged a retrieval failure, not just read about one. Expect open-ended prompts that start from a broken result and ask you to reason backward. A few phrased the way they tend to come up:
- A user asks a question over a 200-page 10-K and the model answers confidently from the wrong section. Where in the pipeline did that go wrong, and how would you fix retrieval rather than patching the prompt?
- Given a long credit agreement, design something that returns every change-of-control provision with citations. What is your chunking strategy, and how do you know your recall is any good?
- A question needs facts spread across forty documents, not one. Top-k chunk retrieval clearly won’t cut it. What do you do instead?
- When does keyword search beat semantic search, and when is it the reverse? Give a concrete example from a financial or legal document.
- You have no labeled ground truth. How do you measure whether your retrieval quality went up or down after a change?
A weak answer treats these as prompt-engineering puzzles. A strong answer separates the retrieval problem from the generation problem, names the failure mode precisely (the right chunk was never retrieved, versus it was retrieved and the model ignored it, versus the chunk boundary split the answer in half), and reaches for evaluation early. If you can talk about reranking, hybrid dense-and-sparse retrieval, chunking that respects document structure, and the tradeoff between recall and latency without turning it into a buzzword salad, you are ahead of most candidates.
They also probe fundamentals, so be ready to explain what an embedding actually represents, how approximate nearest neighbor indexes like HNSW trade recall for speed, and why cosine similarity on generic embeddings often ranks a plausible-sounding but wrong passage above the correct one. The point is not memorized definitions. It is whether you can connect the math to why a specific answer came out wrong.
Systems design when one query fans out to hundreds of model calls
Matrix runs many model calls per user question, sometimes across thousands of pages, so the infrastructure questions are real and specific rather than the usual generic scaling drills. You might be asked to design a system that runs inference over millions of pages per customer while keeping latency tolerable and cost from exploding. Good directions to explore out loud: caching embeddings and intermediate results so you never reprocess the same document twice, batching and rate-limiting model calls, streaming partial results back to the user instead of blocking on the full fan-out, and deciding what to precompute at ingestion time versus what to run at query time.
They care whether you think about failure and cost as first-class concerns. What happens when a model call times out midway through a fan-out over 500 documents? Do you fail the whole query, return a partial answer with a warning, or retry, and how do you tell the user which parts of the answer are complete? That kind of question separates people who have shipped LLM systems in production from people who have only built demos.
Evals are the part people underprepare
Because Hebbia sells accuracy on documents where a mistake is expensive, evaluation is closer to the center of the job than at most AI companies, and it is where I would spend the most prep time. Expect to be pushed on how you would build an eval set for a legal or financial QA system when there is no obvious answer key. Talk about constructing gold answers with domain experts, using held-out questions where the answer is known, measuring citation faithfulness separately from answer correctness, and catching regressions before they reach a client rather than after. If you can describe a time you caught a quality drop with an eval you built, tell that story. It lands harder than any framework name-drop.
Forward-deployed and solutions roles run a live case
If you are interviewing for a forward-deployed or solutions engineering seat, the loop bends toward client-facing judgment. Candidates have described a live case with someone from the AI strategy team where you practice articulating what Hebbia does for a specific client and walk through how you would set up a workflow for them. This is a communication test as much as a technical one. Can you take a vague finance or legal use case and turn it into a concrete Matrix setup, explain the value without overpromising, and handle a skeptical buyer who has been burned by AI demos before? Solutions roles also tend to have the longest loops, so plan for a process measured in weeks, not days.
What to actually do before the loop
Read Hebbia’s own writing on why they moved past RAG and how Matrix fans out across documents. It tells you exactly how they think, and referencing it naturally signals you did the work. Build or rebuild a small retrieval system yourself over a genuinely long document, a full 10-K or a real contract, and pay attention to where it breaks, because that firsthand frustration is the thing they are listening for. Have one crisp story about measuring and improving quality on messy real data. And be ready for the founder conversation to be about pace and ownership more than technique, since this is a company that ships fast and expects people to own outcomes end to end.
On compensation, specific public numbers for Hebbia are scarce, so do not anchor on a figure from a salary aggregator. Comparable Series B AI startups in New York pay senior engineers competitive six-figure base salaries with early-stage equity that can matter more than the cash if the company keeps climbing. Check Levels.fyi for recent data points, and when an offer arrives, ask for the share count, the strike price, and the latest preferred valuation so you can actually value the grant instead of guessing. The equity math at a company valued in the high hundreds of millions is worth doing carefully.
The fastest way to lose this interview is to defend the standard RAG pipeline as if 2023 never ended. The fastest way to stand out is to walk in with a real story about a retrieval system you broke, measured, and fixed on documents that fought back.
