Senior Backend Engineer

Build systems, not just services. Work across products, not inside one codebase. Own problems from first question to production.

The role

We run a portfolio of mobile products used by millions of people.

Our engineering team works across that portfolio.

You won't join a permanent team attached to one app. You might spend your first few weeks improving the backend of one product because that's where the biggest technical need is. A month later, you could be designing a service for another, helping resolve a production incident elsewhere, or improving infrastructure used across several products.

That's intentional.

We want engineers who can understand a system quickly, find the real problem, and move between different technical contexts without needing everything to stay familiar.

We're looking for a Senior Backend Engineer who combines depth in backend engineering with breadth across systems, infrastructure, architecture, and product.

Think T-shaped: deep in backend engineering, broad enough to understand the systems around it.

How engineering works here

There is not always a perfectly specified ticket waiting for you.

Usually, there is a problem.

A service is struggling under load. A database model no longer fits the product. A team needs to test something quickly. An API needs redesigning. Something breaks in production.

Your job is to understand the context, decide what engineering should do next, and build it.

That means asking questions beyond implementation:

What problem are we actually solving? What happens upstream and downstream? What breaks if usage grows 5x? What trade-off are we making? Does this need a new service at all?

We care more about how you reason about the whole system than how well you know one framework.

What you'll work with

Go is our backend standard.

Roughly 80–90% of our backend work is Go, with the rest mainly in Node.js and Python.

You don't need to have spent your whole career writing Go. You might come from Java, Kotlin, Python, Node.js, or another backend ecosystem.

What matters is that you can become productive in Go and don't treat one language as your professional identity.

You should also understand the infrastructure behind the code, including:

- relational databases, schema design, migrations, indexing, and query behaviour;

- distributed systems, message queues, and brokers such as Kafka;

- Docker and Kubernetes;

- cloud infrastructure and APIs;

- observability, performance, reliability, and failure modes.

What you'll actually do

You'll design, build, run, and improve backend systems across multiple products.

You'll take problems from an unclear starting point through architecture, implementation, deployment, and iteration.

You'll investigate systems you didn't build.

You'll work directly with product, frontend, data, and other engineers.

You'll improve existing systems instead of assuming everything needs a rewrite.

And when something breaks, you'll help solve it even if it wasn't part of your plan that morning.

Ownership means the whole thing

When we say ownership, we don't mean completing your assigned engineering tasks without reminders.

It's being able to take a problem, understand the context, speak to the right people, identify the unknowns, make the trade-offs visible, and get the solution into production.

Then check whether it worked.

There won't always be someone turning the problem into a checklist first.

You’ll probably thrive here if

You naturally zoom out before zooming in.

You can discuss architecture in the morning, debug a production issue in the afternoon, and work in an unfamiliar codebase the next day.

You care more about solving the problem than protecting your preferred stack.

You can make a sensible decision without having 100% of the information.

You ask questions about the product and user instead of treating requirements as fixed instructions.

You learn unfamiliar technology when the problem requires it.

You change your mind when new evidence makes your original approach wrong.

And when you notice a problem outside your current task, your first reaction isn't: “That's not mine.”

This probably won't work if

You want to spend the next 2 years inside one product, codebase, or narrowly defined area.

You need a detailed specification before you can start thinking about a problem.

You want architecture separated from implementation.

You prefer handing infrastructure, databases, deployments, or production problems to another team.

You strongly identify with one programming l