PlanetScale · Software Engineer
Updated · 2026-10-02

PlanetScale Software Engineer
Interview Guide

THE 60-SECOND BRIEF

At PlanetScale, a Software Engineer is not just a backend developer; you are an architect of the world's most advanced database platform. PlanetScale has reinvented database technology by building on top of Vitess, the open-source database clustering system developed to scale MySQL horizontally. As a member of the core engineering team, you will design, build, and maintain critical distributed systems that serve millions of queries per second for some of the world's largest, most rapidly growing applications. The impact of this role is immense. Your work directly secures and scales what is often a company’s most precious asset: its data. Because the stakes are incredibly high, PlanetScale operates with a philosophy centered around small, highly autonomous teams of p99 individuals.

This guide is scoped to a Software Engineer candidate at PlanetScale.

PlanetScale candidates report 3 rounds over 3-5 weeks. The stages below are what candidates describe, not a published process.

Distributed SystemsDatabase Infrastructure EngineeringVitess

27 min read

Browse Software Engineer questions

See the practice prompts

11Practice promptsAcross five skill areas

At PlanetScale, a Software Engineer is not just a backend developer; you are an architect of the world's most advanced database platform. PlanetScale has reinvented database technology by building on top of Vitess, the open-source database clustering system developed to scale MySQL horizontally. As a member of the core engineering team, you will design, build, and maintain critical distributed systems that serve millions of queries per second for some of the world's largest, most rapidly growing applications. The impact of this role is immense. Your work directly secures and scales what is often a company’s most precious asset: its data. Because the stakes are incredibly high, PlanetScale operates with a philosophy centered around small, highly autonomous teams of p99 individuals. This means you will have the freedom to solve complex engineering and business problems with minimal direction, taking high ownership of your systems from design to production. Whether you are optimizing query routing, diving into database internals, or refining cloud-native orchestration on Kubernetes, your contributions will directly influence the developer experience of thousands of companies worldwide. This role requires a rare blend of deep systems-level knowledge, pragmatic problem-solving, and a passion for building robust, clean, and highly maintainable codebases.

The PlanetScale interview process

01

Recruiter Screen

reported

Initial conversation with a recruiter to discuss background, interest in the database space, and role expectations.

What to demonstrate

  • Initial conversation with a recruiter to discuss background, interest in the database space, and role expectations
  • Depth in Distributed Systems

How to prepare

  • Be able to walk your CV end to end in two minutes, and say why this company specifically.
  • Have your salary expectations, notice period and location constraints ready, and ask for the rest of the loop in writing.
PlanetScale Software Engineer candidate reports ↗
02

Technical Rounds

reported

Series of interviews focusing on systems programming, live coding, and distributed system design.

What to demonstrate

  • Series of interviews focusing on systems programming, live coding, and distributed system design
  • Depth in Distributed Systems

How to prepare

  • Work Distributed Systems until you can explain it without notes
  • Work Database Infrastructure Engineering until you can explain it without notes
PlanetScale Software Engineer candidate reports ↗
03

Leadership Interview

reported

Final interview with a leadership or VP-level member to evaluate strategic alignment and communication style.

What to demonstrate

  • Final interview with a leadership or VP-level member to evaluate strategic alignment and communication style
  • Depth in Distributed Systems

How to prepare

  • Work Distributed Systems until you can explain it without notes
  • Work Database Infrastructure Engineering until you can explain it without notes
PlanetScale Software Engineer candidate reports ↗

Where candidates lose points

PracHub editorial advice for the preparation topics above.

01

Emphasize your open-source mindset

PlanetScale is deeply connected to the open-source community. If you have contributed to open-source projects, written technical blogs, or engaged with developer communities (like the Vitess Slack), make sure to highlight this.

02

Show your passion for open-source

PlanetScale is deeply rooted in the Vitess community; demonstrating familiarity with Vitess or open-source database tools will set you apart.

