Quiz

Robinhood mobile design quiz

Check the Robinhood mobile design post: quote freshness, order idempotency, fills, buying power, ledgers, notifications, security, and mobile failure modes.

Questions

Est. time

~9 min

Read the post View the series

01
Boundaries

Why should quote display and order submission be separate systems?
Options for question 1
1. A. Because quotes are a read-heavy freshness problem, while order submission is an auditable financial transaction.
2. B. Because the mobile app should calculate final order prices locally from the latest chart candle.
3. C. Because WebSockets cannot be used for any trading product.
4. D. Because separating them lets the app skip server-side risk checks.
Correct answer: A.

Quote display can be optimized for fanout, freshness, and rendering. Order submission needs idempotency, authorization, risk checks, auditability, and durable state transitions. Mixing the two makes the system less safe.
02
Idempotency

The user taps Submit, the server accepts the order, but the mobile response times out. What should the app do next?
Options for question 2
1. A. Mark the order as failed and let the user submit a new order immediately. This sounds simple in the UI, but it can create a duplicate trade when the first request actually succeeded.
2. B. Query order status using the same client operation ID and treat the result as unknown until the server answers.
3. C. Assume the order filled and update the portfolio locally.
4. D. Delete the pending order row because the app did not receive a response.
Correct answer: B.

A timeout after submit is unknown, not failed. The app should retry or query with the same operation ID so the server can return the existing order instead of creating a duplicate trade.
03
Buying power

Why should buying power be computed on the server instead of trusted from the mobile cache?
Options for question 3
1. A. Because buying power may depend on pending orders, unsettled funds, restrictions, margin rules, account type, and risk checks.
2. B. Because the mobile app cannot display cash balances at all.
3. C. Because buying power is always equal to the user's last portfolio value.
4. D. Because buying power only changes once per market day.
Correct answer: A.

Buying power is a policy-heavy projection. The app can display it, but the server should compute and refresh it before sensitive actions like trade submission.
04
Notifications

A push notification says an order filled. What should happen when the user taps it?
Options for question 4
1. A. Use the push payload as final proof and update positions without a network call. This is tempting for speed, but old pushes can be delayed, duplicated, or tapped after the state has changed.
2. B. Open the order detail screen, then fetch fresh server state for the order and portfolio.
3. C. Ignore the push because order events can only be shown through WebSockets.
4. D. Create a new order event on the device so the backend can catch up later.
Correct answer: B.

Push is a routing hint, not durable truth. It can be delayed, duplicated, or stale, so the app should fetch authoritative state after navigation.
05
Freshness UX

What is the safest behavior when the quote stream misses heartbeats on an instrument detail page?
Options for question 5
1. A. Keep showing the old price as if it is live so the UI does not feel broken. This keeps the page visually calm, but it is dangerous because the user may think an old quote is still live.
2. B. Immediately hide the whole instrument page until the stream reconnects.
3. C. Mark the quote as stale, attempt reconnect and resync, and refresh before enabling sensitive actions.
4. D. Switch the chart to a local simulated price until the server returns.
Correct answer: C.

The UI should stay useful but honest. Stale indicators, reconnect, resync, and pre-submit refresh keep the user from acting on misleading data.
06
Order state

An order partially fills while a cancel request is pending. What should the system show?
Options for question 6
1. A. Only the cancel event, because partial fills make the UI too confusing.
2. B. Only the fill event, because cancel requests are not important after a fill.
3. C. Both events in the order timeline, with positions updated for the filled quantity and remaining quantity handled by the cancel result.
4. D. A generic failed state until support manually reviews the order.
Correct answer: C.

Order state is not a simple success or failure flag. Partial fills, pending cancels, accepted cancels, and remaining quantity all need explicit state.
07
Ledger

