Most database interviews still test the skills that matter on one machine: reading an EXPLAIN plan, spotting a missing index, reasoning about a vacuum schedule. Those skills are real. They are also insufficient once the database spans racks and regions, because the hard part moves from query shape to the write path and its failure domains. This piece lays out the questions that actually separate distributed SQL depth from Postgres muscle memory, and how to rewrite a loop around them.

Single-Node Habits Die Hard

A typical Postgres loop asks a candidate to explain an EXPLAIN ANALYZE output. That is a reasonable filter for query tuning. It tells you almost nothing about whether someone can reason about a write that must survive a node failure in another availability zone. The two skills overlap less than interviewers assume.

In a distributed SQL interview, the first question should be where the write commits. Not which index, not which join order. Where does the acknowledgment come from, and what has to happen before the client sees success? Candidates who reach for replication lag before they reach for the commit path are already showing you their mental model.

The deeper problem is that most interviewers never probe failure domains at all. They ask about consistency in the abstract, get a CAP recitation, and move on. A candidate can pass that exchange without ever having thought about what happens when the leader dies mid-commit, which is the scenario the role will actually face.

The Commit Path Is the Real Question

Ask what happens between BEGIN and COMMIT in a Raft-backed system. A strong candidate will describe the client request landing on a gateway or coordinator, the write being routed to the leaseholder or leader for that range, and a consensus round trip before the commit is acknowledged. The acknowledgment is the interesting part.

Raft and Paxos add round trips. On a local network those round trips are cheap enough to hide. Across regions they are not, and the candidate who can estimate the cost is the one who has actually operated the system. Follow up with a simple question: what if the leader dies mid-commit? Good answers distinguish between a write that was replicated to a quorum and one that was not.

Strong consistency has a measurable cost, and the interview should surface it. A candidate who says consistency is free has not run a cross-region cluster. A candidate who says it costs one extra round trip per write, and can explain why that number changes with leaseholder placement, has.

Consider how CockroachDB handles this. Its commit path involves a Raft proposal to the leaseholder, which then replicates to a quorum of followers before acknowledging. In a multi-region deployment, that round trip crosses the WAN, and the latency is dominated by the speed of light in fiber, not by disk I/O. A candidate who has operated CockroachDB across regions will often mention that the leaseholder placement is the single biggest lever on write latency, and that moving the leaseholder closer to the writer can cut p99 by a large margin. That kind of specific, hedged observation is worth more than a recitation of the Raft paper.

Partition Scenarios Expose Depth

CAP is a starting vocabulary, not an answer. The useful follow-up is PACELC, which extends the question to the normal case: when there is no partition, you still choose between latency and consistency. A good answer names a concrete tradeoff in the system the candidate has used, not the acronym.

Give a scenario. A rack loses network connectivity to the rest of the cluster, and the application is still sending writes. What does the database do, and what does the application see? Candidates who have operated distributed SQL will talk about lease expiration, quorum loss, and the difference between a stalled write and a failed one.

The bad answer recites the acronym and stops. The good answer says something like: reads may be served stale from a follower if the application opts in, writes will block until quorum is restored, and the retry budget matters more than the timeout. That is a tradeoff with a cost attached.

Probe further with a scenario that involves asymmetric partitions. One availability zone can reach the other two, but the other two cannot reach each other. What happens to leases, and how does the system avoid split-brain? Candidates who understand Raft will describe how the leader in the minority partition steps down after a lease timeout, and how the majority elects a new leader. The application sees a brief window of unavailability for writes that were routed to the old leader, and the retry logic must handle that. This is the kind of failure that rarely appears in test clusters but happens in production, and the candidate who can walk through it has real depth.

Latency Budgets Beat Benchmark Recitation

Ask for a p99 write latency estimate. Not a benchmark number from a vendor page, an estimate with stated assumptions. A candidate who says roughly a few milliseconds within a region and tens of milliseconds across regions, then explains what changes the number, is stronger than one who quotes a figure without a model behind it.

Probe cross-region round trip assumptions. How many round trips does a commit take, and where do they go? Candidates who hedge their numbers are usually the ones who have measured. Candidates who state a precise figure with no assumptions are usually reciting.

Single-node thinking ignores network distance entirely, and that is the tell. A candidate who reasons about the write path as if it were local will design a schema that works in a test cluster and falls over when the leaseholder moves. Latency is a design constraint, not a benchmark result.

Ask the candidate to sketch a latency budget for a write that must replicate to three regions. A strong answer will break the budget into components: client-to-gateway, gateway-to-leaseholder, leaseholder-to-followers, and the return path. Each component has a floor set by physics. For example, a round trip between US East and Europe is typically in the 80–100 ms range, and a commit that requires two such round trips will have a p99 that reflects that. The candidate who can do this back-of-the-envelope calculation, even with rough numbers, demonstrates that they think about latency as a system property rather than a constant.

Operational Questions Reveal Scars

Ask about rolling upgrades and schema changes. Distributed SQL systems handle these differently from single-node Postgres, and the differences are where production pain lives. A candidate who has done a rolling upgrade on a multi-region cluster will mention version skew, lease transfers, and the order in which nodes are drained.

Probe rebalancing during peak traffic. What happens when a node is added and ranges start moving while the application is at its busiest? Good answers include blast radius limits: throttling the rebalance, capping the number of concurrent moves, and watching for hot ranges that make the move worse.

Watch for backup and restore intuition. A distributed backup is not a file copy. It is a consistent snapshot across ranges, and the restore path is where teams discover they never tested the thing they assumed worked. This site has argued that retry budgets decide which failures become outages, and the same logic applies to restore drills.

Schema changes deserve their own probe. In a distributed system, an ALTER TABLE that adds a column must propagate to every node, and the system must handle the case where some nodes have the new schema and some do not. A candidate who has operated distributed SQL will talk about online schema changes, the need for a two-phase approach in some systems, and the risk of blocking writes during the change. They might mention that some systems use a lease-based mechanism to ensure that only one node performs the change at a time, while others rely on a consensus round. The specifics matter less than the awareness that schema changes are a distributed coordination problem, not a local DDL statement.

Rewriting the Loop

Replace EXPLAIN drills with commit-path walkthroughs. Ask the candidate to trace a write from client to acknowledgment, naming each hop and what can fail there. This one change moves the interview from query tuning to systems reasoning without losing the tuning signal, because a candidate who understands the commit path usually understands the query too.

Add one partition scenario per interview, and require a concrete tradeoff rather than an acronym. Ask for latency estimates with stated assumptions, and score the assumptions as heavily as the number. Ask for a failure story from real operations, and listen for what the candidate changed afterward.

Score tradeoff reasoning over vocabulary. A candidate who can explain why a system chose latency over consistency in a specific case has more depth than one who can define PACELC but never applied it. The related piece on replication slots holding WAL until disk fills is a useful probe here: ask what the distributed equivalent of that failure looks like.

Three concrete actions for the next loop. Rewrite one existing question as a commit-path walkthrough and run it in the next interview. Add a written prompt asking for a p99 write latency estimate with assumptions stated explicitly. Ask each candidate to describe one operational failure they personally diagnosed, and score the blast radius reasoning in the answer. Keep the EXPLAIN question as a secondary filter, not the opener.