Quantitative Developer

The problem.

Research produces something correct in a notebook. Production needs something correct at three in the morning. The gap is numerical detail: how money is represented, what happens at a rounding boundary, whether a value read back from the database is the value that went in. Getting this wrong is silent. That is what makes it dangerous.

What you would do.

• Build the shared libraries research and production both use, so there is one implementation of a calculation rather than two that agree by coincidence.
• Hold the line on monetary arithmetic: no capital sizing in a double; scaled integers read back through paths that survive values above the safe range.
• Turn a researcher's prototype into a maintained component, with tests that pin the behaviour they relied on.
• Own the backtester's fidelity: what it models, what it does not, and where a user would be misled if they did not know the difference.
• Keep the developer experience good enough that a researcher writes correct code by default rather than by discipline.

What we would want evidence of.

• You know why 0.4 + 0.3 is not 0.7, and you have found that in production rather than in a lecture.
• You have designed an interface that made a class of mistake impossible rather than discouraged.
• You have maintained code you did not write, and it changed how you write your own.
• You can say no to a convenient shortcut in a way that leaves the researcher still willing to talk to you.
• You test the boundary rather than the middle.

What would make this a bad fit.

This role is a poor fit if you want to be the person who has the ideas. Influence here is over how well ideas can be expressed, not which ones are tried.

This role is a poor fit if a strict type system feels like an obstacle. It will feel like one every day.