Hi there, I'm Harold,
mechanical & software engineer.

The intensive selection month — you have to swim!

I still had my engineering job back then. Time and stress management were taken to another level. I enjoyed learning the basics of C in no time, meeting amazing new people (some made it into the school, some did not). C coding during the week, exams on Fridays, "rushes" during the weekends.

Let's be honest: I would not do it again. Glad I got accepted the first time.

A friend told me: "it's like Split on crack" (Split being a challenging exercise from the Piscine exams). That was enough to trigger my appetite for a new challenge.

I made a fast and minimalist solution using a linked list to avoid unnecessary copying. Well, I don't think he had ever experienced crack, and I haven't either... but in retrospect, it's probably just like RedBull ;)

Recoding printf from scratch, in C. The bonus was somewhat challenging, especially the parsing. In the end, I was happy that my code base stayed small.

An introduction to sorting algorithms and time complexity. The program (in C) has to sort an array of integers with the minimum number of moves, given specific game rules.

I first coded a direct (no pre-sorting) solution using merge-sort — O(n log n). Even though it was quite good on large arrays, I averaged 699 moves for n=100. The target for full marks was under 700.

So I made another solution: based on a greedy algorithm backed by a backtracking evaluation of multiple candidates, it reaches 477 moves on average for n=100. If Push_Swap were in the Olympics, I think that one could qualify ;) It runs on O(n^1.5), so it's only interesting for small n, though.

Code a simple shell in C, with Bash as a reference. The first group project at 42 — known as a big milestone, with quite a lot of complexity.

I worked with Hélène. We almost clashed during the first week... Nevertheless we kept going, professionally. After 5 weeks, we had a solid solution covering all tests we could find or think of. And Hélène and I became good friends :)

How to understand the fundamentals of parallel computing through a classical example, coded in C, using low-level functions only.

For the multi-threading part: I coded a pool manager on my old i5-3320M, so that the philosophers/workers perform well even when the machine is pushed to its limits. For multi-processing: subject restrictions meant I couldn't apply the same strategy, so I went with optimized time-phasing instead.

The last exercise in a series of C++ modules introducing object-oriented programming. Because it's the last one — and because it's 42 — it's quite challenging.

The Ford-Johnson algorithm is the best known sorting algorithm in terms of number of comparisons. It reaches the mathematical lower bound for small n (up to n=22 and n=66). Even though it dates from the 1950s, only tiny improvements for larger n have been found since.

Implementing it is far from trivial, I would say — much harder than merge-sort. But here's the catch: on a computer, it runs on n²log n, at least for all implementations I could find. Minimal comparisons, but super slow. How frustrating is that?!

After my initial vector-based implementation, I built a hybrid version using red-black order-statistic trees. This one runs on n(log n)². Still not competitive with n log n algorithms — but in cases where comparisons are expensive and n is large, it might win the game. (Please let me know if this approach exists somewhere already.)

You enter a dark cluster — 3 hours to solve a problem, no internet, no AI, not even your IDE. Just you and the machine, and you have to code. Sometimes quite tough problems, picked randomly from a pool.

I enjoyed those challenges: the adrenaline, the tension in the room, the sound of neighbors' keyboards, the terminal rejecting your solution until — finally — it accepts it.

And yes, it's 42: failure is accepted, it is part of the process. You can repeat the exam as many times as you need. Next time, you'll prepare better. Still always frightening... and somehow very fun.