Quant Developer

Stage by stage

Close each stage out loud, so they always know where you are.

1. 1Operations and their speed8 minThose are the operations and the time each message gets. Now the data structures.
2. 2Data structures12 minThat's the structure for price levels, orders and cancels. Next, the matching rules.
3. 3Matching rules8 minThose are the rules, worked on an example. Now what goes out on the feed.
4. 4The feed9 minThat's what we publish and how a client recovers. Last, how I'd test it.
5. 5Testing8 minThat's how I'd come to trust it. Happy to write the core next.

How people lose this round

• I'd start with a lock-free concurrent tree.A clever structure before the requirements worries an interviewer. One thread per book is usually simpler and faster.
• To cancel, I'd scan the level for the order id.Cancels are a large share of messages, and a busy level holds thousands of orders. Keep an index from id to order.
• The buyer pays their limit price.Trades print at the resting orders' prices. A buy that sweeps two levels pays each level's price.
• I'd measure the average latency.The rare slow message is what hurts, and an average hides it. Give the 99.9th percentile and the maximum.
• Unit tests for each function will cover it.Order book bugs live in sequences of messages. Check invariants and compare against a simple reference on random streams.

Stage by stage

Close each stage out loud, so they always know where you are.

1. 1The situation in one line15 secThat's the situation. Here's what I did.
2. 2What you did60 secThat was my part. Here's how it turned out.
3. 3The result, with a number30 secThat's the result. And here's what I'd change.
4. 4What you'd change15 secThat's what I'd do differently. Happy to go into any part.

How people lose this round

• We decided, we built it, and we fixed it.They're hiring you. With "we" all the way through, they can't tell what you did.
• I can't think of a real failure.Everyone has one. It sounds like you don't notice your mistakes, or won't own them.
• In the end, they saw I was right.A story you win outright sounds one-sided. Show what you took from the other side.
• So to give you some background, the company had three teams...Long setup uses up your time and their attention. One line of situation, then what you did.
• It worked out, so it was the right call.A good result can come from luck. Say why the decision made sense with what you knew then.

Stage by stage

Close each stage out loud, so they always know where you are.

1. 1The problem2 minThat's the problem and why it mattered. Here's the main choice I made.
2. 2Your choice and its alternative3 minThat's what I chose and what I turned down. Now what broke.
3. 3What broke2 minThat's what went wrong and how I found it. Here's where it ended up.
4. 4The result2 minThat's the result, against where we started. Last, what I'd do next.
5. 5What's next1 minThat's what I'd do next. Happy to go further on any part.

How people lose this round

• The stack was Python, Postgres, Airflow and Docker.A list of tools isn't a decision. Say what you chose, what you turned down, and why.
• Nothing really went wrong.Every real project breaks somewhere. It sounds like you didn't build much of it, or didn't watch it run.
• We got 95 percent accuracy.Without the baseline or how rare the positives are, the number means nothing. Say what the simple approach scored.
• I tried logistic regression, then trees, then a neural net.A list of tries isn't a story. Say what each one taught you and why you moved on.
• The team built it, and I helped out.Too modest to score. Name the parts that were yours.