The 42 Piscine: how it works and how to prepare

What the Piscine is

In 42-network schools, the Piscine (French for "swimming pool") is how you get into the main curriculum. For roughly four weeks, candidates work full time through a sequence of programming subjects. There are no lectures and no teachers explaining the material: each subject is a document that describes what to build, and it is up to you — and the people sitting around you — to work out how.

What is being assessed is less "how much C do you already know" and more "how do you learn when nobody hands you the answer": whether you read carefully, test your own work, ask for help, help others, and keep going when something does not make sense yet. Plenty of candidates start with no programming experience at all.

What you work on

The work is split into modules, usually tackled in order. A typical Piscine looks like this:

Few people finish every module, and you are usually not expected to. Getting further matters, but so does how you got there: code you understand and can explain counts for more than code you copied and cannot.

Learning from peers, not lectures

Peer learning is the core of the method. When you are stuck, the intended move is to ask the person next to you, and when someone asks you, explaining it is part of your own learning — you find out quickly whether you actually understood something when you have to say it out loud.

Work is also evaluated by peers. Other candidates review your submission with you: they read your code, run it, ask you to explain your choices and check edge cases you may have missed. You do the same for them. Automated tests usually grade the submission as well, and they are strict: output has to match exactly, file names have to be exactly right, and anything extra in your repository can fail an exercise.

Two habits make evaluations go better on both sides: test your own work before anyone else does, and be ready to explain every line. "A friend told me to write it this way" is not an explanation.

Why it starts with the shell

The Piscine begins at a terminal prompt, not in a C file. Everything that follows — creating files, compiling, running tests, submitting with Git — happens on the command line, so the first modules make sure you can work there deliberately.

The shell modules are also a first lesson in precision. An answer is often a single file or a single command line, and it is either exactly right or wrong: the wrong permission bit, a missing trailing newline or a stray extra file is enough. That attention to detail is exactly what the C modules will ask for next. The two guides below cover each module's ideas in depth.

How the C modules build up

The C modules introduce one idea at a time and then lean on it. Early on you print characters and loop over values; soon you are passing pointers to functions, walking strings byte by byte, converting numbers between bases, and eventually allocating memory yourself and building linked structures. Each module assumes the previous ones, so gaps compound — it is usually better to understand C 01 properly than to rush to C 04.

Code is expected to follow the Norm, the 42 coding standard, which is checked by a tool called norminette. It constrains things like function length and layout. It can feel arbitrary at first; in practice it forces small functions and readable code, and a Norm error can fail an otherwise correct exercise.

The concepts that trip people up most are the ones you cannot see: what a pointer actually holds, where a string ends, what happens to memory after a function returns. Drawing memory on paper — or watching it in a tool that shows it — helps far more than rereading the same code.

Exams: coding alone, against the clock

Most Piscines include regular exams. You work individually, in a controlled environment, without your usual notes or the internet, and exercises get harder as you succeed. Being able to finish a module with help from peers is not the same as being able to write the same code from memory under time pressure — exams test the second one.

The practical preparation is simple and a little uncomfortable: take functions you have already written, close everything, and write them again from scratch. Then test them on edge cases — empty strings, negative numbers, the largest and smallest values of a type. If you can only write something while looking at a previous version, you do not know it yet.

How to prepare

You do not need to learn C before the Piscine, and trying to memorise the curriculum in advance tends to backfire. What does help:

• Get comfortable in a terminal. Moving between directories, listing files with their details, creating and removing files, reading a manual page with man. The Shell00 guide is a good starting list.
• Pick a terminal editor and learn the basics. Opening, editing, saving and quitting without thinking about it saves a lot of frustration in the first week.
• Read a little C. Not to master it — just so variables, loops, functions and if statements look familiar when you meet them.
• Practise reading instructions exactly. File names, output formats and permitted functions are part of every requirement.
• Plan for the pace. It is an intense month. Sleep, food and breaks are part of the preparation, not a distraction from it.

During the Piscine, a routine helps: read the whole subject before starting, do the exercises in order, test each one yourself, push your work regularly, and ask for help once you have been stuck on the same problem for a while rather than hours later.

Common mistakes

• Skimming the subject. Most failed exercises get the idea right and a detail wrong: a file name, a permission, a newline, an extra file left in the directory.
• Skipping ahead. Subjects are often graded in order, and a broken early exercise can stop later ones from counting. Make the easy ones solid first.
• Submitting code you cannot explain. It tends to surface in peer evaluations, and it certainly surfaces in exams.
• Testing only the example. The example in a subject is a hint about the format, not a test suite. Try the cases nobody showed you.
• Ignoring the Norm until the end. Writing to the Norm from the start is far easier than reformatting working code.
• Working in isolation. The method assumes you will talk to people. Candidates who never ask for help usually get stuck longer than they need to.

Shell guides

Two detailed guides cover the ideas behind the opening modules. They teach the concepts with their own examples and do not give exercise answers — working those out is the point of the modules.

Using 42CodeLens alongside the Piscine

42CodeLens is an interactive environment for learning C and preparing for the 42-style curriculum. You can step through a C program line by line and see what happens to memory, pointers and the call stack as it runs — the part of C that is hardest to see in a terminal. Around that sit course modules for the Piscine and the Common Core, a Handbook, interactive Labs and practice exercises.

A useful part of it is free with no account needed to browse: the Shell 00 and Shell 01 modules, Handbook volumes 0 and 1 (volume 1 covers Unix and shell foundations), and every Lab, including number-base conversion and pointers. The C modules and the rest of the Handbook are part of 42CodeLens Premium — see Pricing for what that includes. 42CodeLens does not submit or grade your Piscine work; it is there to help you understand it.

Open 42CodeLens and choose Curriculum to find Shell 00 and Shell 01.