Almost everything here runs on infrastructure written in-house. The identity and account system, the sessions, the rate limiting, the abuse prevention, the database and its failover, the deployment path. That is not a preference about vendors: a system you rented is a system whose failures you can only watch, and watching is not the job. This role owns that ground.
What you'll work on
The database is ours, self-managed and self-healing across availability zones, and it has been tested the only way that counts. Its leader was killed mid-write on purpose, over the application's own connection: 323 writes acknowledged before the kill, 323 alive after it, with writes accepted again in about a second. Keeping that property true as the system grows is work that does not end.
You will also own the parts that are less pleasant and more instructive. Discovery that has to survive an instance disappearing. Alarms that can actually reach a human, which is not the same thing as alarms that fire; that distinction cost this laboratory five days and is published in full. A liveness check that fails when the database is gone, rather than the kind that returns 200 while the thing behind it is dead.
Go is the primary language, on self-managed instances across several availability zones rather than on managed services, with the keys held here. Cost is a design constraint rather than an afterthought, and it is verified against the bill rather than estimated: everybody here knows what the fleet costs per month, to the dollar.
What we're looking for
Someone who thinks in systems rather than endpoints, and who has been the person debugging one at three in the morning. You know the difference between a service that handles a thousand requests a second in a benchmark and one that does it under real traffic with real failure patterns.
You care about what most people skip: connection pool behaviour, garbage collection pressure, serialisation overhead, tail latency, and what a retry storm does to a system that was fine a second ago. You are comfortable owning something from provisioning to incident response, because there is nobody to hand it to.
Production Go, or deep systems experience and the will to learn it quickly.
How to apply
Email careers@neuraphic.com with the subject line "Backend Engineer." Send a resume, links to relevant work, and a short note on the hardest infrastructure problem you have solved: what made it hard, and what you got wrong on the way.