Backend Engineer

RedCarbon builds AI agents for cybersecurity. Think of them as virtual colleagues that join a Security Operations Center and take on the work that burns analysts out: triaging the endless stream of alerts, investigating incidents, hunting for threats, writing the report at the end. The humans keep what needs a human: judgement, decisions, the call to the customer at 2am. We are an Italian company with our HQ in Turin, remote since day one, and we closed a €3M Series A in 2025. Our customers trust us with their security, which is a polite way of saying that "it works on my machine" is not an option here. We are a bit crazy. We put a hacking challenge in front of our application form, and a pixel-art mascot in our job posts. You are about to meet him. Hi, I'm Rosso. Our release notes are written by an AI. This job post was too. Kidding. Mostly. But we are dead serious about the engineering. We aim for a technical bar that is very, very high, and we are AI-first: we build AI products, and we build them with AI, every day, on purpose. So we don't hire people to turn detailed requirements into code. We hire engineers who start from a problem, understand it, question the assumptions, pick a reasonable solution, ship it, and check that it actually solved the problem. You don't need to know our whole stack on day one. You need solid fundamentals, and to learn fast. The role We're looking for a backend engineer who starts from the problem, not from the ticket. Every incident our agents and analysts handle starts as data: alerts from the security tools our customers already use, normalized, enriched and routed to whoever, human or agent, has to act on it. As a Backend Engineer you build and run the services that make that happen, reliably, securely, and without waking anyone up at 3am.

What you'll do
- Build services in Go and TypeScript that ingest, normalize and route security data from many different sources.
- Design event-driven systems: streams, durable jobs, retries, idempotency. The kind of plumbing that keeps working when one of its inputs doesn't.
- Design APIs (gRPC/protobuf, GraphQL) that the frontend, the agents and the other services rely on.
- Own your services in production: metrics, traces, alerts, runbooks. If it breaks, you know before the customer does.
- Build security in from the start: least privilege, secrets handling, tenant isolation. If the default isn't secure, the design is wrong. The problems you'll solve
- A vendor changes its API without telling anyone. You find out before the customer does, and the alerts keep flowing.
- The same alert arrives three times, from two sources, across two retries. It has to become one incident, not three.
- A customer's SIEM floods us in the middle of an attack, which is exactly when nothing can be dropped.
- Our software runs behind the customer's firewall, where you can't SSH in: it has to tell you what's wrong on its own. Every pull request here declares whether it is a one-way or a two-way door. Even the one that changed a logo colour. Blast radius: cosmetic. What we're looking for Must have
- Go or TypeScript/Node in production. One very well, ideally both.
- Relational databases beyond the ORM: schema design, migrations, reading a query plan. We use PostgreSQL.
- Distributed systems fundamentals: at-least-once delivery, idempotency, ordering, backpressure. You know why they are hard, not just which library hides them.
- Containers: you have built, shipped and debugged services running in Docker.
- Strong on tests, especially integration tests against real dependencies rather than mocks of everything.
- You have debugged a production problem you didn't cause, and you can tell us how you found it. Nice to have We use these every day. You'll learn the ones you don't know yet.
- Message brokers: we use NATS JetStream; Kafka or similar counts.
- gRPC and protobuf.
- Observability with OpenTelemetry: metrics, traces, structured logs.
- CQRS, the outbox pattern, event sourcing.
- GraphQL.
- GitOps and infrastructure as code.
- Integrating messy third-party APIs, ideally security vendors'.
- Shipping software that runs in customers' environments (on-prem, their cloud, behind their firewalls), where you can't just SSH in. Someone here has 12 git worktrees of the same repo open. Right now. On one laptop. Your first months
- First week: deploy a small fix to a service, and follow it on the dashboards up to production.
- First month: build or extend an integration with a security vendor: ingestion, normalization, tests against real responses.
- First three months: own a service: its alerts, its runbook, its roadmap. When it alerts, you're the one who knows why, and the one who proposes what it needs next.
- After one year: you are better at something that matters to you, technical or not, and you can prove it. That's what the growth budget is for, and we'll look at it together. For every role
- You live in Italy. We hire in Italy only, f