03

Focus on pragmatic trade-offs

In system design rounds, do not just present a single "perfect" solution. Discuss the trade-offs of your choices (e.g., consistency vs. latency, write performance vs. read performance) and explain why your design is appropriate for the scale required.

Questions & practice

Choose a category, try a prompt, then open its approach, worked solution or follow-up when you need it.

8 technical prompts0 include a worked solution

Canonicalise a request body into a stable idempotency fingerprint

medium
parsingcanonicalisationhashing

idempotency_key.request_fingerprint is a SHA-256 over the method, path and canonicalised body, and a retry whose fingerprint differs must be rejected with 422 rather than served the stored response. Write the canonicaliser. Bodies are JSON up to 256 KB nested at most 32 levels; clients vary key order, whitespace and unicode escaping, and some send 64-bit ids as JSON numbers. Produce a deterministic byte string such that semantically identical bodies match and any semantic difference does not. State your complexity and name two normalisations you refuse to perform.

Approach
  1. Parse once into a tree, then re-serialise under fixed rules: object keys sorted, array order preserved, one escaping convention, no insignificant whitespace. Parsing is O(n) and sorting keys is O(k log k) per object, so O(n log n) overall with O(depth) stack, and the 32-level cap is enforced during parsing because hostile nesting is how a canonicaliser becomes a stack overflow.
  2. Sort keys by their UTF-8 bytes and say why the obvious implementation is wrong in some runtimes: a default string comparison that orders by UTF-16 code units places surrogate pairs, meaning code points from U+10000 up, below U+E000 to U+FFFF, which is not UTF-8 byte order, so two services written in different languages disagree on the same document.
  3. Do not re-encode numbers through a double. IEEE-754 binary64 represents integers exactly only up to 2^53, so normalising a 19-digit id through a float changes it, and 1 against 1.0 cannot be reconciled without deciding whether they are the same value. Preserve the literal token, and require ids as strings at the API boundary if you want them comparable.
  4. Reject duplicate keys rather than picking one. JSON permits them and parsers disagree, most keeping the last, so any choice you make ties the fingerprint to a parser detail that the code handling the request does not necessarily share.
Follow-up
  • A client sends the same logical request with an extra field your API ignores. Same key, different fingerprint, so you return 422. Is that the right answer?
  • Where does the fingerprint get computed relative to request decompression and the body-size limit?

Collapse a redelivered event batch into per-aggregate high-water marks

easy
hashingat-least-onceaggregation

You drain a batch of up to 5,000,000 events, each (aggregate_id BIGINT, aggregate_version INT, event_type, payload). The log guarantees order within one aggregate only; the batch merges 64 partitions, and a relay failover has redelivered a range, so an older version for an aggregate can appear after a newer one. Given a map of last_applied_version per aggregate, produce the events worth applying, at most one per (aggregate_id, version), plus the count discarded. Target O(n) time. State the memory for 2,000,000 distinct aggregates and what you do when it does not fit.

Approach
  1. One pass, one hash map from aggregate_id to the highest version kept, and a discard counter. An event whose version is at or below last_applied_version for its aggregate is dropped without further work, which is the whole reason the event carries its version rather than a delta. O(n) expected time, O(d) space in distinct aggregates.
  2. Keep the maximum, never the last occurrence. The redelivered range means the final appearance of an aggregate in the batch can be an older version than one seen earlier in the same batch, so last-wins applies stale state over newer state and the projection regresses with no error anywhere.
  3. Cost the memory instead of calling it large: an 8-byte key plus a 4-byte version is 12 bytes of payload, and an open-addressed table held at a 0.7 load factor costs roughly 17 bytes per entry before per-slot metadata, so 2,000,000 aggregates is tens of megabytes in a native layout and several times that in a runtime that boxes both key and value.
  4. If the distinct set exceeds memory, partition on hash(aggregate_id) mod P and reduce each partition independently. Every event for one aggregate hashes to the same partition, so the per-partition result is exact and the merge is concatenation rather than a second reduction.
