Core / Low-Latency Software Engineer

The problem.

On the order path, being slightly wrong is expensive and being slightly slow is also expensive. The path must be correct under partial failure, idempotent on re-entry, and fast enough that research assumptions still hold. Those three requirements disagree. Resolving the disagreement is the work.

What you would do.

• Own the market-data handler, the order manager and the execution path end to end, including paths that only run when something has gone wrong.
• Build timing instrumentation before optimisation. Report percentiles rather than averages.
• Make restart safe: state that survives a kill, an intent identifier derived from its own content, and re-entry that a venue rejects as a duplicate rather than filling twice.
• Profile before you rewrite. Keep the profile that justified it.
• Push into a compiled language where the measurement says to. We start on TypeScript and Bun and add C++ where the profiler points, not fashion.

What we would want evidence of.

• Your views on crash recovery came from an incident rather than an article.
• You have measured a latency distribution and can say what was in the tail and why.
• You have made something faster and can show before and after on the same workload.
• You have written the code that handles the second acknowledgement of the same order.
• You are comfortable in a strictly typed codebase with no escape hatches, and you do not miss them.

What would make this a bad fit.

This role is a poor fit if low latency means microseconds to you and nothing above that is interesting. Our current floor is higher. The first thing you would do is measure how much higher.

This role is a poor fit if you want to rewrite the system in a language you prefer without a profile that says to. Without it the answer is no.