Network Engineer, Low-Latency

The problem.

Between a decision and a venue there is a network. Most of what people believe about it is inherited rather than measured. Which hop is slow, which route is stable, what variance looks like at the times that matter: those are answerable questions. The answers change what the rest of the system should do.

What you would do.

• Measure the path to each venue continuously. Report distribution rather than a single number.
• Own routing, peering and provider decisions with an argument attached to each.
• Tune the host networking stack where it earns the complexity, and document why.
• Build failover behaviour: what happens when one path degrades rather than fails. That is the harder case.
• Keep the network boundary strict. The site, research machines and live machines are separate zones with no path between them.

What we would want evidence of.

• You have measured network latency properly, including clock discipline, and know where the measurement itself lies to you.
• You have improved a path and can show the distribution before and after.
• You have designed for degradation rather than for failure, and can describe the difference.
• You are rigorous about segmentation and can say what each rule is protecting.

What would make this a bad fit.

This role is a poor fit if you are used to co-location and cross-connects. Our current setup is more ordinary than that. The first work is measuring how much it costs us.

This role is a poor fit if network engineering means configuration rather than measurement. The emphasis here is the other way round.