Follow-up
  • The payload is a patch rather than a snapshot, so applying only the highest version loses the intermediate changes. What changes in your reduction?
  • How do you detect that version 7 arrived while version 6 was never delivered, and what should the consumer do about the gap?

Identify the heaviest tenants in a five-minute window under memory pressure

medium
top-kheavy hittersstreaming

The edge service handles about 3,000 requests per second across roughly 50,000 tenants, peaking near 9,000. Expose the 50 heaviest tenants by request count over the trailing five minutes so limits can be tightened before one tenant's backfill starves the fleet. You may not retain five minutes of raw records. Give the exact solution and its memory, then the bounded-memory approximation with its error stated as a formula, and say which you would ship and at what tenant cardinality that choice changes.

Approach
  1. Do the exact version first, because it is affordable at this cardinality: a ring of 300 one-second counters per tenant, advanced lazily, is 1,200 bytes of counters per tenant and roughly 60 to 90 MB for 50,000 tenants with overhead. Carry a running total and subtract the bucket you overwrite so a window read is O(1) rather than 300 adds.
  2. Extract the top 50 with a size-k min-heap over the tenant sums: O(d log k) for d tenants, against O(d log d) to sort them all. Maintaining the heap continuously instead of on query requires a tenant-to-heap-index map, because incrementing a count already inside the heap means sifting from a known position, and without that map you rebuild the heap on every request.
  3. State the approximation precisely rather than gesturing at sketches. Misra-Gries with m counters retains every item whose true count exceeds N/(m+1), and each retained count underestimates the truth by at most N/(m+1). With m = 1,000 and N = 900,000 requests in the window the error is roughly 900 requests, which is fine for spotting a tenant sending 50,000 and useless for ranking two tenants 200 apart.
  4. Say what breaks when the window slides: Misra-Gries and Space-Saving are insert-only and cannot be decremented as records age out. The workable construction is one summary per sub-window, say ten seconds, with 30 summaries merged at query time, and the merged error is the sum of the per-summary errors, so the bound degrades linearly in the number of sub-windows.
Follow-up
  • The heaviest tenant is heavy because of one export job rather than user traffic. Should the limiter treat those as the same tenant?
  • Two tenants sit tied at the boundary of the top 50. Does your answer flap, and does the flapping matter?

Suggested practice checklist

Built from the rounds and topics PlanetScale candidates report.

Small steps. Visible outcomes.0 / 7 completed
ONE WEEK · YOUR PACE

Prepare, practise & reflect

One practical outcome each day. Spend longer where you need it.

0 / 7 done
01Map the PlanetScale loop
  • Write out the reported sequence: Recruiter Screen, Technical Rounds, Leadership Interview.
  • For each round, write one sentence on what it is judging, from the description above, and mark the one you are least ready for.

Deliverable: A one-page map of the 3 reported rounds, with the weakest marked.

02Work Distributed Systems
  • Spend the session on Distributed Systems, which PlanetScale candidates report being tested on.
  • Write one worked example in Distributed Systems and time yourself on it.

Deliverable: One timed worked example in Distributed Systems.

03Work Database Infrastructure Engineering
  • Spend the session on Database Infrastructure Engineering, which PlanetScale candidates report being tested on.
  • Write one worked example in Database Infrastructure Engineering and time yourself on it.

Deliverable: One timed worked example in Database Infrastructure Engineering.

04Work Vitess
  • Spend the session on Vitess, which PlanetScale candidates report being tested on.
  • Write one worked example in Vitess and time yourself on it.

Deliverable: One timed worked example in Vitess.

05Consolidate
  • Re-work the problem you got wrong earliest in the week, from scratch, without looking at your previous attempt.

Deliverable: A second, cleaner solution to the problem you got wrong first.