What is the relationship between the ledger and the portfolio screen?
Options for question 7
1. A. The portfolio screen is the ledger because it shows current positions.
2. B. The ledger records durable financial effects, while the portfolio is a user-facing projection derived from authoritative events.
3. C. The ledger only stores chart prices and has no relationship to positions.
4. D. The mobile app should write directly to the ledger after a fill animation.
Correct answer: B.

The ledger should be durable and auditable. Portfolio views are projections that should reconcile with orders, fills, cash, positions, and back-office records.
08
Realtime scaling

Why should the quote gateway know which symbols are visible on the device?
Options for question 8
1. A. So the server can send every tick for every symbol in the market to every phone. That would waste bandwidth, battery, rendering work, and server fanout for data the user cannot currently see.
2. B. So the app can avoid all server calls and compute quotes locally.
3. C. So visible screens can receive appropriate updates while offscreen watchlist data can be coalesced or refreshed less often.
4. D. So users cannot add more than one symbol to a watchlist.
Correct answer: C.

Mobile clients do not need tick-level updates for every symbol at all times. Visibility-aware subscriptions reduce fanout, rendering work, and battery cost while keeping important screens fresh.
09
Security

Which action is a good candidate for step-up authentication in a trading app?
Options for question 9
1. A. Changing app theme from light to dark. This adds friction in the wrong place and teaches users that security prompts are arbitrary noise.
2. B. Scrolling a public education article.
3. C. Viewing a cached watchlist while offline.
4. D. Adding a new bank account or submitting a high-risk order from a new device.
Correct answer: D.

Step-up checks should protect sensitive actions such as bank linking, withdrawals, device changes, and high-risk trading flows, especially when device or session risk changes.
10
Degraded mode

Market data is available, but order submission is unavailable. What is the most honest product behavior?
Options for question 10
1. A. Pretend submission works and queue all orders locally for later. This makes the app feel available, but it is unsafe because the server has not accepted the financial transaction.
2. B. Enable read-only mode with clear messaging that trading is temporarily unavailable.
3. C. Hide all prices because orders cannot be placed.
4. D. Let the client route orders directly to an exchange.
Correct answer: B.

A read-only degraded mode keeps the app useful while telling the truth. Local queuing of financial orders without server acceptance would be unsafe.
11
Observability

Which metric best captures the mobile user experience after an order submit?
Options for question 11
1. A. Number of CSS classes on the trade ticket.
2. B. Average size of the watchlist payload only.
3. C. Time from tap submit to trustworthy user-visible order state, including accepted, rejected, or checking status.
4. D. Total count of symbols available in search.
Correct answer: C.

Backend latency matters, but the user cares when the app reaches a trustworthy state. That includes mobile request timing, server acceptance, risk decision, and UI reconciliation.
12
Auditability

Which data is useful to store with order intent for audit and debugging?
Options for question 12
1. A. Only the final portfolio value after all positions update. That final number is useful, but it is not enough to reconstruct what the user saw, confirmed, and triggered.
2. B. Only the color of the Buy button shown to the user.
3. C. Only the device battery level because order systems are backend-only.
4. D. User confirmation context, quote context, device/session metadata, app version, risk decision, and routing events.
Correct answer: D.

A brokerage-like system needs a durable trail of what the user saw, what they confirmed, how the system evaluated the order, and what happened after routing.

Progress

0/12 answered

Robinhood mobile design quiz

Why should quote display and order submission be separate systems?

The user taps Submit, the server accepts the order, but the mobile response times out. What should the app do next?

Why should buying power be computed on the server instead of trusted from the mobile cache?

A push notification says an order filled. What should happen when the user taps it?

What is the safest behavior when the quote stream misses heartbeats on an instrument detail page?

An order partially fills while a cancel request is pending. What should the system show?

What is the relationship between the ledger and the portfolio screen?

Why should the quote gateway know which symbols are visible on the device?

Which action is a good candidate for step-up authentication in a trading app?

Market data is available, but order submission is unavailable. What is the most honest product behavior?

Which metric best captures the mobile user experience after an order submit?

Which data is useful to store with order intent for audit and debugging?