Data modelling & storage in a Staff interview
Our Staff data questions put a decision beside its numbers: a write latency budget, the outage an SLO allows, a retention period, one hot row. They test whether you choose the design those numbers allow and can say what the other one would have cost.
An axis of our Staff backend and Staff fullstack targets.
The check comes with every pass and covers all the competencies of the target you choose: 10 for Staff backend (about 20 minutes) and 12 for Staff fullstack (about 24 minutes). It reports each one as Ready, Borderline or a Gap for this level. It never predicts a pass.
Patterns our questions are designed to test at Staff
These are the distinctions the questions on this axis are written to separate — our judgement from writing them and having them reviewed, not a measurement of candidates. We have run no study, so nothing here is a statistic and none of it is phrased as one.
- 1.
Consistency bought for every request when one endpoint needed it
In one of our questions, a single endpoint needs read-your-writes from a PostgreSQL streaming standby. With that standby named in
synchronous_standby_names,synchronous_commit = remote_applygives it by making every commit wait until the standby has replayed it, and lets a stalled standby stall every write. Routing a user's reads by the WAL position of their last write gives that endpoint the same guarantee for one stored position per user and one comparison per read. Our Staff questions ask who needs a guarantee, and who pays for it. - 2.
A key chosen for one query and paid for by another
Resharding a MongoDB collection from
createdAtto its hash spreads inserts that all landed on one shard, and sends the dashboard's last-hour query to all six shards. Partitioning a 2 TB PostgreSQL events table by month turns a three-hour nightlyDELETEinto dropping each month once all of it is past retention; partitioning it by tenant keeps the delete and the vacuum after it. Our questions ask which access path a key serves and which one it gives up. - 3.
A change that does not reach the data already there
Widening an S3 replication rule replicates the objects written from then on; the ones already in the bucket need a Batch Replication job, and Replication Time Control's 15-minute target covers objects as the rule replicates them, not that job. Sending AWS Backup's cross-Region EBS snapshot copies to a vault with a different KMS key makes the next copy a full one; a vault's key is fixed when the vault is created, so the change is a new vault. Our Staff questions ask what a change does to the data that predates it, and to the next job that touches it.
- 4.
Zero downtime treated as free
Moving PostgreSQL 14 to 17 by logical replication avoids a planned write outage, and replicates neither schema changes nor sequence values, so weekly migrations are paused or applied on both sides during catch-up, and every sequence is set by hand at cutover. A rehearsed
pg_upgrade --linkthat fits inside the outage the SLO allows is the cheaper option, and once the new cluster starts, the old one is no longer a way back. Our Staff questions give the budget and ask which risk it pays for.
What a strong answer sounds like: A strong answer picks the option the stated numbers allow, says what the rejected one would have cost, and names what has to stay true for the choice to hold.
How the check measures it
3 questions drawn on this axis alone — 1 medium and 2 hard for a Staff target, because the bar is the level. Hard counts for one and a half times a medium, which is what makes the verdict relative:
| Medium right | Hard right | Verdict |
|---|---|---|
| 1 of 1 | 2 of 2 | Ready |
| 0 of 1 | 2 of 2 | Ready |
| 1 of 1 | 1 of 2 | Borderline |
| 0 of 1 | 1 of 2 | Gap |
| 1 of 1 | 0 of 2 | Gap |
| 0 of 1 | 0 of 2 | Gap |
Three questions is coarse and the report says so beside every verdict. It is enough to separate this axis from the others in your target, which is what the check is for — there is no total, no percentage and no single number anywhere in the report.
What there is to practise
Questions here most often also test technical judgment: decisions and trade-offs, debugging and incident reasoning, distributed systems and reliability & failure modes. Few questions on this axis test it alone, which is why the check reports every competency separately rather than averaging them.
One of them, in full
A question from the free demo, not written for this page. A demo quiz opens with it; the answer, the explanation and the source come when you submit — no account needed.
Answer it on the demoOne axis is not the loop
This axis is one of 10 in our Staff backend target and one of 12 in Staff fullstack, and being strong here says nothing about the others. The check covers all of them in one sitting and reports each separately, so what comes back is a profile rather than a score.