Quantitative Developer

Role Overview

The Quantitative Developer builds and runs the code that turns StratiFi's risk methodology into scores customers see. It is the engineering half of Financial Engineering — the half that has never been staffed.

The Financial Engineering Manager decides what a correct score is. The Quantitative Analyst adjudicates individual securities. This seat writes the production code, builds the validation harness, and owns scoring integrity in production. Today that work falls to the Principal Engineer by default, which is why PRISM scoring has been re-fixed eight times over sixteen months.

Seniority: senior. The first ninety days are spent establishing what undocumented production code actually does, then making it safe to change — work that needs someone who has carried production systems before, not someone being taught to.

Risk scoring is the immediate mandate, not the ceiling. Scoring is the critical work today, but this is a functional connector across the product, and the person in it will need to be versatile — moving onto other analytical areas over time rather than staying narrowly on scoring. We value breadth: candidates who have worked across several areas, not only one. The role generates a long list of requirements and few people will have all of them; the ones that matter most are called out as the gate and the core non-negotiable below.

5 Core Responsibilities

1. Risk Model Implementation

Own the production code that computes risk scores. Turn the methodology the Financial Engineering Manager defines into code that runs correctly, repeatably, and at scale.

Write and maintain the production code that implements PRISM and related risk calculations

Translate a written methodology into code, and raise it when the methodology is ambiguous rather than guessing

Keep scoring runs idempotent and re-runnable, so a failed batch can be replayed safely

Own performance of the scoring path as portfolio and security volume grows

Give input into the design and architecture of the calculation and analytics code as flexible, well-organized modular libraries that the Frontend and other teams can build on — contributing to the wider system architecture, not just consuming it

Work inside the existing production codebase to the same standard as any other engineering seat — tests, CI, code review. Research-quality code does not ship from this seat

Take risk-model implementation off the Principal Engineer, who has carried it by default

1. Reference-Set Harness & Validation Engineering

Build and maintain the harness that runs the classification and scoring reference set on every model or taxonomy change.

Build the harness that compares engine output against the adjudicated reference set

Wire it into CI so that a change cannot ship without it running

Report coverage and drift in a form the Financial Engineering Manager can act on

Keep the harness fast and deterministic enough that its results are believed

Expected values belong to the Financial Engineering Manager. This seat builds the mechanism, not the answers

1. Production Monitoring, Debugging & Score Integrity

Diagnose scoring failures in production — both the code path and the numbers — monitor the scoring path, and establish when a failure started.

Diagnose failures across the scoring pipeline, from ingestion through to the score a customer sees

Own production monitoring, debugging and data integrity for the scoring path — partner with the Observability Engineer so scoring is watched continuously and the numbers it produces stay trustworthy

Distinguish a code defect from a data defect from a methodology gap, and route accordingly

Reproduce customer-reported score anomalies against real portfolio data

Build the diagnostic tooling that lets others answer scoring questions without asking this seat. Being the only route to an answer is the failure mode this seat exists to remove

Fix the class, not only the instance, and record which was done

1. Routine Classification Adjudication

Rule on straightforward classification questions so they do not queue behind the Financial Engineering Manager.

Rule on unambiguous cases — a US utility classified as international equity, an implausible score on a cash-equivalent

Escalate genuinely hard calls: structured products, buffered and defined-outcome ETFs, private assets

Record a rationale for every ruling so the reference set carries its reasoning

Reduce the number of questions that require the manager, measured over time

Never rule on methodology — only on its application

1. Model Change Governance & Deployment Safety

Apply model and classification changes safely, with a known blast radius and a verified way back.

Run every change against the reference set before it is applied to production

Produce a blast-radius estimate — how many securities, portfolios and customers a change moves

Maintain a verified rollback path and test that it works rather than assuming it

Document what changed, why, and what it moved, in a form an auditor could follow

Stage changes so a large reclassification is observable before it is universal

9 Required Skills & Competencies

1. Production Software Engineering

This is the gate, and it is evidence-based: the candidate must have built production code that was deployed and is in use. Not a prototype, not a notebook, not a proof of concept that never shipped — software other people depend on, that they maintained after release. The core non-negotiable is experience implementing and managing a complex analytical software product, working with numerical data and large data sets. Writes production-quality code in an existing codebase to the same standard as any other engineering seat: tests, code review, CI, migrations. Fluent with data tooling (such as pandas/numpy) and SQL at portfolio scale. Our production stack is Python/Django — experience in any production language counts, and it is learnable by a strong production engineer; prior Python/Django is a plus, not a gate. A strong quant who writes research-grade code is the specific mis-hire this role cannot absorb.

1. Application Architecture, Software Design & Safe Change in an Inherited System

Application architecture and software design: designs maintainable, well-structured software and makes sound architecture and design decisions for large-scale, long-lived systems. Gives input into the design of flexible, well-organized modular libraries that the Frontend and other teams can use, and knows enough of the wider system architecture to do so — while the specialist contribution is the design of the calculations, business logic and analytics. Establishes what production code actually does before changing it, then changes it without breaking anything. This seat inherits a rules engine whose requirements were never written down — the first months are archaeology as much as construction. Reconstructs real behaviour including the paths nobody documented; writes the requirement down after establishing it rather than assuming the code is correct; resists rewriting what they have not yet understood. Writes migrations and backfills that are re-runnable and reversible, estimates blast radius before applying, and stages a large reclassification so it is observable before it is universal. Has done this on live financial data and knows what it costs to get wrong.

