Design a Stock Exchange
Match buy and sell orders in microseconds, in a strict and provable order, never lose a fill, and stay correct when the matching engine dies mid-trade.
3 questions on this site are reported in Bloomberg software engineer interviews. Each has a full reference design (requirements, back-of-envelope numbers, components, user flows and deep dives with interviewer follow-ups). Each one can be walked through turn by turn and then sat as a mock. Patterns covered: order-book, determinism, event-sourcing, low-latency, fairness, sorted-sets, ranking, sharding, time-windows, anti-cheat, market-data, order-management, ledger, websockets, fintech.
Run an AI mock Bloomberg interview →One of these questions, run as a live round in that style, with a debrief at the end.
Attribution comes from public interview guides and candidate reports, not from Bloomberg. It indicates where a question has been asked, nothing more.
Match buy and sell orders in microseconds, in a strict and provable order, never lose a fill, and stay correct when the matching engine dies mid-trade.
Rank 300 M players of a mobile game in real time: the global top 100, your exact rank among millions, your friends, and daily, weekly and season boards that reset on time.
A retail brokerage: live prices to 3 M phones, 20 k orders a second at the open, every share and cent exact.
45–60 minutes, often on real-time financial data close to what Bloomberg runs: price updates fanned out to Terminal users, low-latency messaging, alerting or news pipelines. Some teams instead show their own architecture and ask how you would improve it.
Bringing a generic template. Prompts are reported to sit close to real, latency-sensitive systems and interviewers keep pulling on each choice, so ask about the actual setup and constraints first and propose only what you can defend.
From public interview guides and candidate reports, and Bloomberg’s own interview guidance where it publishes any. Not endorsed by Bloomberg. Formats change; treat it as a prior, not a promise.
Large-company loops run 45 to 60 minutes, expect numbers, and spend most of the time on deep dives. Walk through a question to see how a strong candidate paces the hour, sit the same question as a mock until you can produce the requirements, the estimates and the design without looking, then read the interview framework guide for how to structure the hour. The other questions on the site teach patterns that show up in Bloomberg interviews under different names.
Questions reported in Bloomberg system design interviews include Stock Exchange, Real-Time Leaderboard and Robinhood. Between them they test order book, determinism, event sourcing, low latency, fairness and sorted sets. The reports come from public interview guides and candidate accounts, not from Bloomberg, so practise the patterns rather than memorising one list.
45–60 minutes, often on real-time financial data close to what Bloomberg runs: price updates fanned out to Terminal users, low-latency messaging, alerting or news pipelines. Some teams instead show their own architecture and ask how you would improve it.
Reports say the Bloomberg round weighs 4 things. 1. Low latency and high throughput on data that changes constantly. 2. Fan-out of live updates to a very large number of subscribers. 3. Choices that survive persistent follow-ups: why this one, what fails first, what you rejected. 4. On existing-system prompts: questions about the setup and its goals before any change. Bringing a generic template. Prompts are reported to sit close to real, latency-sensitive systems and interviewers keep pulling on each choice, so ask about the actual setup and constraints first and propose only what you can defend.
Practise the questions reported there out loud, under a 45-minute clock: requirements with numbers first, then estimates, a high-level design, and deep dives into the two or three hardest parts. Start with Stock Exchange: watch a strong candidate answer it turn by turn, then sit it yourself. Then cover the patterns the round leans on (order book, determinism, event sourcing and low latency) with one more question each.