06Rehearse your own examples
  • Prepare three examples from your own work where you made the decision, each with the outcome you can quantify.

Deliverable: Three examples written out, each with a number attached.

07Dry run for PlanetScale
  • Run one full mock under time, then write down the two questions you most want to ask your interviewers.

Deliverable: A completed timed mock and two questions to ask.

Expand any day for tasks and deliverables. Your progress is saved on this device.

Behavioural preparation

Behavioural rounds judge the decision you made and what it cost.

Unblock an engineer without taking the keyboard

easy
mentoringleasesat-least-once

A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

Approach
  1. Ask before diagnosing, and ask for things answerable from data they already have: the attempt count on the job rows that produced duplicates, the handler's observed duration against its lease expiry, and whether the duplicate rows share a natural key that a unique constraint could have caught.
  2. Teach the shape rather than the answer. A lease cannot distinguish a dead worker from a slow one, so a handler that outruns its lease is running twice by design, and deploys deliver the other half by killing handlers mid-run on every rollout. Both of their candidate theories produce identical duplicate rows, which is why the evidence has to come from timings rather than from argument.
  3. Hand over a checklist they execute: a natural key on every write the handler performs so the second copy collides rather than appends, the record of intent written before any external effect, a lease heartbeat while running, and the metric that shows it working.
  4. Keep ownership with them deliberately. Pair on the first write, then step back; if you finish it yourself you have closed one ticket and left the same person stuck on the next redelivery.
Follow-up
  • How would you distinguish a genuine double-delivery from a lease expiry using only the data already stored?
  • Their handler calls an external endpoint before recording that it did. What do you tell them to change first?

Argue against a design, lose, and commit anyway

medium
disagreementservice boundariesdecision records

Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.

Approach
  1. State the prediction in falsifiable form up front: the mechanism, the condition that triggers it, and the observable outcome. A prediction that cannot be checked also cannot be credited to you later.
  2. Show the evidence you had at the time and label each piece honestly as measured, analogous, or intuition. Keeping the intuition is fine; disguising it as data is the thing that erodes your standing in the next argument.
  3. Represent the opposing case at full strength, including the constraint you did not control: a fixed date, a team boundary, or the fact that the decision was cheap to reverse and yours was not.
  4. Make disagree-and-commit concrete. Name the artefact you left behind so the prediction could be settled without you: the alert and its threshold, the counter on the dashboard, the decision note that recorded the trade-off and the condition that would revisit it.
Follow-up
  • What threshold on that alert would have proved you right, and did anyone ever look at it?
  • If the same proposal arrived tomorrow with the same deadline, would you argue it the same way?

Ship under a deadline and bound the debt you chose

medium
paginationtechnical debttradeoffs

You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

Approach
  1. Name the deferred failure precisely instead of calling it slow. OFFSET n makes the database produce and discard n rows, so cost grows with page depth; without an index matching the sort, every matching row is read and sorted before the limit applies; and rows inserted between two page fetches shift across the boundary so items are skipped or repeated with nothing in the response to signal it.
  2. Bound the blast radius with something mechanical rather than a promise: cap maximum page depth, cap page size, restrict the endpoint to one internal caller, or keep it behind a flag. State which failure each cap removes and which it leaves standing.
  3. Attach a number to the trigger and wire it to an alarm: the first tenant crossing N resources, or the endpoint's p99 crossing its share of the 400 ms budget, so the debt announces itself instead of waiting to be remembered.
  4. Write it where the next engineer looks, which is the code and the ticket, not a chat message: what was deferred, why, the cap, and the trigger.
