When he joined Criteo’s R&D department over 4 years ago, Nicolas Truchi had a Software Development Lead position in our Product Engineering organization. Since then, he moved to an Engineering Manager role in the Site Reliability Engineering department, now providing critical services to his previous group.
We talked with Nicolas about these changes, what his teams are all about, and what’s next—for Criteo R&D and for new members of his team.
What was your biggest surprise when you joined Criteo?
When I joined, I took over a very small team owning several business-critical products. My mission was to grow it from almost scratch to about 12 developers.
What struck me the most is the amount of trust, freedom, and autonomy that my manager entrusted me with. That was exhilarating, and I came to realize that it’s part of Criteo’s culture. I never experienced such a stimulating environment in my career and I’m happy this is still a core part of Criteo’s culture today.
Tell us about your role in SRE.
As an Engineering Manager in the SRE department, I do oversee several teams, and thus manage the leads and managers that are running those teams. Our core responsibility is to provide high-level frameworks and SDKs to about 300 engineers in R&D.
We operate the systems, design the APIs, and provide performance expertise in Criteo’s main development technologies (.NET & JVM).
As an engineering manager, my mission is to guide execution through vision and roadmaps for the group, create growth opportunities, and build strong relationships with other teams in R&D.
What are your teams’ biggest challenges?
The main defining challenge for engineers in the team is that their code performance and reliability is paramount, as SDK code. Every piece of code they write will be executed over 500 billion times a day, 3 million times per second at peak hour. As you can imagine, the slightest mistake or optimization might make or break the business. This is the looming risk when contributing to critical, low-level code in SRE: you will have a huge impact on all of the company’s products at once.
A timelier challenge is that we are moving all our C# code from Windows to Linux servers. This means improving Microsoft’s .NET Runtime performance on Linux—this time, contributing optimizations not only to Criteo, but to all .NET developers worldwide.
What’s coming next that someone joining the team might be excited about?
So, I guess those challenges weren’t enough? Well, we do have parts of the architecture that are 8 years old, and the company’s scale has grown more than 10 times since then. As you probably know, a given design can usually sustain an order of magnitude of growth—rarely more. We always have a few components that will benefit from re-engineering.
One example: our distributed caching infrastructure, which at the time was supporting tens of servers, now needs to cope with thousands of them.
If you’d enjoy working at that scale on distributed online systems, we’re hiring!
Share a few things people should know about Criteo’s SRE department!
I really think SRE is by far the best department in R&D to learn about design and architecture. These teams also have a large diversity of skills: low-level performance code, operations, data engineering, and even front-end.
Most of the skills we learn are not related to the business and thus, they’re transferable from one team to another. These are the kind of skills that are sought after in every significantly-sized tech company, so they are very valuable to learn.
What’s a lesson that you wish you learned earlier in your professional life?
Most junior engineers—me included—think that software engineering is a lot more about code than it actually is.
With experience, we all realize it is more about solving problems and making things happen. This is where most of the time, communication, and your social network in the organization are much more powerful assets than those neat algorithms in TAOCP.
What’s the biggest misconception you hear from candidates that you’d like to correct?
A reassuring one: a lot of candidates think they are not ready for the technical interviews we run and need weeks of preparation. The skills we are testing for aren’t about a specific sorting algorithm that you can learn in a few weeks. They are about the fundamentals of computer engineering, an open attitude, and willingness to make things move forward. You usually have these skills, or they will take years to grow. Be confident, and don’t procrastinate for a few weeks!
Any advice you’d give to a candidate or to your younger self?
It’s an important piece of advice from Grace Hopper, and it’s part of our R&D’s culture as well: “Ask for forgiveness, not permission.” You’ll thrive in an environment that accepts that.
