Experienced Professionals: Engineering Interview Process

Engineering at Citadel Securities runs the systems behind a global market maker. The work is low-latency, high-throughput and rarely static: requirements shift, edge cases surface in production and yesterday’s design must absorb today’s load.

We wanted to create an interview that looks like that work. So instead of a circuit of disconnected puzzles, you spend the day on one real problem. You scope it, build it, defend it and stretch it as new constraints land. The questions get harder because your earlier decisions make them harder.

Strong engineering gets you in the room, but it isn’t the whole job. The people who do best here also understand the business behind the system: what it is really for, which tradeoffs matter and how today’s requirements will change as demands grow. As the tools of the trade keep evolving, that judgment—knowing which problem to solve and why—is what holds its value.

How the Interview Unfolds

One problem, four stages, the same engineer working through all of them. You define the problem, design a system, build it and then defend and extend it as new constraints come in. Early decisions compound: a choice you made in the design hour will shape what you can do in the code review.

We’re less interested in whether you finish than in how your thinking holds up as the problem gets harder. For a stage-by-stage walkthrough, see what to expect at an engineering onsite.

The Four Stages

Requirements and design

You sketch the system end to end: components, interfaces, data flow, the assumptions you’re making and the ones you’re not. Your interviewer will push on edge cases and add requirements you didn’t plan for.

Implementation

You write the code. We care about whether it works, whether someone else could read and extend it and if the abstractions you chose in the design hold up once they meet real input.

Code review

You walk the interviewer through what you built and why. Expect questions about the tradeoffs you made, the ones you didn’t see and a new requirement that tests the limits of your current design. The point isn’t to defend your code; it’s to evolve it.

Discussion

This is a wider conversation about how you work, from scoping ambiguous problems and handling disagreement to moving systems into a production environment with strict reliability requirements.

What we’re looking for

There isn’t a right answer waiting at the end of the problem. We’re watching:

• how you move forward when the spec is incomplete
• what you cut when you can’t do everything
• how you build for the next requirement, not just the current one
• whether your code is something another engineer would want to inherit
• how you react when an assumption you relied on turns out to be wrong

For more on how we think about engineering talent, see what we look for in experienced engineers.