Turbopuffer builds a serverless vector and full-text search database on top of object storage (S3 and GCS), which makes search roughly 10x cheaper at scale than memory- and disk-replica architectures. Founders Simon Eskildsen (CEO) and Justine Li (CTO) spent years scaling Shopify’s database layer from 1k to 1M requests per second, and the company grew out of a 2023 blog post into the search backend for Cursor, Notion, Linear, and Anthropic. The numbers are unusual: as of mid-2026, Turbopuffer has raised less than $1M in primary capital (backers include Lachy Groom and Thrive Capital), is profitable, and reports ARR in the tens of millions with a team of roughly 17 in early 2026, growing toward 40 by mid-year. That profile shapes the interview: no leetcode factory, and every hire has to pull serious weight from week one.
Process
Straight up: there are almost no first-person interview reports for Turbopuffer on Glassdoor, Blind, or Reddit as of mid-2026. The company is tiny and hires rarely, so the sample size is close to zero. What follows is the likely shape, assembled from their job postings, Simon’s public interviews, and how comparable database companies (Neon, Materialize, CockroachDB, where several team members came from) run their loops.
Expect a short loop, probably three to five conversations over one to three weeks: an intro call with a founder or early engineer, one or two technical rounds grounded in real work rather than puzzles, a domain conversation on search internals, storage engines, or distributed systems, and a values conversation about how you work. Simon has said publicly that Turbopuffer runs an interview designed to screen for the traits of a “P99 engineer”: obsessiveness, root-cause discipline, and the instinct to keep pulling a thread until the system makes sense. He has also described a reject-by-default culture: an offer happens when someone on the team champions you strongly, never on a lukewarm “fine.” A paid work sample or short project would fit the postings’ shipping emphasis, though we could not verify one. Writing matters at every stage: every posting, from database engineer to designer, lists “typist: you can write well and explain complex ideas simply” as a hard requirement, so expect your emails and follow-ups to count.
What they actually ask
- Systems fundamentals at the metal. The database engineer posting asks for people who “think in memory layouts, cache lines, and syscalls.” Expect questions on how data actually moves: page cache behavior, IO pipelines, SIMD, allocation patterns, and what a profiler would show for a given workload.
- Performance debugging. The job description names “intensive performance hacking: tracing, CPU/heap profiling, optimizing data structures, tuning IO pipelines” and lists eBPF, perf, strace, and gdb as expected tools. A likely round: here is a slow query or a latency spike, walk us through finding the cause.
- Domain depth in one of three areas. They explicitly require expertise in search internals (inverted indexes, ANN indexes, rerankers), storage engines (LSM trees, WALs, MVCC, compaction, garbage collection), or distributed systems (replication, leases, fault injection). Expect a long conversation probing whichever one you claim.
- Design against object storage constraints. Their whole product is a bet that you can build low-latency search on S3 with caching in front. Expect system design discussion about cost, cold-start latency, write amplification, and consistency when your durable layer is a blob store.
- Napkin math. Simon literally wrote the napkin-math performance estimation project and teaches it publicly. Candidates should expect back-of-envelope questions: how many vectors fit in a cache tier, what does a query cost in IOPS and dollars, does this design clear the latency budget.
- How you work, in writing and with customers. Values are posted on every listing: “overstep > understep, show > tell, complexity is earned.” Product and customer engineering roles add multi-tenant SaaS, React ecosystem, and live debugging of customer workloads in Slack. Prepare concrete stories of ownership beyond your job description.
Levels and comp (2026)
Turbopuffer publishes no salary bands: the Ashby postings (US and Canada, remote) ship without compensation fields, and levels.fyi has no verified data points as of mid-2026. There is no public leveling ladder either; at this size, titles are flat (“database engineer,” “product engineer”) and scope is negotiated per person. Anchor your expectations on comparable seed-to-Series-A database infrastructure companies, where senior and staff systems engineers commonly land in the $180k to $300k+ base range in the US, less in Canada, plus meaningful equity. The equity conversation deserves extra care: the company is profitable, raised very little primary capital, and Simon has said the team itself is a significant stakeholder, which suggests less dilution than a typical venture-backed startup. Get the recruiter or founder to spell out base, grant size, strike price, latest preferred price, and total shares outstanding so you can value the grant yourself. They hire almost entirely senior people, so do not expect a new-grad band to exist at all.
Prep priorities
Skip generic leetcode grinding: nothing in their materials points to algorithm trivia, and everything points to systems depth. First, pick your domain lane (search internals, storage engines, or distributed systems) and get genuinely sharp in it: re-read the LSM and MVCC literature, or the HNSW and BM25 papers, whichever is yours, and be ready to defend design tradeoffs for an hour. Second, practice performance narration: profile something real with perf or flamegraphs and get fluent describing the path from symptom to root cause. Third, drill napkin math until latency and cost estimates are reflexive; Simon’s own napkin-math repo is the best prep material and doubles as proof you did your homework. Fourth, write: a technical blog post or design doc is close to a prerequisite given the “typist” bar. Keep core coding patterns warm in Rust or C++, and prepare behavioral stories that show obsession and ownership: the bug you chased for a week, the migration you flew out to finish, the thing you fixed that nobody asked you to fix. That is the “P99” trait they screen for.
Frequently Asked Questions
Is the Turbopuffer interview hard? The bar is high in a specific way: they hire senior systems engineers with real domain depth, and Simon has described a reject-by-default process where someone must champion you. It is less about tricky puzzles and more about whether an hour of technical conversation exposes genuine expertise.
Do I need to know Rust? The engine is written in Rust, but postings ask for extensive experience in any systems language (“Rust, C++, Java, Go, etc.”) with multiple years of Rust listed as nice to have. Deep C++ plus storage-engine expertise beats shallow Rust; expect to pick up Rust fast on the job.
Is Turbopuffer remote or in-person? Remote-first across the US and Canada (one design role also lists Europe), with flexible hours. They open offices in cities with two or more employees, currently Ottawa, Vancouver, and NYC, so colocation is optional rather than required.
What does Turbopuffer pay? No public bands exist and no verified levels.fyi data as of mid-2026. Expect senior-level startup packages, likely competitive cash given profitability, plus equity. Ask directly for base, grant size, strike price, and preferred price, and pressure-test the equity story since this is an unusually capital-efficient company.
Similar company guides
Prepping for Turbopuffer? Put it to work:
