What's your developer origin story — how did you find your way into backend engineering?

It wasn't a straight path. I started out in mobile development because I thought it was the best way to build something that improves people's lives at scale: apps used by many people, making a big difference through many small impacts. It was fun to learn.

But as I grew and moved to a different country, I started to see that meaningful change doesn't come from shifting individual habits. It comes from systemic action. I got more interested in software tools that are more powerful, more impactful, and built to solve bigger problems.

That's what drew me towards climate and eventually ESG. And with that interest came a shift in complexity, from building mobile UIs to building systems where the UI is a representation layer, and all the interesting logic lives in the backend from focusing on the representation layer in the UI, to focusing on the internal modelling of a complex reality in the backend.. That's where I found the most interesting problems to solve.

Granular is probably the most challenging backend experience I've had. What makes it hard is that we're modelling a domain that is genuinely intricate.

What's the most interesting technical challenge you've tackled at Granular Energy?

The domain itself is the challenge. The energy space, and hourly matching in particular, is remarkably complex, and translating that into a reliable systems is hard. We're constantly adding new features while deepening our understanding of the domain, and that requires constant refinement of what we've already built. Things that seem elegant in theory get messy in practice and it requires a lot of thought and good design to keep the flexibility while containing complexity. As a former manager of mine once said: it takes far longer to build something simple than something complicated. That's the part I find most rewarding. I'm a bit obsessed with simplifying complex things.

Walk us through your typical development process from requirement to deployment.

It starts with outlining the business requirements. We have brainstorming sessions to make them concrete, then a developer takes ownership of writing a document that maps out exactly how the workflow should function: what data goes in, what comes out, which models need to be created or changed.

From there, we implement. With almost every project, diving deeper reveals new edge cases that send you back up the ladder, back to the requirements doc, back to the code. Once implementation is done, we open a pull request (or many), review comments, which often spark further discussion, and we loop back in wherever needed.

How does remote collaboration work in practice for the backend team?

Every morning we have a stand-up with the full backend and frontend team. Everyone runs through what they're working on, anything notable they've just finished, anything they're about to tackle. Often that sparks conversations that carry into smaller calls afterwards.

The rest of the day alternates between async and sync depending on where we are in the process. Brainstorming phases tend to involve more calls; implementation tends to be heads-down with async feedback on Notion docs or PRs. I personally lean towards talking things through directly. It's just faster for anything nuanced.

One thing we're disciplined about is documentation. Even when we have an offline conversation about a PR comment, we'll write it up: we discussed this in person and decided X because Y. That matters a lot when you need to understand why a decision was made months later. This mostly happens on Notion or Linear, and when appropriate as comments or docstrings in the code.

Do you have any advice for a candidate applying for a backend role?

Prep well, and prep specifically. Before my interview, I listened to podcasts on hourly matching, read articles on the domain, and worked through the white paper Granular co-authored with Nord Pool.

Understanding the domain really helped, because the technical challenges in the interview were grounded in it. Beyond that: refresh the fundamentals. It's easy to forget things you know well if you haven't practised them recently.

What makes Granular a good place to work as an engineer?

We're building something with purpose, with fascinating problems to solve. Modelling a complex, real-world domain from first principles is the kind of engineering challenge that's hard to find. And it's set in a working environment that's relaxed and supportive, with a team that's self-aware and continuously improving itself.

Plus, offsites three times a year, which offers a really great balance between having the flexibility of remote working and building a relationship with the team :).