Company
Careers
What we are building, how the engineering and research work is organized, the roles that are open, and how to apply.
No open roles listed
And no invented ones. A fabricated opening wastes the time of exactly the people you most want to hear from, and it is discovered on the first reply.
What is here instead is an accurate description of the work, which self-selects better than a job description does.
Roles listed
0
Invented roles
0
What the work is actually like
Six things about this that would put some people off, said on purpose.
A careers page normally lists what is appealing. These are accurate, and three of them are things a hiring page would never volunteer — which makes them the useful part, because they are what a candidate needs in order to decide.
- Correctness before completeness, on a schedule that resents it
- Every number on this site is computed from a fixture rather than typed, because a heading once read "six frameworks" while the estate held eight and survived 533 passing tests. That discipline is the job, and it costs real time on every page.
- You will be asked to make the product look worse
- The trust page opens with the certifications we do not hold. The integrations catalogue keeps its unavailable entries. The pricing page has no table. Somebody had to decide each of those and defend it, and that somebody was an engineer as often as not.
- The tests assert editorial claims, not just behaviour
- A test greps for forward-looking compliance language. Another checks no two solution pages share more than four fifths of their vocabulary. Another checks a page that shows fixture figures also carries the word illustrative. This is unusual and it is deliberate.
- Absences are features, and they are hard to keep
- No endpoint returns a stored credential. No endpoint amends an evidence record. No model call in the decision path. Each is a property held by not building something, which means every new feature is a chance to break one by accident.
- Governance work is adversarial by nature
- The interesting cases are the ones where somebody is trying to get around the control — sometimes maliciously, more often because they are under deadline pressure and the boundary is inconvenient. Designing for the second is most of the work.
- Small surface, deep consequences
- The API has six resources. The difficulty is not breadth, it is that a wrong decision in an evaluation path is somebody’s duplicate payment, and a wrong decision in the evidence path is an audit that cannot be answered.
The constraints will slow you down, and that is the job rather than an obstacle to it.
Nobody writes that on a hiring page. It is the single most important thing to know here: the discipline that makes this product defensible — computed figures, absences held deliberately, claims asserted by tests — costs time on every change, and somebody who finds that intolerable will be unhappy quickly.
What is looked for
Framed as evidence rather than as adjectives.
Everybody claims rigour and pragmatism. What is checkable is whether you have done a specific thing, so each of these names the thing rather than the quality.
01Judgement about what not to build
Something you argued against shipping, and why. This matters more here than in most products because several of the product’s guarantees are absences.
02Comfort being the person who says the number is wrong
A time you blocked something on a correctness concern that was inconvenient for somebody senior to you.
03Writing that explains reasoning rather than describing behaviour
A design document, a post-mortem, or a code comment you are proud of. The comments in this codebase explain why rather than what, and that is a hiring signal as much as a style.
04Enterprise reality, not enterprise vocabulary
Experience of a system of record somebody could lose money in, an audit, or an incident with a regulator attached. Familiarity with the shape of those constraints matters more than seniority.
Open roles
None listed, and none invented.
A page of fabricated openings wastes the time of the people you most want to hear from, and it is discovered on the first reply. Writing anyway is still worth doing, and it is read.
Open roles
There are none to list accurately today. Posting a speculative role to collect applications would waste your time and be found out immediately, which is a worse outcome than an empty page.
What it will contain
- The actual role, with what you would own rather than a list of technologies.
- What the first three months look like, specifically.
- The salary range, stated rather than requested.
- Who you would work with, named.
Writing anyway
hello@opsai.dev with what you have worked on and which of the six things above appeals or worries you. The second is more interesting than the first.
A specific disagreement with something on this site is the strongest possible opening.
What to read first
The six positions are the load-bearing beliefs. If you disagree with them, the work will be frustrating rather than interesting, and that is worth establishing before either of us spends an afternoon.
- How the work is organised
- Around the six stages of the product rather than around layers. Somebody owning approvals owns the mechanism, the surface, the documentation and the argument for why a hold expires — which is unusual and is why the pages read the way they do.
- Research is not a separate group
- The four questions on the research page came out of building the thing, and the positions they produced are published inside product pages rather than as papers.
Where to go
Read the six positions, then tell us which one is wrong.
It is a better opening than a covering letter and it tells us more. Several of the decisions on this site are arguable, and somebody arguing well with one of them is the clearest signal available.