Founding staff engineer, or the CTO after them.

Customers hand us a workflow and walk away. We promise it finishes — through process restarts, bad deploys, a downstream API that goes dark for six hours, and the occasional clock that runs backwards. That promise is the entire product.

Right now it holds because six people are careful. It needs to hold because the system is built to. That gap is the job.

• The durable execution core — event sourcing, replay determinism, and the migration story for workflows already in flight when the code under them changes.
• Scheduling under back-pressure. We currently drop work at the wrong end of the queue and nobody is happy about it.
• The correctness bar: what gets a test, what gets a proof sketch, and what gets an alert and a shrug.
• Hiring the next four engineers, if the seat turns into the CTO one.

• You have debugged something that only failed in production, under load, on one machine, and you found it without a stack trace.
• You can say what a decision cost, out loud, without softening it.
• You read error messages. All the way to the end.

We do not screen on years, on a degree, or on where you worked last. We screen on the next section.

The application form is the first technical round. It is obstructed on purpose. Things that look broken are not broken — they are the exercise, and every one of them tells you what went wrong if you look at what the server actually said.

You will need browser developer tools and, at one point, the ability to send an HTTP request yourself. No file is ever uploaded; we take links only. Budget an hour or so. There is no timer and no penalty for taking longer.

Use whatever tools you like, models included. They will help less than you expect — most of the work is diagnosing state that only exists in your own browser.