What to Expect in the Polymarket System Design Interview

Expect a design round based on Polymarket's own exchange, about 60 minutes long, which is typical for a company of this size and not confirmed. Polymarket runs a prediction market where people trade on the outcome of real events, with orders matched off-chain in a matching engine that Polymarket operates and trades settled on the Polygon blockchain through smart contracts.

Polymarket does not publish its interview questions, and candidate reports are scarce, so the question types below follow the systems its job postings describe. Expect a market-shaped problem rather than a generic social network question, and expect correctness to be graded with the architecture.

The Question Types

The matching engine. Design the service that keeps an order book, which is the list of open buy and sell orders sorted by price, and pairs buyers with sellers. The hard parts are ordering, fairness, and speed under a sudden surge of orders.

Off-chain matching with on-chain settlement. Design the path from a signed order to a settled trade, where users sign orders without paying a transaction fee and an operator matches them, then submits the matched trades to a smart contract. The hard parts are consistency between the two worlds, retries, and failed transactions.

Real-time market data. Design the feed that pushes price and order book updates to millions of viewers. The hard parts are fan-out, which means sending one update to many connected clients, along with ordering and staying cheap during a major news event.

Market resolution. Design the pipeline that decides the outcome of an event and pays the winners, given that Polymarket uses an outside oracle, a service that reports real-world facts to the blockchain. The hard parts are disputes, delays, and paying out the correct token holders exactly once.

Integrity and monitoring. Polymarket's product depends on trustworthy prices, so measurement questions are likely, such as how you detect a stuck settlement, a stale price feed, or unusual trading, and expect to discuss alerts, reconciliation, and audit logs.

What the Interviewer Grades

Correctness matters more than unusual parts, so state requirements first, including order volume and failure cases, and name your trade-offs out loud. Connect each choice to the money, because a double settlement pays someone twice, and defend each choice with a reason, since interviewers at small companies usually ask for more depth.

A Walkthrough: Design a Prediction Market Exchange

Here is a high level plan for the signature question.

1. Requirements (5 minutes). Many markets, each with a yes and a no outcome, where users place limit orders, with matching that must feel instant and settlement that must be verifiable and must never pay twice.

2. Order intake. The user signs an order in the browser, and the API checks the signature, the balance, and the market state before valid orders go to the matching engine for that market.

3. The matching engine. Keep one order book per market in memory, sort bids and asks by price and then by arrival time, and use a single thread per market to remove race conditions. Write every accepted order to a durable log before matching it, so a crash loses nothing.

4. Settlement. Matched trades go to a queue, where a settlement service batches them and submits them to the smart contract. Store the transaction id with each trade, so that a failed transaction can be retried with the same id and no trade settles twice.

5. Market data. Publish each book change to a message bus, let a fan-out layer push updates to connected clients, and cache the current price per market for the many readers who never trade.

6. Resolution and payout. When the event ends, the oracle reports the result. Wait for the dispute window to close, then allow holders of the winning token to redeem collateral, and reconcile the total paid against the total collateral held.

7. Scale and safety. Shard by market, put the busiest markets on their own hardware, rate limit order submission per user, and alert on any gap between matched trades and settled trades.

Common Mistakes in This Round

• Starting with the blockchain. The chain is one box in the diagram, while the matching engine, the queue, and the reconciliation are what the interview tests.
• Ignoring double settlement. Retries without a stable trade id are a serious miss.
• No surge plan. A large election night can multiply traffic in minutes, so say how the system degrades slowly, not suddenly.
• No reconciliation story. If you cannot say how you would prove the books balance, the design is unfinished.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers queues, caches, and databases, which every exchange design uses.
• Go deeper on hard cases. Advanced System Design Interview, Volume II helps with ordering, replication, and failure handling.
• Rehearse the exchange walkthrough. Practice the seven steps above out loud in under 40 minutes.
• See the full loop. The design round is one stage of the Polymarket interview process, alongside the motivation question and the waiting time after each round.