How the interviewer opens it
“Design a stock trading app like Robinhood where users follow live prices and submit buy and sell orders to exchanges. Users should also be able to see their portfolio and track what happened to each order.”
The prompt is vague on purpose. The first few minutes are yours: narrow it to the core features and agree on the numbers before you draw anything.
What to clarify first
- Instruments and order types
- Users and subscriptions
- Trading volume and read:write mix
- Market data
- Latency
- Buying power and settlement
- Execution provider
- Consistency versus availability
- Durability and audit
- Scope boundaries
The answers stay with the interviewer. In a SysRound round, Alex answers them as an interviewer would.
Scope of a strong answer
Core requirements
- Show live stock quotes for watchlists and portfolios
- Submit and cancel buy and sell orders routed to an external execution provider
- Track order acknowledgements, partial fills, rejections, and cancellations
- Show holdings, available cash, reserved funds, and portfolio value
Usually out of scope
- Building an exchange or matching engine
- Account opening, identity verification, deposits, and withdrawals
- Margin, short selling, options, crypto, and fractional shares
- Implementing clearing, settlement, corporate actions, and tax reporting
What interviewers probe
- Cash and share reservations across concurrent orders
- A user can submit several orders before any execute. Fills occur later at external prices, and displayed portfolio state can lag. Checking a cached balance or reserving against an unbounded market price can create an unfunded trade.
- Order lifecycle when execution outcomes are uncertain
- The application cannot atomically commit with an exchange. A timeout may hide a live order, cancellations can race with fills, and duplicate or reordered reports must not create duplicate trades or release resources too early.
- Live quote fanout without misleading or blocking users
- A modest feed becomes millions of downstream deliveries, concentrated on a few symbols. Intermediate prices can be dropped, but stale prices must be visible and financial state updates need a different recovery path.
Common mistakes
- Designing an exchange matching engine instead of a brokerage application that routes orders externally.
- Treating accepted, acknowledged, filled, and settled as the same state.
- Checking displayed portfolio balances without atomic reservations, or treating a quote-based buffer as a guaranteed market-order spending limit.
- Blindly retrying an uncertain external submission or treating a cancellation request as proof that no more fills can arrive.
- Using mutable cached balances as the source of truth, with no execution deduplication, ledger, or provider reconciliation.
- Focusing only on WebSockets while ignoring subscription fanout, slow consumers, stale prices, and durable recovery of account updates.
The bar by level
- Senior (L5/E5)
- Defines the account transaction boundary, enforceable market-buy spending limits, ledger and reservation updates, durable dispatch, and a precise partial-fill/cancel lifecycle. Resolves ambiguous provider outcomes without blind retries, separates portfolio projections from buying power, and sizes quote fanout with bounded slow-client behavior.
- Staff (L6+/E6+)
- Establishes end-to-end financial invariants across internal commits and external execution. Explains what cannot be made exactly once, how routing ownership and provider sessions are fenced, when to halt trading, and how reconciliation resolves gaps. Addresses regional recovery without duplicate live orders, auditability, hot-symbol distribution, and capacity limits without turning the design into a matching engine or an unnecessary global transaction system.