Algorithm Developer

The problem.

Most edge is lost between a research result and a running algorithm. Queue position, partial fills, late cancels, duplicate acknowledgements: none of it appears in simulation unless somebody puts it there. You close that gap in both directions.

What you would do.

• Implement decision logic on the production path with the same numerical behaviour as research. Prove the two agree on recorded data.
• Make the simulator honest about latency, partial fills, rejects, funding, and books that are not what the last snapshot said.
• Instrument so a difference between expected and actual behaviour is visible within minutes, not at end of day.
• Own the parameter surface: what is configurable, what is not, and what happens when an unexpected value arrives.
• Write the tests that would have caught the last defect, and the ones that would catch the next.

What we would want evidence of.

• You have found a discrepancy between simulator and live system and traced it to cause rather than tuned it away.
• You treat a floating-point difference as a defect until it is proven noise.
• You can read a venue's API documentation and say which parts of it are wrong.
• You have written the code that decides, not only the code that reports.
• Your tests fail for the reason they claim to fail for.

What would make this a bad fit.

This role is a poor fit if research is somebody else's problem and implementation is translation. Half the decisions are research decisions made in production clothes.

This role is a poor fit if you are happiest when the specification is complete. Most of the specification is discovered by building it.