At Camunda, we create products that empower customers to tackle some of the world’s most complex business processes. That sounds simple. It’s not!
Behind the scenes, our engineers are tackling challenges that span distributed systems, long-running workflows, event-driven architecture, and scale across multiple cloud environments. But what sets them apart isn’t just their technical skill—it’s how they think.
In this special “Meet a Camundi” series, we’re spotlighting the engineers behind the platform. You’ll get a window into the problems they’re solving, how they think about system design and debugging, and the mindsets that make them thrive at Camunda.
If you’re the kind of person who loves peeling back the layers of complex systems, who doesn’t wait to be told what to do, and who gets curious about the why, not just the what, then you might belong here, too! Read on to find out!
Nicolas Pepin-Perreault
What experiences have shaped your career and led you to where you are today?
There are two major things that stand out. In my first job, while still in university (shoutout to SCL Medtech, since then acquired by Schneider), I worked on building automation—essentially on multi-protocol sensor integration. I was initially hired to do the complete frontend, and while it worked, I obviously handed in something that was an unmaintainable mess. After I came back from my year abroad, they hired me again, and I interviewed with my replacement, who proceeded to rip into the “previous guy” for a good half hour.
We had a good laugh about it after, and he turned out to be a great mentor! From him, I learned how to build things in iteration while always delivering functional MVPs, which has proven to be invaluable. So thanks, Scott Burch, wherever you are now!
The second one was my last job before Camunda, a small startup, where I ended up wearing all the hats. I did web frontend development, I built an iOS application, an Android application, the Rails backend for them, the BI pipeline, a custom workflow engine, and also did operations (pre-Terraform and Docker days 😀).
That was incredibly formative, since I got to basically set up a product from the ground up—frontend, backend, CI/CD, ops, on-call, QA, etc. Though, I’m still surprised they gave me so much trust.
How did you learn about Camunda, and what motivated you to join the team?
Glassdoor. I basically looked around for small companies with high ratings, and since I had built our own workflow engine in my company, I figured this seemed like a good opportunity.
Two things motivated me to join: the idea of working on a “research” project (meaning very early in its lifecycle) and the ability to shape it, and our CTO. At the time, Daniel was not CTO but was the manager for my team (and the person who interviewed me), and I was used to having nontechnical managers, so it was refreshing to have a great engineer, a peer, be my manager, from whom I could expect to learn a lot.
How do you describe what your team works on?
So I’m currently managing two teams, but I will focus on my “oldest” one, the Distributed Systems team. We build and support the foundation of the Camunda 8 Orchestration Cluster, specifically the cluster part. We’re responsible for everything related to data storage and replication (including backups thereof), cluster management, and network communication.
Why is debugging so difficult in your domain and how do you train engineers to handle it?
As Lena mentioned, debugging distributed systems is quite different from single instance or stateless programs. Since direct observation of such a system will change its behavior (e.g., a debugger stops a thread which causes some timers to go off), you cannot always rely on conventional tools. Making good use of all four pillars of observability is crucial to have a good understanding of your running system—that is, getting used to holding multiple possible timelines/states in your head when reasoning about it 🙂.
If you were onboarding a new engineer, what three technical skills or habits would you prioritize?
- Solid understanding of concurrency. While distributed systems and concurrent programming don’t map 1-to-1, anyone who is experienced and comfortable with concurrent programming will have a much easier time with distributed systems. This is because both deal with reasoning about multiple possible concurrent states and timelines/causalities.
- Solid network programming foundation. It’s important to understand how nodes communicate over the network between each other, how to troubleshoot it, how to evolve a backward/forward-compatible protocol, and finally how to deal with unreliability.
- Finally, disk I/O. Our team builds the primary storage used by the engine, so we have to ensure data integrity while remaining highly performant. This can be a challenge if someone has never worked with this, as any I/O (much like with networks) will fail in strange and sometimes arcane ways.
What makes engineering at Camunda feel different from other places you’ve worked?
It’s the first real pure software company I’ve worked at, meaning engineering is the value, not simply a cost. I obviously cannot speak for all of engineering, but at least in our team, high quality standards are a must, and it feels great to work on hard problems where “good enough” is, very often, a pretty high standard.
What kind of engineers thrive on your team and at Camunda?
In the distributed systems team, it’s definitely people with an internal drive for improvement—first themselves, but also their work, their team, and so on. People who are both innately curious and generous, meaning they want to learn and teach others at the same time. This helped us build a very cohesive, highly motivated team.
What excites you the most about your work?
I genuinely enjoy working with my team. They’re very smart people, and having worked so long with them, it’s very casual, very easy. We work on genuinely challenging problems (e.g., dynamically scaling your cluster horizontally with minimal disruption while maintaining data integrity), and we’re all generally excited about working together on these things.
It’s a bit of a feedback loop, but basically it’s motivating to work with motivated people, who are motivated because it’s motivating to…you get the idea 😄. Maybe a bit strange to say, but it works.
Where are you currently based and how has your experience been working with teammates in a full remote setup?
I’m based in Berlin, Germany. The switch to remote has been rather smooth from my end, both as an engineer initially and then as a manager. I cannot speak for all teams, but ours still has a high degree of collaboration, such that even if we’re all in different spaces, we still often talk to each other face to face, whenever it makes sense.
It did require leveling up our communication skills. A lot of the knowledge you would previously absorb through random, organic conversations, now you have to make sure to pass directly. So we adapted through weekly asynchronous updates (focusing purely on the relevant changes for your teammates, not as a status update), increased technical documentation, and internal guides (runbook style).
This means, more than before, the team can work autonomously and self-serve in most instances, and when not, we can easily switch to a quick call.
What’s a project or idea you’ve worked on at Camunda that you’re particularly proud of?
Is it okay to say Zeebe? Along with Chris and Deepthi (and others who have since left our team), we pretty much built it from the ground up. It had very rough early days, but I think we can be proud of where it is now, what it can do, and what it powers.
What’s one piece of advice you’d share with someone considering an engineering role at Camunda, especially someone earlier in their career?
Get rid of your ego as soon as possible. This doesn’t mean that you cannot be proud of your achievements, but there is always a bigger fish. Just always do your best, always try to learn, and don’t hesitate to say you don’t know. And follow up, ask them to explain it to you!
And for people later in their career, it’s a win-win to upskill the people around you. If you think they aren’t at your level, instead of fighting against it, teach. It will save you time down the line.
Can you share something about your personal life that colleagues might not know about you?
I had a very privileged life, so I don’t know, nothing much interesting. I have a BA of Arts in English Literature? I did a double major in both computer science and English literatures, since I couldn’t decide.
I’ve recorded four CDs, some of which are on Spotify. But you’ll have to ask me or wait for another blog post to know which ones 😄.
Lightning round
Favorite debugging tool or approach when everything else fails?
Can’t beat printf. We are talking about when everything else fails, right? 😄
JVM trick or concept every engineer should know?
Every engineer? Learn to use and love JFR. It’s useful for metrics, I/O monitoring, CPU profiling, and memory dumps!
Distributed systems engineers though—learn the Java Memory Model! It doesn’t take that long, and it’s incredibly useful for reasoning about concurrency.
Most misunderstood concept in distributed systems?
Distributed computing != Distributed systems! I joke, but I’ve heard the two used interchangeably too often 😄.
More seriously, I don’t know if it’s misunderstood. I think experts all probably know this, but it’s a very common rookie mistake: coordination is the root of all evils. Avoid coordination as much as possible, embrace conflict resolution and eventual consistency (if you can).
Come build with us
The work we do at Camunda isn’t for everyone, but if this kind of thinking energizes you, you’ll likely feel right at home.
We’re looking for engineers who think in systems, who get excited by hard problems, and who care deeply about building tools that other developers love to use.
Want to work with people like Nicolas? Explore our open roles.
