What the round is like
Design rounds run 60 to 90 minutes, often after some resume talk. Interviewers dig into trade-offs: SQL vs NoSQL, load balancing, caching, deployments, API gateways, and cloud vs running your own servers. Some candidates get schema design or a question about what their team actually builds instead of a classic design.
What people have been asked
These come up in candidates' own write-ups of their interviews. Prompts vary a lot by team. We wrote the example prompts ourselves, so the wording you get will be different.
Build a secure client portal
A web app where clients onboard, reset passwords, request company information and raise IT tickets. One recent candidate got this in a 90-minute round.
Each feature has to deploy on its own, and everything handles highly sensitive financial data.
How it might be asked
Design a web application where users of a financial data company can sign up, reset their password, request information about companies, and raise IT help requests. Each feature should deploy independently, and the data is highly sensitive.
Key concepts to know
Try this Interview
Stream live stock prices
Candidates report getting a real-time market data system: prices come in from several exchanges and go out to connected users.
Prices arrive over an unreliable network, so you have to deal with lost, duplicated and out-of-order messages before anyone sees them. Sending each update to lots of users comes second.
How it might be asked
Design a real-time market data system. Several exchanges send prices to your servers over UDP, so messages can get lost, duplicated or arrive out of order. Clean that up, store the prices, and stream them to connected users.
Key concepts to know
Try this Interview
Price alerts
Users set rules on stock prices, and the system tells them when a rule is hit.
Every price tick has to be checked against lots of rules quickly, and "moved X% in Y minutes" means tracking a rolling window without keeping the whole stream.
How it might be asked
Users set price rules, like "tell me when this stock goes above a level" or "tell me if it moves 5% in 10 minutes". Design the system that checks every price tick against those rules and notifies them.
Key concepts to know
Try this Interview
Ride sharing
Match riders with nearby drivers using their live locations.
Finding nearby drivers fast takes a geospatial index, and candidates get pushed on SQL vs NoSQL and CAP trade-offs.
How it might be asked
Design a ride-sharing service like Uber. Drivers send their location, riders request a ride, and you need to match them quickly.
Key concepts to know
Try this Interview
What's really being tested
| Topic | What you're being asked, basically |
|---|---|
| Latency | Where does time go between the exchange and the screen? |
| Ordering | How do you handle messages that arrive late, twice or not at all? |
| Trade-offs | Why this database, and what do you give up? |
| Security | Who can see what, and how do you prove it? |
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.
- Message queues and event streamsKeep services from depending on each other, and handle traffic spikes.
- Stream processing and windowingCount things in data that never stops coming in.
- Authentication and access controlWork out who someone is and what they're allowed to do.
- Caching strategiesMake reads faster, and figure out what to do when data changes.
- Sharding and consistent hashingSplit data across machines and keep it balanced.
- Relational vs non-relational databasesPick a database based on how you'll actually use it.
- Rate limitingStop too much traffic with token buckets and sliding windows.
- Idempotency and retriesMake sure a retried request doesn't happen twice.
- Geospatial indexingFind what's nearby with map grids like geohashes and H3.
- Consistency and the CAP theoremWhat happens when copies of your data can't agree.
- Load balancing and replicationSpread traffic across servers and keep copies so one failure isn't an outage.
- Real-time deliveryPush updates to users the moment they happen, with WebSockets and friends.
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 SWE 4+ YOE, NYC (Nov 2025)
- LeetCode Discuss: Senior SWE, NYC (Nov 2025)
- LeetCode Discuss: Senior SWE, Pune (Nov 2025)
- LeetCode Discuss: Bloomberg phone screen, car and oasis grid
- Jointaro: Senior SWE, US (Jan 2025)
- LeetCode Discuss: SSE virtual onsite, rule-based alert system (2022)
Practice Loop is an independent practice tool and isn't affiliated with or endorsed by Bloomberg.