Neon stopped being an independent company in 2025. Databricks acquired it in a deal reported at around a billion dollars, and if you’re interviewing there today you’re really interviewing into a Databricks team that happens to own one of the more interesting Postgres codebases around. That shift changes the loop you’ll face and the comp you can expect. Worth knowing before you start prepping.
The technical bar was already high before the acquisition, and it did not drop after. Neon’s whole reason to exist is a hard systems problem: they pulled Postgres apart so that storage and compute scale independently. The storage engine is written in Rust. The compute side is Postgres itself, a few hundred thousand lines of mature C. Interviewers come from that world, and the questions reflect it.
What you’re actually walking into
Neon separated storage from compute so a database can autoscale, branch like code, and suspend to zero when nobody’s using it. When your Postgres instance goes idle, the compute node shuts off and you stop paying for it; when a query arrives, a new one spins up and reattaches to the same storage. Branching works by copy-on-write at a specific log position, so you can fork a multi-gigabyte database in about a second and throw the branch away when you’re done.
Under that sit two Rust services worth knowing by name before you interview. The pageserver stores database pages and reconstructs any page at any point in time by replaying the write-ahead log up to a given log sequence number. The safekeepers hold the WAL durably and run a consensus protocol, usually across three nodes, so an acknowledged commit survives a machine dying. If you can explain why that design lets the compute layer stay stateless, you’re already ahead of most candidates.
The other thing to understand is why Databricks wanted this. Neon has said publicly that the large majority of new databases on its platform are created by AI agents rather than by people, sometimes thousands at a time. Databricks turned that into Lakebase, a managed Postgres offering aimed at agents and applications that sit next to the lakehouse. A lot of current Neon hiring is really Lakebase hiring. Expect at least one interviewer to care about how databases behave when agents, not humans, are the ones creating and querying them.
The loop
Before the acquisition, a backend engineer typically saw a recruiter call and then three technical rounds, each a 45 to 60 minute one-on-one with an engineer. That core is intact, but the process now runs through Databricks recruiting, which added a values round and a more formal leveling conversation on top. Here’s the shape most systems and backend candidates report.
| Stage | Format and length | What it is really testing |
|---|---|---|
| Recruiter screen | ~30 min, phone | Background fit, why databases and infra, target level and comp range |
| Technical screen | 45-60 min, 1:1 with an engineer | Depth in your strongest area through a real systems discussion |
| Coding round | 45-60 min, live | Correct concurrent or I/O-heavy code, not LeetCode puzzles |
| Systems design | ~60 min | Storage and compute separation, consistency, failure modes |
| Domain deep-dive | 45-60 min | Postgres internals and Rust, or Kubernetes and cloud, depending on the role |
| Team and values | 30-45 min | Ownership, working in the open, how you collaborate |
Front-end and full-stack roles skew the design and coding rounds toward the console and API surface instead of the storage engine, but the systems bias runs through the whole company. Even the product engineers are expected to reason about what happens when a connection pool exhausts or a region goes dark.
What each round is really checking
The coding round is not a LeetCode gauntlet. You’re more likely to get a problem with real I/O, concurrency, or a nasty edge case in it: parse and merge a stream of WAL-like records, implement a small LRU with correct eviction under concurrent access, or reason through a race between two writers. They want to see that you write code that survives contact with production, that you test the ugly cases, and that you notice when something is O(n^2) hiding behind a clean-looking loop. Narrating your assumptions counts as much as finishing.
The design round is where the architecture pays off. A common prompt is some version of “design a system where storage and compute scale separately,” which is flattering if you’ve read how Neon works and rough if you haven’t. Interviewers push on consistency and failure: what happens to an in-flight transaction when the compute node dies, how you keep the WAL durable without making every commit wait on disk everywhere, how branching stays cheap when the parent keeps changing. Name the tradeoffs out loud. Say when you’d accept eventual consistency and when you wouldn’t.
The domain round splits by role. For storage and infra positions it goes deep on Postgres internals and often on Rust: MVCC and how dead tuples get cleaned up, why a long-running transaction blocks vacuum, what a checkpoint actually does, how the buffer cache and WAL interact. Rust questions tend to be practical rather than trivia, ownership and lifetimes in the context of code you’d write for a pageserver, not a quiz on the standard library. For platform and full-stack roles it leans toward Kubernetes, containers, CI/CD, and cloud plumbing, since that’s the day-to-day.
Questions phrased the way they’re actually asked
A sample of the kinds of prompts that come up, close to how interviewers word them:
- “Walk me through what happens, end to end, when a query hits a Neon compute node that just woke up from being suspended.”
- “How would you let someone branch a 10 GB database in under a second without copying 10 GB?”
- “MVCC keeps old row versions around. Who cleans them up, when, and what goes wrong if they never get cleaned?”
- “You need a commit to survive one node failing, but you can’t wait for every replica. How many do you wait for, and why?”
- “Here’s a function that leaks memory under load. Find it and fix it.” (usually Rust or C for infra roles)
None of these have a single blessed answer. The interviewer is watching how you decompose the problem, whether you ask about the constraints before you start drawing boxes, and whether you can say “I don’t know, here’s how I’d find out” without flailing.
Comp, now that it’s Databricks money
This is the part that changed most. Neon’s standalone offers were startup-shaped: competitive cash and meaningful equity, with wide variance by level. Post-acquisition, offers come out of Databricks bands, which means higher base salaries, a real bonus target, and Databricks equity rather than Neon options. Databricks is a large late-stage private company that has been widely reported as heading toward an IPO, so the equity is pre-IPO stock with the upside and the illiquidity that implies.
I’m not going to invent numbers, because they move and they depend heavily on level and location. Check levels.fyi for recent Databricks data points, filter by the level you’re targeting, and treat the equity as a range rather than a promise, since its value depends on a liquidity event you don’t control. When the recruiter gives you a band on the first call, that band is real and worth negotiating against with a competing offer in hand.
How to prep without wasting a week
Read Neon’s own architecture docs and engineering blog first. They’re unusually candid about how the storage engine works, and the design round rewards people who’ve clearly done that reading. For a storage or infra role, spend real time on Postgres internals, MVCC, WAL, vacuum, the buffer manager, and get comfortable enough with Rust to reason about ownership in someone else’s code. For platform and full-stack roles, be ready to whiteboard a deployment on Kubernetes and talk through what breaks at scale.
Practice narrating. The biggest differentiator in these loops is not raw knowledge, it’s the ability to think out loud, state your assumptions, and revise cleanly when the interviewer adds a constraint. The team works in the open on a public repo, and they hire for people who can reason in public without getting defensive. If you can walk into the design round and explain, unprompted, why a stateless compute layer needs a consensus-backed WAL underneath it, you’ll have answered half the interview before anyone asks.
Practice the behavioral round:
