From Staff Engineer to Engineering Manager at OpenClassrooms

When I moved into management, I worked with HR to define the role and design the hiring process end to end. I ran manager interviews, organised the technical and cultural fit interviews, consolidated feedback, contributed to decisions and facilitated salary workshops.

For candidates I had met who were not moving forward, I took the time to call them personally and explain our decision. They had invested time in the process, and the least we could do was explain our reasons directly.

I also played a significant part in designing the technical interview. You can read more in my article, A front-end interview process at OpenClassrooms ↗.

Once the hire was confirmed, I prepared a three-month onboarding plan with clear goals, so the new team member knew exactly what was expected and could go through probation without any surprises.

My squad works on connecting recruiters with talent, a critical part of OpenClassrooms' business. Just before Christmas, we unfortunately faced malicious outreach targeting people on the platform. With a full roadmap and fewer people available over the holidays, we had limited capacity to respond to further abuse. We needed to act quickly, but pragmatically.

I made a somewhat bold suggestion: temporarily close the direct contact channel over the holidays. In simple terms, this meant “switching off the business”. My reasoning was that recruiting activity is much lower at that time, so the temporary business cost seemed lower than the risk of leaving the door open without enough capacity to react.

After some discussion, my proposal was accepted on the condition that we put a lasting solution in place after the break. I then proposed a shadow ban mechanism inspired by my previous experience at Meetic. We were able to implement it in roughly one sprint.

Temporarily blocking everyone was not ideal, but it gave us the space to think through a durable and effective solution that OpenClassrooms can still build on today.

OpenClassrooms' sales teams need to view and manage organisations, recruiters, job postings and applications. To do so, they use a highly customised CRM that contains a substantial amount of business logic.

Each new capability therefore brings an unwelcome synchronisation: the OpenClassrooms platform has to send a significant amount of information to the CRM. This requires coordination with the technical team responsible for it and extends delivery timelines.

When we were asked to add information about applications, I went back to the underlying need: sales teams needed access to that information, but did not necessarily need it in the CRM itself. I had previously built a generic admin system that we could extend for these business objects. With the support of my team, I proposed building on that admin to remove the cross-team dependency that was affecting our performance.

Without that decision, we would have needed to send several types of events to the CRM, which would then have needed to process them: we estimated the full approach at around one month of work. With the new approach, we delivered all application management for sales teams in roughly one sprint.

That admin work also created an opportunity to broaden ownership within the team. I encouraged someone on my team, whose work had until then focused on backend development, to join product discussions earlier. They found this especially engaging and began considering a career path more focused on product.

They then had considerable latitude to build a substantial part of the admin interfaces now used by sales teams, keeping those teams' needs in mind. My contribution was to create the opportunity and support their autonomy, while leaving them room to own the implementation.

This is how I approach career development: gradually opening up opportunities to understand business problems, contribute to the product and take on broader responsibilities, then adapting support to the person's interests.

With artificial intelligence, I place even more value on engineers' ability to understand a problem, question proposed solutions and bring their expertise to product decisions. Today, an engineer's contribution is no longer simply about writing code.

When I joined OpenClassrooms, the frontend architecture had not yet been established, even though the codebase was already several years old. Drawing on my experience at Meetic, I proposed and then implemented a modular architecture. I wrote about that process in Construire une application JS depuis zéro ↗ (article in French).

Our React codebase was initially written in JavaScript. I pushed for the move to TypeScript to make the code more precise and rigorous. It was a change that needed to be supported over time, with existing code and teams continuing to develop the product.

I worked on the migration strategy, tooling and standards, as well as helping teams adopt them. This led me to propose and write the Découvrez TypeScript ↗ course for OpenClassrooms (in French).

I built a JavaScript SDK to communicate with an OAuth2 API, then worked on data-access layers. The goal was to give applications shared foundations for communicating with the backend.

These foundations evolved towards an API layer strongly typed with TypeScript and generated from backend OpenAPI definitions. This provided precise autocompletion and more robust code.

The frontend chapter brought together up to 12 engineers. I helped run it and supported teams across standards, code reviews and tooling.

A new practice to introduce? A library to update? A change to our architecture practices? As a Staff Frontend Engineer, my role was to align the entire chapter so that we could all move in the same direction.

To ensure cohesion as new members joined the frontend chapter, I helped define the technical interview process. The main goal was to give candidates the best possible experience, respecting their personal time and avoiding unnecessarily stressful situations. I wrote more about these interviews in A front-end interview process at OpenClassrooms ↗.

When I joined OpenClassrooms, all text was stored directly in the codebase. The main consequence was that developers were responsible for it.

This was a huge waste of time: around 80% of quality feedback concerned copy. I therefore asked the CTO to completely rethink the workflow, and was given carte blanche.

Working with the Content Designers, I designed a workflow in which developers no longer had to manage copy themselves, based on an external tool: Phrase. I described the entire process in Automate a translation system ↗.

We went on to use Phrase for several years. Unfortunately, over time, its cost and fit with our needs led us to look for another solution.

I therefore built an internal tool based on GitHub. The idea was for it to meet our exact needs, and nothing more. This allowed us to leave Phrase, which remains a very good tool but no longer matched our needs, saving around €20k per year.

I helped shape the frontend testing strategy, using React Testing Library and Playwright for integration tests. I advocated for 100% coverage, despite it being a much-criticised metric. I explain my position in The real benefit of 100% code coverage ↗.

Real end-to-end tests on essential user journeys, the golden paths, remain the responsibility of Quality Engineering. This distinction makes it clear what frontend tests cover and what they cannot guarantee on their own.

My long experience as a technical lead helped me realise what I enjoyed about my work: making sure my colleagues had everything they needed to do their jobs well, while remaining a technical point of reference.

When OpenClassrooms gave me the opportunity, I took the logical next step in my career: becoming an Engineering Manager.