Infrastructure / Systems Engineer

The problem.

A trading firm's infrastructure fails in ways a web company's does not. A degraded host is worse than a dead one. A clock that drifts quietly corrupts the record. A half-succeeded deploy leaves a position nobody is watching. Systems must fail in a way we chose in advance.

What you would do.

• Own the hosts, the network path to each venue, clock discipline, and the observability that says when any of it is wrong.
• Build deployment that is atomic from the system's point of view, and rollback that has been exercised rather than documented.
• Separate environments properly. Research machines and live machines share nothing that would let a mistake on one reach the other.
• Own the secrets: how they are stored, rotated and audited, and who can reach what.
• Write the runbook, then delete the parts a machine should be doing.

What we would want evidence of.

• You have run infrastructure where downtime had a direct cost, and know what that changed about your decisions.
• You have debugged a problem that only appeared under load, and can describe the tooling you reached for.
• You treat time as a hard problem rather than a solved one.
• You have said no to a convenient network path because of what it would connect.
• You automate the second occurrence, not the tenth.

What would make this a bad fit.

This role is a poor fit if you want a large platform team and a clear boundary around your service. There is neither. The boundary here is the whole firm.

This role is a poor fit if you are looking for scale as the interesting problem. The interesting problem here is correctness under failure. There is not much traffic.