Follow-up
  • At what page depth does the offset version breach your latency budget, given your page size and row counts?
  • What breaks first when you switch to keyset pagination later, and what does a client holding an old page token see?
  • 01

    A teammate has spent two days on a job handler that occasionally writes duplicate rows. They are certain the queue is delivering twice by mistake. You suspect a lease expiring under a slow handler, so the job is running concurrently with itself. Describe how you have unblocked someone in this position: what you asked before offering a hypothesis, what you showed them rather than told them, and what you left them owning. Then say what you would do if their theory turned out to be the right one.

  • 02

    Describe a design you argued against and lost. State the failure you predicted as a named mechanism, not a feeling about complexity: two services that would need one transaction, a projection with no rebuild path, a write path with no idempotency key. Say what evidence you brought, what the decision maker weighed instead, and what you did after the decision was made: what you instrumented, what you wrote down, and whether the prediction came true. Five minutes.

  • 03

    You have four days to ship a tenant-facing listing endpoint. The version you would defend uses keyset pagination over (tenant_id, status, updated_at DESC, resource_id DESC); the version you can finish uses LIMIT/OFFSET with no matching index. Describe a deadline call you actually made of this shape: what you shipped, what you knowingly deferred, how you bounded the damage with a mechanism rather than an intention, and the specific numeric condition that would force the follow-up. Name who you told and where you wrote it down.

PracHub preparation framework ↗

Frequently asked questions

How difficult is the interview process at PlanetScale?

The process is challenging and highly technical, focusing heavily on real-world systems engineering, database internals, and concurrency. However, candidates find it fair, transparent, and free of arbitrary brainteasers.

PlanetScale Software Engineer candidate reports ↗
What is the typical timeline from the first screen to an offer?

PlanetScale generally moves quickly, often completing the entire process within a few weeks. However, keep in mind that holiday seasons or team availability can occasionally introduce delays in scheduling.

PlanetScale Software Engineer candidate reports ↗
Do I need to be a Vitess expert to get hired?

No, you do not need to be a Vitess expert beforehand, but you should have a strong foundation in relational databases (like MySQL or Postgres) and distributed systems concepts. A willingness to learn and engage with the Vitess community is highly valued.

PlanetScale Software Engineer candidate reports ↗
What is the working style and culture like?

The culture is built on high trust, high autonomy, and asynchronous communication. PlanetScale hires "p99 individuals" who can execute independently without micromanagement, making it an ideal environment for self-starters.

PlanetScale Software Engineer candidate reports ↗
How many interview rounds does PlanetScale have for a Software Engineer, and what are they?

PlanetScale reports 4 interviews total for the Software Engineer experience. The process includes a Recruiter Screen, Technical Rounds focused on systems programming, live coding, and distributed systems design, and a final Leadership Interview with a leadership or VP-level member.

PlanetScale Software Engineer candidate reports ↗
What does PlanetScale test for Software Engineer interviews, especially for distributed systems and coding?

Technical Rounds focus on systems programming, live coding, and distributed system design. The role is also strongly aligned to distributed systems and database infrastructure topics including Distributed Systems, Database Infrastructure Engineering, Vitess, MySQL, and Horizontal Scaling, plus Go (Golang) and debugging distributed systems.

PlanetScale Software Engineer candidate reports ↗
What are the most important topics to prioritize when preparing for a PlanetScale Software Engineer interview?

Prioritize distributed systems and database internals tied to PlanetScale, including Vitess and MySQL, and understand horizontal scaling. The topic list also includes debugging distributed systems, plus Go (Golang), and PostgreSQL, so be ready to connect those areas to backend behavior under load.

PlanetScale Software Engineer candidate reports ↗
What software engineering interview questions are publicly available for PlanetScale, and how should I use them to prepare?

Public sample questions include “Resolving an Issue Independently” and “Balancing Technical Debt and Delivery.” Use these as anchors for behavioral prep by preparing clear examples that show autonomy on ambiguous problems and a pragmatic approach to trade-offs.

PlanetScale Software Engineer candidate reports ↗
Sources & methodology 3 sources ↗

No official company page is cited. Rounds and questions come from candidate reports and PracHub editorial material; each source shows the date it was read.

Browse Software Engineer questions