What to Expect in the Wealthsimple System Design Interview

Expect a round of about 60 minutes where you present a system you built yourself. Wealthsimple is a Canadian financial technology company based in Toronto, and candidates report this round under the name "Bring Your Own System". Others report the same round as "Bring Your Own Design". You prepare the material in advance, present your architecture, and then defend each decision.

Other candidates report a standard design question instead, and the reported questions are about money: design a banking ledger from a list of transactions, or build a bank system that handles deposits, withdrawals, and stock purchases. Wealthsimple runs many small services, split between Ruby on Rails and Java or Kotlin, with Kafka for events and a GraphQL gateway in front of them. Prepare for money systems rather than for a generic social network.

The Signature Round: Bring Your Own System

Pick a system you designed or led, not one you only used, because interviewers keep asking about details that only the designer would know. Candidates report that weak preparation here is the main reason this round fails.

Prepare five things before the round. First, the requirements the system had to meet. Second, one clear diagram of the services and the data stores. Third, the two or three decisions that mattered, each with the alternative you rejected.

Fourth, the failure cases and how the system behaved in each. Fifth, what you would change now.

The Reported Design Questions

A banking ledger. One reported question asks you to design a ledger from a list of transactions. A ledger is the record of every amount that moved and the balance it produced, which is the core problem at a company that holds client money.

A bank account system. Another reported question asks for deposits, withdrawals, and the purchase of stocks, which combines money movement with orders sent to a market.

A rate limiter for an API. Candidates report this question at the early talent level, where a rate limiter caps how many requests one client may send in a period of time.

Object oriented modeling. The coding rounds test the same skill in small form, and one reported question asks for a class that moves a rover around a grid with clean responsibilities.

A Walkthrough: The Ledger Behind a Trading App

Here is a high level plan for the reported ledger question.

1. Requirements (5 minutes). Clients deposit cash, buy and sell stocks and ETFs, and see a balance that is always correct. Registered accounts, such as a TFSA or an RRSP, have extra rules the system must enforce. Nothing may be lost, and every amount must be explainable later.

2. The ledger model. Use double entry records, which means every amount is written twice, once as a debit and once as a credit, so the two sides always match. Entries are append only, so you correct a mistake with a new entry, never by editing an old one. A balance is the sum of entries, and you cache it for speed.

3. Money movement. Each transfer is a request with a unique key, which makes the operation idempotent. Idempotent means you can repeat the request safely, because the second attempt changes nothing, and networks retry often enough to make that property necessary.

4. The order path. A buy order reserves cash, goes to the market, and settles later. Hold the reserved amount separately from the free balance, and write the final entries only when the trade settles.

5. Failure cases. Define what happens when the market accepts an order and your service crashes. Store the intent before you send the order, then recover from the stored intent. Reconcile your ledger against the external records every day, and raise an alert on any difference.

6. Audit and reporting. Keep every entry for the required retention period, because tax reporting and client statements both read from the same ledger. That makes the ledger the one record the whole product reads from.

7. Scale. Partition by client account, because accounts are independent, and publish events to Kafka so that reporting and notifications read a stream instead of querying the ledger directly.

What the Interviewer Grades

Requirements come first, before any diagram. Name each trade-off out loud, with the reason you chose one side. Correctness with money matters more than elegance, so say where a value could be lost or counted twice.

Candidates report collaborative interviewers who ask for detail, so expect several follow up questions on every answer. Clear speech is graded as well: this round is a presentation, and the delivery counts.

Common Mistakes in This Round

• Storing money in floating point numbers. Store amounts as whole cents in integers, because a rounding error in a ledger is a real financial loss.
• No idempotency. A duplicate transfer caused by one retry is a serious defect in a financial system.
• Presenting a system you did not design. The follow up questions quickly go past what you can know about someone else's work.
• Skipping the regulated parts. Wealthsimple holds registered accounts and must keep records. Mention audit trails and daily reconciliation before you are asked.
• One long monologue. The interviewer wants a conversation, so pause and invite questions after each section.

How to Prepare

• Learn the building blocks. Grokking the System Design Interview covers the queues, caches, and databases that every money system uses.
• Study the hard cases. Advanced System Design Interview, Volume II covers consistency, replication, and failure handling in depth.
• Rehearse your own system out loud. Practice the presentation in under 25 minutes, so there is time for questions.
• See the whole process. This round is one part of the Wealthsimple interview process, which also covers the motivation question and the reported waiting times between rounds.