What the round is like
One candidate said their interviewer spent half the round on how concurrent transactions and failure recovery would actually work. Have a reasonable high-level design quickly, so you have time to go deep. New grads get a design round too.
What people have been asked
These come up in candidates' own write-ups of their interviews. We wrote the example prompts ourselves, so the wording you get will be different.
Design a game payment system
Credit card processing for an online game: players buy in-game credits with a card, spend them on items and can get refunds.
Charges, credits and items all have to stay correct when lots of things happen at once and some of them fail.
How it might be asked
Design the payment system for an online game. Players buy in-game credits with a credit card, spend credits on items, and can get refunds. Everything has to stay correct under heavy concurrency and partial failures.
Key concepts to know
Try this Interview
Build a multi-threaded log writer
A single-machine design: many threads write log entries, and they all have to end up in a file in order.
Candidates say it starts as a simple single-threaded writer. Then you add threads and have to keep every entry whole and in order.
How it might be asked
Build a logging system that lots of threads in one program can write to. Every entry has to end up in the file complete and in the order it was written, and it needs to keep up as you add threads.
Key concepts to know
Try this Interview
Design a book price aggregator
A middleman service that asks lots of bookstores for a book's price and decides where to buy it.
Some stores are slow or down, so you can't just wait on all of them. Reports say the interviewer cares a lot about the API and the data model.
How it might be asked
Design a service where a user gives an ISBN and a max price. It asks lots of bookstores for their price, picks the best one, and places the order. Some stores are slow or fail. Focus on the API, the data model, and how you handle bad stores.
Key concepts to know
Try this Interview
Design a distributed job scheduler
Users submit jobs to run now or later, and the system runs them across a fleet of workers.
Error handling is the whole point. Workers die mid-job, and you have to make sure jobs don't get lost or run twice.
How it might be asked
Design a system where users submit jobs to run now or on a schedule. It runs them across lots of workers and handles retries and failures, so jobs don't get lost or run twice.
Key concepts to know
Try this Interview
What's really being tested
| Topic | What you're being asked, basically |
|---|---|
| Correctness | What has to be exactly right, and how do you guarantee it? |
| Concurrency | What happens when two things change the same data at once? |
| Failure | If a step fails halfway, how do you recover? |
| Depth | Can you explain how a box on your diagram actually works? |
How to work through a question
- Figure out what you're building. Who's using it, what does it need to do, and what can you ignore?
- Do some rough math. How many requests, how much data, more reads or more writes? Those answers decide a lot.
- Walk through one request. Draw the simplest thing that works before you add anything fancy.
- Pick storage last. Once you know what gets read, how often and how fresh it has to be, the choice gets a lot easier.
- Then try to break it. What happens in a traffic spike? What if a server dies?
Key concepts to know
If you're rusty on any of these, start here.
- Idempotency and retriesMake sure a retried request doesn't happen twice.
- Consistency and the CAP theoremWhat happens when copies of your data can't agree.
- Message queues and event streamsKeep services from depending on each other, and handle traffic spikes.
- Relational vs non-relational databasesPick a database based on how you'll actually use it.
- Sharding and consistent hashingSplit data across machines and keep it balanced.
- Caching strategiesMake reads faster, and figure out what to do when data changes.
- Rate limitingStop too much traffic with token buckets and sliding windows.
- Concurrency and threadsShare data between threads without races or deadlocks.
Sources
We pulled this together from candidates' own write-ups of their interviews. They don't always agree, and things change over time.
- LeetCode Discuss: senior onsite, payments and log writer
- LeetCode Discuss: SDE II loop (Fibonacci tree, CIDR)
- LeetCode Discuss: L5 phone screen, CIDR firewall
- Jointaro: backend SWE, Belgium (2025)
- Jointaro: senior SWE screen, SnapshotSet (2023)
- 1point3acres: onsite, encoder and SnapshotSet
- 1point3acres: onsite, job scheduler and book buying service
- Glassdoor: new grad SWE reviews (House Robber, 2025)
Practice Loop is an independent practice tool and isn't affiliated with or endorsed by Databricks.