REDCARBON logo

Backend Engineer

REDCARBON·€45,000 – €70,000

Primary stack

GoTypeScript

Nice to have's

KubernetesgRPCOpenTelemetryGraphQL

Job description

About the Position

Own the event-driven services that turn alerts from dozens of security tools into incidents our agents and analysts can act on.

Remote (Italy) · HQ Turin
Engineering
Full-time

Salary

€45k–70k gross/year (RAL)

Indicative. Truly exceptional? We go above it.

Level

Mid-level or senior

Contract

Full-time, permanent, CCNL Commercio


About the Role

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.


Responsibilities

  • 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.
  • One stream, many customers, zero leaks between tenants.

Requirements

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.
  • Kubernetes.
  • 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.

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.

We Offer

  • A competitive salary: €45k–70k gross a year (RAL), depending on your level. The range is indicative: if you are truly exceptional, we'll talk numbers above it.
  • Full-time, permanent contract, CCNL Commercio, with health insurance.
  • Full remote from anywhere in Italy. We do about 95% of the work remotely; the rest is alignment days and company retreats.
  • A MacBook Pro. It's what we all work on.
  • An AI subscription for everyone. Use it, a lot.
  • Flexible hours, holidays managed on trust, zero micro-management.
  • Growth budget: time for learning, courses and certifications, internal tech talks, and conferences paid for, even more so if you are the one on stage.
  • Meal vouchers.

How We Think About Engineering

Writing code is only part of the job, and with AI writing more of it every day, it's less and less what sets an engineer apart. What does: understanding the problem you're solving, questioning assumptions, exploring alternatives, and taking responsibility for the outcome.

We value curiosity over certainty, evidence over ego, and impact over activity.

Ownership means owning the problem, not falling in love with your solution. Sometimes the right thing is to push through a difficult problem. Sometimes it's to admit that the original decision was wrong and change direction. Knowing the difference matters, and changing your mind when the evidence changes is a strength here, not a loss of face.

We give people context, trust, and room to make decisions. We don't expect you to get everything right; we expect you to learn, take initiative, and grow. The team will help you, a lot, but it won't do your thinking for you.

We care about what you achieve, not how many hours you spend looking busy.

And we want to enjoy building things together. Great engineering and having fun aren't mutually exclusive.


How We Work

We are agile, in the original sense of the manifesto, with security by design and by default on top. As an engineering team, we value:

  • people and trust over processes and controls;
  • real impact over plans and documentation;
  • understanding the customer's problem over executing the spec;
  • learning and adapting over following the original plan;
  • security as a design choice over checking it at the end;
  • growing together over excelling alone.

The things on the right matter. When we have to choose, we choose the ones on the left.

We are agile. Sometimes very agile. Sometimes so agile that the plan from Monday is a fond memory by Wednesday.

In practice:

  • Simplicity over virtuosity. Complexity is a debt, clarity is an asset. When in doubt, the simplest thing.
  • Ownership, not hand-offs. Shipping is not passing the ball. You follow your work until it really works in production, and you fix it if it doesn't.
  • Decide, write it down, revisit it. The people closest to the problem make the call, and write down why: that's what the ADRs are for. When the evidence changes, the decision changes too. A superseded ADR means we learned something, not that someone failed.
  • Remote, not isolated. Writing well is part of the job: we don't have a hallway, we have text. And we meet in person regularly, because some things remote can't give you.
  • Mistakes are fine, repeating them isn't. A deploy that breaks something happens. The same deploy breaking the same thing three times is not "iterating".
  • Cross the borders. Backend people touch the frontend, AI people learn the security domain, everyone cares about the analyst on the other side of the screen.

How to Apply

There is no "send us your CV" form here. To apply, you have to hack the site.

The application form is behind a short challenge: a few puzzles that a curious developer solves with the browser devtools, a terminal and some patience. It's the same for every role. Solve it, then send us your CV and your GitHub profile. If you like the challenge, you'll probably like the job.

What Happens Next

  1. An intro call with your future manager and our Product Manager: who we are, who you are, what you are looking for.
  2. One or two technical interviews with the engineers you would work with.
  3. A final interview with our CTO, and then an offer.

RedCarbon S.r.l.

Torino (TO), OGR - Corso Castelfidardo, 22 - 10128 - Italy

Tax Code and VAT Number 13235700013

REA Number TO-1348837

Registered share Capital €322.447,06


Products

  • AI Analyst L1
  • AI Analyst L2
  • AI Threat Hunter
  • AI Threat Intelligence Analyst
  • RedGuard AI
  • AI Compliance Analyst

About

  • About us
  • Blog
  • Careers

Social

RedCarbon S.r.l. 2026 ® - all rights reserved

Privacy Policy

Cookie Policy

EULA

Security Information

© REDCARBON. This job description was sourced from the employer's public career page. TheJob is not the employer — we index the posting and route candidates to the source. All content rights and hiring decisions belong to the employer.

More at REDCARBON

All 2 roles

Popular searches