Our experienced engineering onsite is one problem, worked continuously over several hours, in four stages: design, programming, code review and discussion.
The point of running it this way is that each stage carries the last one forward. The design you sketch is the design you implement. The code you write is the code you review. The decisions you made in the first hour come back in the third, usually because a new constraint just made one of them harder to defend. That sequence is the interview. It’s how we get to watch a candidate’s thinking move.
So, the day isn’t built around producing a finished system, and candidates who optimize for that tend to do worse. What we’re trying to see is how you work when the problem keeps changing underneath you, which is what the job actually is.
Before You Begin
The day opens with a short introduction from your interviewers, followed by the problem itself. It’s grounded in something real, such as a simplified matching engine or an order book, rather than an abstract puzzle.
A few things are said out loud before you start, because they matter: you’ll be on this one problem the whole day, the spec you’re given is deliberately incomplete and you’re expected to ask questions and name your assumptions rather than wait for the gaps to be filled in. Candidates who treat the first ten minutes as a passive briefing usually lose ground they don’t get back. Candidates who start questioning the problem are already doing the work.
What we’re watching for here: whether you push on the spec before you start building against it.
Requirements and Design
The first stage is design. You define the system before you write any of it.
That means clarifying the requirements, naming the gaps, deciding which constraints matter and which don’t and outlining how the pieces fit together. The good designs we see aren’t the ones that cover every detail in the first hour. They’re the ones that pick a clean structure, make their assumptions visible instead of burying them and leave room for the parts you haven’t thought about yet. We’ll introduce those later.
A note on approach: we’d rather you outline a design you can defend than enumerate every option you considered. Talk through the decisions you’re making and why. If you’re choosing between two approaches and the tradeoff isn’t obvious, say so. That’s the conversation we want to have with you.
What we’re watching for here: whether your design can absorb a new requirement without being torn down.
Programming
Next you implement it. This is where the design stops being a diagram and becomes real, and where the questions you deferred during design have to be answered. The interfaces you drew get exercised. Edge cases you anticipated show up, and so do the ones you didn’t.
In the matching engine version of the problem, that might mean handling order prioritization, partial fills and keeping state consistent as updates come in. In a different version it’s something else, but the shape of the work is the same: you build the core, test as you go and debug what surprises you.
Use whatever language you’re most fluent in; we’re not evaluating choice of language. This is true for most roles, though some require candidates to interview in C++; you’ll be told in advance if that applies to yours. What we care about is whether the code is clear enough for someone other than you to read, whether it’s faithful to the design you defended an hour earlier and whether you can reason about it under pressure when something behaves unexpectedly.
What we’re watching for here: code that’s clear over code that’s clever, and how you respond when reality pushes back on your design.
Code Review
After you’ve built something, you review it with us. You walk through the system, explain the calls you made and we pressure-test it together: different inputs, different loads and different assumptions than the ones you started from.
Expect to be asked where it breaks. Expect to be asked what you’d do differently if you started over knowing what you know now. Expect at least one new requirement that doesn’t fit cleanly into what you built. Because that’s how requirements arrive in real systems, and we want to see how you absorb one. The strongest candidates here are the ones who can be honest about a limitation without getting defensive and who can extend their own work without quietly rewriting the parts they wish they’d done differently.
What we’re watching for here: whether you understand your own system well enough to evolve it and if you can take in new information in stride.
Discussion
The last stage steps back from the code. You talk through the day with us: the tradeoffs you made, the decisions you’d revisit and where you’d take the system from here if you had another week with it.
It’s also where we get to see how you work with other engineers, how you handle disagreement on a design and what kinds of problems you gravitate toward. This is the most open-ended part of the day by design. At this point you’ve shown us how you build; now we get a clearer read on how you’d build alongside the rest of the team.
What we’re watching for here: whether you can assess your own work honestly, and if the way you talk about engineering matches what you just demonstrated.
How the Day Fits Together
None of these stages reset. You don’t get a fresh problem for the implementation round, and you don’t get a fresh implementation for the review. The design you wrote is the design you build against. The code you wrote is the code we read together and the new constraints we introduce mid-day land on the system you already have.
That’s deliberate. Real systems get built one decision at a time, with each decision constrained by the last and usually with someone changing the requirements halfway through. We’d rather see how you operate inside that loop for a few hours than score you on isolated answers to isolated questions.
By the end of the day, you’ll have worked through an incomplete problem, made decisions as the constraints around you moved, built and tested something real and walked us through how you’d evolve it. You should leave with an honest picture of what engineering work looks like here, because the interview is a close approximation of it.
