Research Platform Engineer

The problem.

The rate at which the firm learns anything is set by how long a well-controlled experiment takes, and how easy it is to run a badly controlled one by accident. Both are platform problems. The trial ledger, reproducibility of a run, a leaked feature raising an error rather than a good result: those are things you build.

What you would do.

• Own the experiment runner: deterministic, reproducible from a recorded configuration, and cheap enough that nobody skips a control to save time.
• Make the trial ledger structural. Every configuration evaluated is counted, and the count cannot be reset by the person it embarrasses.
• Build the guardrails that catch leakage, look-ahead and a split that does not honour the embargo, as failures rather than warnings.
• Keep results addressable: what was run, on what data, by whom, and what the code was at the time.
• Shorten the loop between a question and a defensible answer, and measure whether you did.

What we would want evidence of.

• You have built a platform researchers actually adopted, and can say what you removed to get there.
• You understand why an unresettable counter is a design decision rather than a database choice.
• You have made a class of error impossible rather than documented.
• You can work with people whose priority is their result and whose patience for tooling is finite.
• You measure whether your platform helped rather than assuming it did.

What would make this a bad fit.

This role is a poor fit if you want to build the platform to completion before it is used. It will be used before it is ready, every time.

This role is a poor fit if research tooling feels like a support function. It is treated here as an input to the edge and will be argued with accordingly.