Year
Tech Stack
Description
42’s Common Core is project-based and peer-reviewed. There are no traditional classes, so I had to learn by reading docs, breaking things, asking better questions and defending my code in front of other students.
I worked through low-level programming, algorithms, Unix systems, networking, graphics, C++, containers and web foundations. That mix changed how I debug: I’m much less afraid of going below the UI layer when something behaves strangely.
My Role
I completed the curriculum at 42 Lyon through individual and team projects in C, C++, Unix, networking, graphics and web development.
It shaped the habits I still bring to product work: owning the problem, handling errors directly, reading other people’s code and explaining tradeoffs without hiding behind buzzwords.
Case Study
Summary
The peer-to-peer engineering curriculum where I learned to build, debug, defend my choices and keep going without lectures or ready-made answers.
Context
42 is a self-directed engineering school where students move forward by shipping projects and passing peer evaluations.
The Common Core comes before specialization. For me, it was the period where I built the base I now use for frontend, Web3 and product engineering work.
Problem
The challenge wasn’t only learning syntax. It was learning how to approach an unfamiliar technical problem when nobody gives you the recipe.
Most projects started with a dense subject PDF and ended with a defense. In between, I had to turn vague requirements into working software, handle edge cases and explain why my implementation made sense.
Contributions
Built C projects around parsing, memory management, process control, shell behavior, networking and graphics.
Completed C++ modules covering object-oriented design, type safety, resource management and standard library usage.
Worked on team projects with real-time communication, Dockerized services and full-stack product flows.
Technical Decisions
I learned to prefer explicit error handling, readable control flow and defensive code because 42 evaluations tend to punish happy-path thinking.
Peer review became part of the work, not a ceremony after it. If I couldn’t explain a choice clearly, the code usually needed another pass.
Result
I built the low-level base that now helps me write better frontend and product code, especially when debugging performance, state or API behavior.
I also got used to moving between systems programming, web interfaces, containers and API-driven apps without treating them as separate worlds.