1. Testing & Validation Engineering

Builds reference-set harnesses and golden-data tests, and wires them into CI so a change cannot ship without them. Understands why a unit test proving the code ran is not evidence the number is right — and why a test that mocks the writer is not coverage of the write.

1. Systems Thinking & Production Debugging

Systems thinking: reasons about the whole system — how data flows, where failure propagates, and how a change ripples across scoring, data, and downstream consumers. Diagnoses live scoring failures methodically and establishes when a failure started. Builds the tooling that lets others answer questions without asking this seat — being the only route to an answer is the failure mode this role exists to remove. Communicates status honestly while a problem is unresolved.

1. Instrument Classification & Market Structure

Financial-instrument fluency, with deep US-market knowledge a strong plus rather than a gate. Knows how instruments are classified well enough to recognise when a classification is wrong on sight — why a fixed annuity is not an equity, why a buffered ETF is not a plain index fund, and why a CD is not a bond, because these are the errors this platform actually produces. Deep working knowledge of the US market specifically — how instruments are structured, identified and traded, how the data arrives, and the identifier schemes and taxonomies data providers use — is a strong plus: a strong engineer with real instrument fluency ramps on the US specifics on the job. What is required is the underlying instinct, not prior US coverage.

1. Risk Modelling, Scoring & Tax-Aware Analytics

Understands volatility, correlation, concentration and tail measures well enough to implement them correctly and to notice when a result is implausible. Understands how a scoring methodology composes from factors, and how a proxy stands in for an instrument with no history. Not just another developer: brings a working knowledge of the business logic and methodologies — or a clear aptitude to pick it up quickly — and enough hands-on exposure to specific financial products to reason about them. Exhaustive product coverage is not required; some real experience is enough. Depth of methodology belongs to the Financial Engineering Manager; this seat needs enough to catch a wrong answer and to implement a right one. Tax-aware analytics — after-tax return, cost basis, tax-aware sequencing and loss harvesting — is forward-looking: not built today, so bring the capability, expect to build it rather than maintain it.

1. Model Documentation & Technical Communication

Writes so a methodology decision survives the person who made it. Explains a scoring result to someone who is not a quant, and produces the written record an auditor or an enterprise prospect's diligence can follow.

1. Escalation Judgment

Knows which classification calls to make and which to escalate — and errs toward escalating when a call would set precedent.

1. AI-Assisted Delivery Discipline

The skill is specification and verification, not tool usage. A candidate who directs AI tooling well gets compounding leverage on this seat in particular: much of what it inherits is archaeology, harness construction and repetitive rule work, all of which parallelise once the contract is written down.

What we assess is the quality of the ask — do they define the contract, the invariants, the design pattern and the failing test before generating, and do they check the output against something other than the tests that were generated alongside it. Someone who does this well produces correct work several times faster. Someone who does not produces plausible, wrong work several times faster, and on this seat that is the more expensive outcome: a wrong score raises no exception. It renders, and it reaches a client or an audit.

Throughput is not the measure. Agent count, tokens, velocity, lines shipped — none of these is evidence of anything without the specification that produced them.

Test-first is verifiable and should be verified from commit history, not taken on assurance

The candidate must be able to explain code they delegated to the same depth as code they wrote. This seat reviews, debugs and defends production numbers; code it cannot account for is code it cannot own

Existing conventions are a constraint to be stated up front, not something to be rediscovered after an agent has invented a parallel mechanism beside them

Absence of AI fluency is not disqualifying. A strong engineer with sound specification instincts acquires it in weeks. Treat it as a tiebreaker, never as the gate — judgment, domain knowledge and verification discipline are the parts that do not transfer quickly

What this seat walks into

PRISM scoring has been repeatedly re-fixed over the last year and a half each marked done, each returning, each handled by the Principal Engineer because no one else could. That is the work this seat takes over.

No reference-set harness exists. The historical classification tickets are the starting corpus, and the validation endpoints it needs are scoped but unbuilt

A single recent taxonomy change moved more than ten thousand securities with no pre-apply comparison and no rollback

Financial data is the largest defect class in the platform — close to a third of everything customers report

No internal engineer works on it today. The whole team is a vendor

First 90 days, roughly

Weeks 1–2 — take one live PRISM defect end to end and establish whether the cause is code, data or methodology

Weeks 3–6 — build the reference-set harness and wire it into CI as non-blocking

Weeks 7–12 — make it a required check, and take scoring incidents off the Principal Engineer

Boundaries — what this seat does not own

These are the seats that own the final call in each area. This seat partners actively with each of them — contributing input, design and challenge rather than taking requirements blindly or deferring wholesale. It is a functional connector, not a downstream recipient.

Risk methodology and what a correct score is — Financial Engineering Manager

Curating the reference set and hard classification rulings — Quantitative Analyst

The canonical entity model — Principal Engineer

Production monitoring infrastructure and drift detection — Observability Engineer (this seat partners on monitoring the scoring path and owns the integrity of the numbers it produces)

Release gating — Quality Engineering Manager

Target Companies

https://stratifi.atlassian.net/wiki/external/M2FlZWM5NzdiNjEyNGE0YWJkMTExNzNhNjc2MGEzNGE