Jour 57 Day 57 · vendredi 30 octobre 2026 Friday 30 October 2026 Méthodo Fondamental
Raconter ses projets en entretien Telling your projects in interviews
Vos projets sont votre expérience : les raconter comme des histoires de décisions, pas comme des listes de technos, fait la différence en entretien de stage. Dernière fiche du programme — tout ce que vous avez vu devient munition. Your projects are your experience: telling them as stories of decisions, not lists of technologies, makes the difference in internship interviews. Last topic of the program — everything you've seen becomes ammunition.
L’essentiel
En entretien de stage, vous avez peu d’expérience professionnelle : vos projets sont votre expérience. Le recruteur ne cherche pas une liste de technos — il vérifie que vous savez expliquer un contexte, justifier une décision, mesurer un résultat et en tirer des leçons. L’outil : la structure STAR adaptée au tech, Contexte → Problème → Décisions → Résultat → Leçons.
| Étape | La question à laquelle vous répondez | Exemple rempli (quiz temps réel) |
|---|---|---|
| Contexte | Quoi, pour qui, en quelle équipe, quel délai ? | « Appli de quiz live pour les soirées de l’école — 4 personnes, 3 semaines » |
| Problème | Quelle difficulté concrète, mesurable ? | « Scores en direct pour 200 joueurs ; notre polling HTTP s’écroulait à 80 » |
| Décisions | Quels choix, face à quelles alternatives, et qui a fait quoi ? | « WebSockets plutôt que polling, Redis pub/sub par salle ; j’ai conçu et codé le serveur de jeu » |
| Résultat | Qu’est-ce qui a marché, avec quels chiffres ? | « 250 connexions simultanées tenues en conditions réelles, latence < 200 ms » |
| Leçons | Que referiez-vous autrement ? | « Tests de charge dès la semaine 1 : on a découvert la limite devant les utilisateurs » |
Chaque ligne du tableau tient en une ou deux phrases : l’ensemble fait un récit de 90 secondes, après quoi l’intervieweur creuse là où il veut. C’est exactement ce qu’il attend.
Comment ça marche
Choisir 2-3 projets et les connaître à fond. Trois histoires maîtrisées valent mieux que huit lignes de CV survolées. Pour chacun, préparez : l’architecture (dessinable au tableau), les décisions et leurs alternatives, un ou deux chiffres, ce qui a raté, ce que vous referiez autrement. L’autocritique est un plus : « aujourd’hui je découperais ce service » signale de la maturité, pas de la faiblesse.
Quantifier quand c’est possible. « Une app rapide » ne dit rien ; « le chargement est passé de 4 s à 800 ms après mise en cache des requêtes » raconte une investigation. Utilisateurs, latence, volume de données, temps gagné : un chiffre honnête, même modeste, bat un superlatif.
Assumer les choix techniques. « Pourquoi Postgres ? » mérite une vraie réponse — et « c’est la base qu’on connaissait, nos données étaient relationnelles, c’était le choix sûr en trois semaines » en est une : honnête, contextualisée, défendable. Le mauvais réflexe : inventer a posteriori une justification savante qui s’effondre à la deuxième question.
Le pitch de 90 secondes, écrit et répété avant l’entretien :
« Mon projet le plus formateur : un quiz temps réel
pour les soirées de l'école. [contexte, 15 s]
Le défi : afficher les scores en direct pour 200
joueurs — notre premier essai en polling HTTP s'est
écroulé à 80 connexions. [problème, 15 s]
On est passés aux WebSockets, avec Redis en pub/sub
pour diffuser par salle. Moi, j'ai conçu et codé le
serveur de jeu, et mesuré la différence avec un test
de charge. [décisions, 30 s]
Résultat : 250 joueurs simultanés en soirée réelle,
moins de 200 ms de latence. [résultat, 15 s]
Si je recommençais, je ferais les tests de charge dès
la première semaine — on a découvert nos limites
devant les utilisateurs. » [leçons, 15 s]🎤 En entretien — « Présente-moi un projet dont tu es fier. » La question tombe dans presque tous les entretiens de stage, souvent en ouverture. Ne jamais répondre par la stack (« c’est du React avec du Node… ») : dérouler le pitch de 90 secondes, puis laisser l’intervieweur creuser. Celui qui pose la question veut une histoire, pas un inventaire.
Concepts clés à maîtriser
- STAR tech : Contexte → Problème → Décisions → Résultat → Leçons. La version RH (Situation, Task, Action, Result) marche aussi ; l’important est l’ordre — le contexte avant les détails, le résultat avant les leçons.
- Le « toi précisément » : dans un projet de groupe, l’intervieweur isolera votre contribution. Préparez la réponse au « je » : « j’ai conçu le schéma de base et l’API d’auth ; Marie a fait le front ». S’attribuer le projet entier se détecte en trois questions techniques.
- L’autocritique calibrée : un vrai raté + ce qu’il vous a appris + ce que vous feriez maintenant. Ni « rien n’a raté » (personne n’y croit), ni l’autoflagellation (le stagiaire qui se démolit inquiète).
- La démo qui marche : URL déployée testée le matin même, et un plan B hors ligne — capture vidéo ou GIF dans le README. Le wifi de la salle de réunion trahit toujours.
- Le GitHub propre : le recruteur passe 90 secondes sur un repo. README avec une capture d’écran, une phrase sur le quoi et le pourquoi, instructions de lancement qui marchent (
docker compose upidéalement — fiche Docker), pas denode_modulescommité, pas de secrets dans l’historique. - Lier chaque projet au poste : relisez l’offre la veille. Chaque compétence demandée doit se raccrocher à une anecdote d’un de vos projets. Poste backend → la modélisation, l’API, les migrations ; poste front → l’état, les perfs, l’accessibilité.
💡 Le README fait la moitié du travail — un recruteur qui ouvre un repo avec capture d’écran, description en deux phrases et un
docker compose upqui marche a déjà une bonne impression avant l’entretien. C’est le seul document que vous contrôlez à 100 % et qui parle pour vous en votre absence. Une heure de rédaction, rentabilisée à chaque candidature.
En entretien
« Qu’est-ce qui a raté dans ce projet ? » — Jamais « rien ». Un raté précis, sa cause, ce que vous avez changé : « on a perdu une semaine parce qu’on n’avait pas figé le schéma de données ; depuis, je commence par le modèle et les migrations ». Le recruteur ne juge pas l’échec, il juge la lucidité et la boucle d’apprentissage.
« Qu’as-tu fait, toi, précisément, dans ce projet de groupe ? » — Réponse au « je », périmètre net, et créditez les autres : « j’ai pris le serveur de jeu et le pub/sub Redis ; le front, c’était Marie et Tom ». Créditer l’équipe renforce votre crédibilité — celui qui a vraiment contribué n’a pas besoin de tout s’attribuer.
« Pourquoi avoir choisi [techno X] ? » — Structure : le besoin, les options considérées, le critère qui a tranché. « C’est ce qu’on connaissait » est acceptable si vous l’assumez et savez nommer ce que vous compareriez aujourd’hui. La pire réponse : une justification inventée que la question suivante démonte.
« Que referais-tu différemment ? » — La question cadeau : elle teste si vous avez re-réfléchi au projet depuis. Une réponse d’architecture (« je séparerais le serveur de jeu de l’API REST ») ou de méthode (« tests de charge dès le début ») montre la prise de recul. « Rien » signifie que vous n’avez pas progressé depuis.
« Tu peux me montrer quelque chose ? » — Oui, toujours : URL déployée, GIF dans le README, ou démo locale préparée. Montrer un truc qui marche en 30 secondes vaut dix minutes de description. Et si la démo plante : plan B vidéo, sans paniquer — la gestion de l’imprévu fait aussi partie de l’évaluation.
Pièges & idées reçues
- Réciter la stack — « React, Node, MongoDB, Docker » n’est pas une histoire. La stack arrive dans les décisions (« pourquoi Mongo ? »), pas en ouverture.
- Le pitch de dix minutes — 90 secondes puis silence : laisser l’intervieweur choisir où creuser. Un monologue qui déroule toute l’architecture épuise l’attention et cache vos points forts.
- La fausse modestie — « c’est un petit projet, pas grand-chose » sabote votre propre travail avant même de le montrer. Un petit projet bien raconté (problème réel, décision réfléchie, leçon) vaut un gros projet survolé.
- Embellir — l’intervieweur tech creuse jusqu’à la couche où vous ne savez plus répondre. Si « j’ai fait le back » devient flou à la troisième question sur les index, la crédibilité de tout le reste s’effondre. Le périmètre honnête est infiniment plus solide.
⚠️ La démo sans plan B — filmez votre démo (30 s, capture d’écran) avant chaque entretien. Wifi capricieux, service gratuit endormi, dépendance cassée la veille : la démo live échoue pour des raisons qui n’ont rien à voir avec votre travail. Le candidat qui enchaîne calmement sur sa vidéo marque plus de points que celui qui relance nerveusement son terminal.
Pour aller plus loin
- Tech Interview Handbook — behavioral round : la préparation structurée des questions non techniques
- Brag documents (Julia Evans) : noter ses réalisations au fil de l’eau — le réflexe à prendre dès le stage
- Make a README : la checklist du README qui donne envie de cloner
- La méthode STAR : la version d’origine, utilisée par les RH
Cette fiche clôt le programme de veille. Les dizaines de fiches accumulées — Docker, bases de données, HTTP, sécurité, LLM en prod, UTF-8… — sont votre vivier d’anecdotes techniques : chaque section « En entretien » est une réponse prête à l’emploi, chaque « Piège vécu » une histoire à raconter. La veille de chaque entretien, relisez les fiches liées au poste et vos deux ou trois projets préparés. Vous avez le matériau ; il ne reste qu’à le raconter. Bonne chance.
The essentials
In an internship interview, you have little professional experience: your projects are your experience. The interviewer isn’t looking for a list of technologies — they check that you can explain a context, justify a decision, measure a result and draw lessons from it. The tool: the STAR structure adapted to tech, Context → Problem → Decisions → Result → Lessons.
| Step | The question you’re answering | Filled-in example (real-time quiz) |
|---|---|---|
| Context | What, for whom, what team, what deadline? | “Live quiz app for school parties — 4 people, 3 weeks” |
| Problem | What concrete, measurable difficulty? | “Live scores for 200 players; our HTTP polling collapsed at 80” |
| Decisions | What choices, against which alternatives, and who did what? | “WebSockets over polling, Redis pub/sub per room; I designed and coded the game server” |
| Result | What worked, with what numbers? | “250 simultaneous connections held in real conditions, latency < 200 ms” |
| Lessons | What would you do differently? | “Load tests from week 1: we discovered our limit in front of users” |
Each row of the table fits in one or two sentences: together they make a 90-second story, after which the interviewer digs wherever they want. That is exactly what they expect.
How it works
Pick 2-3 projects and know them inside out. Three mastered stories beat eight skimmed CV lines. For each one, prepare: the architecture (drawable on a whiteboard), the decisions and their alternatives, one or two numbers, what went wrong, what you’d redo differently. Self-criticism is a plus: “today I would split that service” signals maturity, not weakness.
Quantify when possible. “A fast app” says nothing; “load time went from 4 s to 800 ms after caching the queries” tells an investigation. Users, latency, data volume, time saved: an honest number, even a modest one, beats a superlative.
Own your technical choices. “Why Postgres?” deserves a real answer — and “it’s the database we knew, our data was relational, it was the safe choice in three weeks” is one: honest, contextualized, defensible. The bad reflex: inventing an after-the-fact scholarly justification that collapses at the second question.
The 90-second pitch, written and rehearsed before the interview:
"My most formative project: a real-time quiz app
for school parties. [context, 15 s]
The challenge: displaying live scores for 200
players — our first attempt with HTTP polling
collapsed at 80 connections. [problem, 15 s]
We moved to WebSockets, with Redis pub/sub to
broadcast per room. Me, I designed and coded the
game server, and measured the difference with a
load test. [decisions, 30 s]
Result: 250 simultaneous players at a real party,
under 200 ms of latency. [result, 15 s]
If I started over, I'd run load tests from the
first week — we discovered our limits in front
of the users." [lessons, 15 s]🎤 In an interview — “Tell me about a project you’re proud of.” The question comes up in almost every internship interview, often as the opener. Never answer with the stack (“it’s React with Node…”): roll out the 90-second pitch, then let the interviewer dig. Whoever asks that question wants a story, not an inventory.
Key concepts to master
- Tech STAR: Context → Problem → Decisions → Result → Lessons. The HR version (Situation, Task, Action, Result) works too; what matters is the order — context before details, result before lessons.
- The “you, precisely”: in a group project, the interviewer will isolate your contribution. Prepare the answer in the first person: “I designed the database schema and the auth API; Marie did the front end”. Claiming the whole project gets detected within three technical questions.
- Calibrated self-criticism: one real failure + what it taught you + what you’d do now. Neither “nothing went wrong” (nobody believes it), nor self-flagellation (the intern who demolishes themselves worries people).
- The demo that works: a deployed URL tested that same morning, and an offline plan B — a video capture or GIF in the README. Meeting-room wifi always betrays you.
- The clean GitHub: an interviewer spends 90 seconds on a repo. README with a screenshot, one sentence on the what and the why, launch instructions that work (
docker compose upideally — see the Docker topic), no committednode_modules, no secrets in the history. - Tie each project to the role: reread the job posting the night before. Each required skill should hook onto an anecdote from one of your projects. Backend role → data modeling, the API, migrations; front-end role → state, performance, accessibility.
💡 The README does half the work — an interviewer who opens a repo with a screenshot, a two-sentence description and a
docker compose upthat works already has a good impression before the interview. It’s the only document you control 100% and that speaks for you in your absence. One hour of writing, repaid at every application.
In an interview
“What went wrong in this project?” — Never “nothing”. One precise failure, its cause, what you changed: “we lost a week because we hadn’t frozen the data schema; since then, I start with the model and the migrations”. The interviewer isn’t judging the failure, they’re judging lucidity and the learning loop.
“What did you, precisely, do in this group project?” — Answer in the first person, with a clear scope, and credit the others: “I took the game server and the Redis pub/sub; the front end was Marie and Tom”. Crediting the team strengthens your credibility — whoever really contributed doesn’t need to claim everything.
“Why did you choose [technology X]?” — Structure: the need, the options considered, the criterion that settled it. “It’s what we knew” is acceptable if you own it and can name what you would compare today. The worst answer: an invented justification that the next question dismantles.
“What would you do differently?” — The gift question: it tests whether you’ve re-thought the project since. An architecture answer (“I’d separate the game server from the REST API”) or a method answer (“load tests from the start”) shows perspective. “Nothing” means you haven’t progressed since.
“Can you show me something?” — Yes, always: a deployed URL, a GIF in the README, or a prepared local demo. Showing something that works in 30 seconds beats ten minutes of description. And if the demo crashes: video plan B, without panicking — handling the unexpected is part of the evaluation too.
Pitfalls & misconceptions
- Reciting the stack — “React, Node, MongoDB, Docker” is not a story. The stack belongs in the decisions (“why Mongo?”), not in the opening.
- The ten-minute pitch — 90 seconds then silence: let the interviewer choose where to dig. A monologue unrolling the whole architecture exhausts attention and hides your strong points.
- False modesty — “it’s a small project, nothing much” sabotages your own work before even showing it. A small project told well (real problem, considered decision, lesson) beats a big project skimmed over.
- Embellishing — the technical interviewer digs down to the layer where you can no longer answer. If “I did the backend” turns vague at the third question about indexes, the credibility of everything else collapses. An honest scope is infinitely more solid.
⚠️ The demo without a plan B — record your demo (30 s, screen capture) before every interview. Flaky wifi, a free-tier service gone to sleep, a dependency broken the night before: live demos fail for reasons that have nothing to do with your work. The candidate who calmly switches to their video scores more points than the one nervously restarting their terminal.
Going further
- Tech Interview Handbook — behavioral round: structured preparation for non-technical questions
- Brag documents (Julia Evans): logging your achievements as you go — the reflex to build from your internship onwards
- Make a README: the checklist for a README that makes people want to clone
- The STAR method: the original version, used by HR
This topic closes the program. The dozens of topics you’ve accumulated — Docker, databases, HTTP, security, LLMs in production, UTF-8… — are your pool of technical anecdotes: every “In an interview” section is a ready-made answer, every “real-world trap” a story to tell. The night before each interview, reread the topics tied to the role and your two or three prepared projects. You have the material; all that’s left is to tell it. Good luck.