One of four, not one of forty

You would own the architecture of a system and build it. Our tech leads write the architecture documents — the ones that describe a system from several angles and record the alternatives that were rejected — and then write the code that implements them. On a team of four or five, leading is not a separate activity from building.

Current systems in this shape: a payments switch integrating with a national real-time scheme; a fleet platform ingesting telemetry from thousands of devices twice a minute; a credit engine deciding thousands of applications a day.

You have made an architectural decision that turned out badly, and you can describe what you learned without getting defensive about it. You write well enough that other people can follow your reasoning — not documentation as a chore, but thinking made legible. You are comfortable saying you do not know, in front of a client.

This is not a route out of coding. If what you want is to stop building and start directing, you will be unhappy here and we will both know it quickly.

In our domains the failure paths are the product. On one payments platform, dispute-resolution flows accounted for nearly half the certified surface — the paths that run when something goes wrong outnumbered the ones where it goes right.

You would build the things that make failure reproducible: simulators of systems we cannot get access to, suites that provoke timeouts, duplicate responses and late callbacks on demand, and the certification runs that a scheme operator or regulator signs off.

Someone whose first instinct on seeing an interface is what happens if this arrives twice. Automation skill matters and we will ask about it; adversarial imagination matters more and is harder to teach.

You will spend considerably more time thinking about whether money can move twice than about whether a button is aligned. If manual regression testing against a written script is what you enjoy, this is not that job.

Our domains are genuinely complicated. The verbs of a real-time payment scheme. The difference between an operating lease and a finance lease, and why it changes a contract engine. How a commodity auction takes its floor from a government support price. What a warehouse receipt has to say before a bank will lend against it.

The job is to become properly expert in one of those and then write it down precisely enough that engineers can build from it. One market platform's requirements ran to thirty-eight use cases before a line of code was written — and that document is why the build went the way it did.

Curiosity about how an industry actually works, and the patience to keep asking until the edge cases surface. Precise writing — ambiguity in a requirement becomes a defect three months later. And the confidence to say “that contradicts what you told me last week” to someone more senior than you.

This is not a story-writing role taking dictation from a product owner. You will be expected to understand the domain better than most of the people you write for, which takes months and is uncomfortable at the start.

Backend services in Java and Node, React front ends, mobile in Flutter and native, machine learning in Python. On a small team you will touch more than one of those, and the boundaries are softer than they would be in a larger organisation.

Recent work you could have been part of: a credit engine decomposed into four independent analysers; a rule engine that issues commands to physical hardware in the field; an auction platform integrating weighbridges and yard equipment.

You would work alongside people who have been doing this for fifteen years, on a team small enough that they will notice what you do — and small enough that you cannot be parked on something peripheral. Within a year you should be able to explain a real system end to end.

That is the fastest way we know to become good at this, and it is the reason we take people at the start of their careers rather than only hiring experience.

Evidence that you have built something and cared how it turned out. A university project, something you made for yourself, a contribution to somebody else's work — what it is matters much less than whether you have opinions about it.

We will ask you to go deep on something in the interview. Pick whatever you know best — we have no preferred language, and there is no expectation that it is anything we currently use.

We hire for depth, which means an unusual specialism is interesting rather than a problem. Security engineering, data platform work, site reliability, interface design, technical writing — if you are genuinely excellent at something adjacent to what we do, we would like to hear from you.

We do not always have a matching role open. We would still rather hear from good people at the wrong moment than not hear from them at all.