L'entrevue frontend

Les modules précédents t'ont donné de la matière : le navigateur, le CSS, les formulaires, les Server Components, les tests. Celui-ci ne t'apprend presque aucune technique nouvelle — il t'apprend à parler de ce que tu sais déjà, la compétence qui décide de la plupart des stages. Bonne nouvelle : contrairement à la connaissance technique, qui met des années à s'accumuler, la manière de répondre s'améliore en quelques heures de préparation ciblée.

Ce qu'on évalue vraiment chez un stagiaire

Démontons une croyance répandue : l'idée qu'on serait évalué sur l'étendue de ses connaissances. C'est faux pour un stage, pour une raison pragmatique : la personne en face sait que tu ne connais pas grand-chose, c'est écrit sur l'offre. Elle ne cherche pas un senior au rabais, mais quelqu'un qu'elle pourra encadrer sans que ça lui coûte trop cher et qui produira de la valeur dans trois mois. Elle regarde donc trois choses.

Un — est-ce que tu raisonnes à voix haute ? Puis-je voir ton processus de pensée, ou seulement un résultat qui sort d'une boîte noire ? Encadrer un stagiaire, c'est discuter de problèmes non résolus : s'il répond par un silence puis une phrase définitive, on ne sait pas où il s'est perdu. S'il dit « je vois deux directions possibles, la première serait de… », on corrige sa trajectoire en une phrase. Un stagiaire qui pense fort est encadrable, donc embauchable.

Deux — est-ce que tu sais dire « je ne sais pas » proprement ? Il y a une manière catastrophique de le dire (« euh… non, je sais pas », silence) et une excellente :

« Je n'ai pas utilisé cette bibliothèque directement. Ce que je comprends, c'est
qu'elle résout le problème de [X] — sinon on doit le faire à la main avec [Y].
Si je devais l'intégrer, je commencerais par lire sa doc pour voir quelle forme
elle donne aux données, et je ferais un petit exemple isolé avant de la brancher
dans le vrai projet. »

Trois mouvements : j'admets, je situe le problème que ça résout, je décris comment je m'y prendrais.

Cette réponse démontre trois compétences que la bonne réponse toute faite ne démontrerait pas. L'honnêteté, qui est une donnée opérationnelle : ton futur maître de stage doit pouvoir croire ton « ça va me prendre deux jours ». La capacité à raisonner par problèmes plutôt que par outils. Et l'autonomie d'apprentissage : tu viens de décrire ta méthode pour absorber du neuf.

Le bluff échoue toujours au deuxième niveau, parce que la question suivante creuse systématiquement : l'intervieweur enchaîne sur ce que tu viens d'affirmer. Si tu as dit « oui, j'ai utilisé React Query », la question d'après sera « et comment tu gérais l'invalidation du cache après une mutation ? » — aucune sortie honorable. Alors que « je ne l'ai pas utilisé, mais je sais que ça enlève le triptyque loading / error / data qu'on réécrit dans chaque composant » marque des points et te laisse le contrôle.

Trois — à quelle vitesse apprends-tu ? Le seul critère qui compte vraiment sur six mois, et il n'est pas directement observable : on le mesure par des indices. Poses-tu des questions de clarification avant de foncer ? Reformules-tu ce qu'on vient de t'expliquer ? Sais-tu dire « ah tiens, je n'avais pas vu ça comme ça » ? Un candidat qui change d'avis en cours d'entrevue, en expliquant pourquoi, marque énormément de points.

Le déroulé typique d'un processus de stage frontend

Les processus varient, mais l'ossature est stable. Savoir quelle question chaque étape cherche à trancher te permet de calibrer ton effort au lieu de tout donner partout.

Deux remarques. La première : la colonne du milieu n'est jamais « est-ce qu'il connaît tout » — pas une seule ligne. C'est la confirmation, étape par étape, de la section précédente.

La seconde est stratégique. L'étape la plus décisive, et de loin la plus sous-préparée, c'est la présentation du code : tout le monde s'épuise sur le test technique puis arrive à la présentation en se disant « je connais mon code, ça va aller ». Or connaître son code et savoir le raconter sont deux compétences différentes, et un test moyen bien présenté passe souvent devant un test excellent mal présenté — logique dès qu'on considère que le métier consiste à construire quelque chose avec d'autres gens.

La grammaire de la réponse technique

Le patron le plus rentable de toute ta préparation. Il répond à toutes les questions qui commencent par « pourquoi », qu'elles portent sur un découpage de composants, un choix d'outil, une structure de données ou une approche de rendu :

« J'ai choisi X parce que [raison liée au contexte].
  L'alternative était Y, qui a l'avantage de [Z],
  mais ici [pourquoi X gagne dans ce contexte précis]. »

Quatre morceaux : le choix, sa raison, l'alternative honnêtement créditée, l'arbitrage.

Comprends le mécanisme et tu n'auras plus besoin de mémoriser la formule. « J'ai choisi X parce que c'est bien » prouve une seule chose : que tu connais X. La question qui intéresse ton interlocuteur reste entière — connais-tu autre chose que X ? Peut-être que X est le seul outil que tu saches utiliser, peut-être que c'est ce que disait le tutoriel. Il ne peut pas trancher, donc il pose une question de plus.

En nommant Y et en lui reconnaissant un avantage réel, tu réponds avant qu'on demande, et tu prouves quatre choses : tu connais les deux options ; tu sais évaluer celle que tu n'as pas retenue ; tu as fait un choix délibéré ; tu sais le rattacher à un contexte, définition de l'ingénierie. Ce dernier point est le plus souvent raté : un choix technique n'est jamais bon dans l'absolu, il est bon pour ce projet, cette taille, cette équipe, ce délai. Le mot « ici » n'est pas décoratif.

Le crédit sincère accordé à l'alternative distingue une vraie réponse d'une récitation. « Y mais c'est nul », ce n'est pas arbitrer : une bonne phrase sur Y doit être une phrase qu'un défenseur de Y signerait.

Trois illustrations

Cas 1 — un découpage de composants. La question : « pourquoi avoir séparé le sélecteur et le formulaire au lieu d'un seul composant ? »

« J'ai séparé les deux parce qu'ils ont des responsabilités différentes : le
sélecteur choisit un service, le formulaire rend des fields et collecte des
réponses. L'alternative, un seul composant, aurait été plus simple à lire au
début — un seul fichier, aucun passage de props. Mais dès que le formulaire a
eu plusieurs types de fields, le fichier a dépassé 150 lignes et je devais
scroller pour comprendre. Là, chaque fichier fait moins de 80 lignes, et si on
remplace le sélecteur par une barre de recherche demain, le formulaire n'a même
pas besoin d'être touché : il reçoit une config, il ne sait pas d'où elle vient. »

Remarque le crédit honnête à l'alternative : « plus simple à lire au début » est vrai.

Cas 2 — un choix de rendu. La question : « pourquoi cette page est-elle un Server Component ? »

« Parce qu'elle ne fait qu'afficher des données : elle n'a ni état, ni
gestionnaire d'événement. En la laissant serveur, les données sont déjà dans le
HTML au premier affichage et son code ne part pas dans le bundle du navigateur.
L'alternative aurait été un composant client avec un useEffect et un fetch —
c'est ce que j'aurais fait il y a six mois, et l'avantage c'est que c'est un
seul modèle mental à tenir. Mais ici ça coûtait un aller-retour réseau de plus
après l'affichage, donc un spinner visible. J'ai juste extrait le bouton de
réservation en composant client, parce que lui a besoin d'un onClick. »

Le détail « c'est ce que j'aurais fait il y a six mois » est un aveu de progression : il raconte un apprentissage, pas seulement un choix.

Cas 3 — une absence de bibliothèque. La question : « pourquoi ne pas avoir utilisé une bibliothèque de formulaires ? »

« Le formulaire a cinq fields et une seule règle de validation, donc du
useState et une fonction de validation faisaient l'affaire — et je voulais que
le code reste lisible sans connaître une API de plus. L'alternative, react-hook-form,
a un vrai avantage : elle évite un re-render à chaque frappe en passant par des
refs, et elle branche la validation proprement. Sur un formulaire de trente
fields avec des règles conditionnelles, j'y serais allé sans hésiter. Ici,
l'ajouter aurait ajouté une dépendance pour un problème que je n'avais pas. »

« Un problème que je n'avais pas » : c'est la phrase qui referme proprement un débat d'outil.

CANDIDAT A
« Parce que c'est une bonne pratique de découper ses composants. Le principe de
responsabilité unique dit qu'un composant doit faire une seule chose, donc j'ai
appliqué ça. Ça rend le code plus maintenable et plus réutilisable. »

CANDIDAT B
« Au départ tout était dans le formulaire. Quand j'ai ajouté le troisième type
de champ, je me suis rendu compte que je copiais-collais le même bloc label +
input + message d'erreur pour la troisième fois. C'est là que je l'ai sorti.
Aujourd'hui il est utilisé à trois endroits ; si je change la façon d'afficher
les errors, je le fais une fois. J'aurais pu l'extraire dès le premier champ,
mais je ne savais pas encore de quoi il aurait besoin comme props. »

« J'ai fait des fields contrôlés, parce que j'avais besoin d'afficher les
errors pendant la saisie et de remettre le formulaire à zéro après l'envoi.
Les deux supposent que React connaisse les values à tout moment. »

Les six tradeoffs à savoir défendre

Les arbitrages qui reviennent le plus souvent en entrevue frontend junior. Pour chacun : le contexte en trois lignes, puis la phrase de réponse prête à adapter. La théorie complète est dans le module indiqué — ce qui suit n'est que la version orale.

a. Contrôlé ou non contrôlé

Un champ contrôlé a sa valeur dans l'état React (value + onChange) : React est la source de vérité, ce qui rend triviaux le reset, la validation en temps réel et la persistance, au prix d'un rendu par frappe. Un champ non contrôlé laisse la valeur dans le DOM et on la lit à la soumission (ref ou FormData) : moins de rendus, moins de code, mais tout ce qui doit réagir pendant la saisie devient compliqué. Détail dans « Formulaires 1 ».

« J'ai fait des fields contrôlés parce que j'avais besoin de deux choses
pendant la saisie : afficher les errors au fur et à mesure et pouvoir remettre
le formulaire à zéro après l'envoi. Les deux supposent que React connaisse les
values à tout moment. L'alternative non contrôlée est plus économique — un
rendu au lieu d'un par frappe, et FormData récupère tout d'un coup à la
soumission — mais ici le formulaire fait cinq fields, donc l'économie de rendus
ne se voit pas, alors que la validation en direct, elle, se voit. »

b. useState ou useReducer

useState est fait pour des morceaux d'état indépendants et des mises à jour directes. useReducer devient meilleur quand plusieurs morceaux changent ensemble, quand la valeur suivante dépend de la précédente, ou quand tu veux des transitions nommées (dispatch({ type: 'SUBMIT' })) plutôt qu'une rafale de setters. Voir « Formulaires 2 » et useState & useEffect.

« J'ai gardé useState parce que mon état, c'est un objet de values qui change
d'une seule façon : l'utilisateur tape, on remplace un champ. Il n'y a pas de
transition métier à nommer. Si j'avais eu les errors par champ, l'état
d'envoi en cours et l'état de succès à faire bouger ensemble, je serais passé
à useReducer — l'avantage étant que les trois setters éparpillés deviennent un
seul dispatch, et qu'on peut relire toutes les transitions possibles au même
endroit. Avec un seul type d'opération, ça n'aurait ajouté que de la cérémonie. »

c. CSS vanilla, CSS Modules ou Tailwind

CSS vanilla : aucune configuration, tout le monde sait le lire, mais les noms de classes sont globaux — donc collisions quand le projet grossit, qu'on limite par une convention de nommage. CSS Modules : le build rend chaque nom unique, donc scoping automatique sans dépendance. Tailwind : des classes utilitaires dans le JSX, très rapide à écrire, au prix d'un balisage plus chargé. Détail dans « CSS 1 » et « CSS 2 ».

« Le projet imposait du CSS vanilla, donc j'ai suivi, et j'ai adopté une
convention de nommage par blocs pour éviter les collisions. Sur un projet
libre, j'irais vers les CSS Modules : on garde exactement la même syntaxe CSS
mais le scoping est automatique, sans dépendance à ajouter. Je connais aussi
Tailwind — je l'utilise dans mon app mobile via NativeWind — et c'est très
efficace pour aller vite ; le compromis, c'est que le JSX devient plus lourd
à lire quand il y a quinze classes sur une balise. »

d. Server Component ou Client Component

Le tradeoff du moment : il a remplacé l'ancienne discussion « client-side / SSR / SSG », non pas parce qu'elle était fausse mais parce que la question ne se pose plus au niveau de la page — elle se pose composant par composant : ce bout d'interface a-t-il besoin du navigateur ? Un Server Component ne part pas dans le bundle, peut lire une base de données et livre ses données dès le premier affichage ; un Client Component peut avoir de l'état, des événements et window, mais son code voyage. Détail dans « Server et Client Components » et « Rendu & data fetching » pour le cache.

« Par défaut je laisse tout en Server Component, et je ne bascule en client que
là où il y a vraiment de l'état ou un événement — ici, uniquement le bouton et
le formulaire. L'avantage du client, c'est qu'on n'a qu'un seul modèle mental
et que tout est interactif partout ; l'inconvénient, c'est que 'use client' est
viral vers le bas le long des imports, donc mettre la directive en haut de la
page ferait descendre toute la page dans le bundle. Donc je pousse la frontière
le plus bas possible, vers les feuilles de l'arbre. »

Si on te pose l'ancienne question — « c'est quoi la différence entre SSR et SSG ? » — réponds franchement (SSG rend au build, SSR à chaque requête, l'ISR régénère en arrière-plan après un délai), puis reformule dans le vocabulaire d'aujourd'hui : ces trois modes existent toujours, mais dans l'App Router on ne les choisit plus par des fonctions comme getStaticProps, on les obtient par la façon de demander les données et les options de cache. Connaître les deux générations de vocabulaire prouve que tu as compris le mécanisme, pas seulement mémorisé la mode actuelle.

e. Route Handler ou Server Action

Un Route Handler est une vraie URL HTTP : appelable depuis n'importe quoi (autre service, application mobile, webhook), avec maîtrise des codes de statut et des en-têtes. Une Server Action est une fonction serveur que le composant client appelle comme une fonction locale : moins de code, pas d'URL à inventer, intégration naturelle avec les formulaires — mais c'est un détail interne, pas une interface publique. Détail dans « Route Handlers & Server Actions ».

« Pour la soumission du formulaire j'ai pris une Server Action : c'est une
mutation déclenchée depuis ma propre interface, personne d'autre n'a besoin de
l'appeler, et ça m'évite d'écrire une route, un fetch et la sérialisation des
deux côtés. J'aurais pris un Route Handler si l'endpoint devait être consommé
par autre chose que cette page — une app mobile, un service tiers, un webhook —
ou si j'avais besoin de contrôler finement le status HTTP et les en-têtes. La
validation côté serveur, elle, est obligatoire dans les deux cas. »

f. À la main ou avec une bibliothèque

La vraie question n'est pas « connais-tu react-hook-form ? » mais « sais-tu quand une dépendance vaut son coût ? ». Une bibliothèque achète du temps et de la robustesse ; elle coûte une API à apprendre, du poids, un lien à entretenir. La bonne réponse fait toujours référence à la taille du problème.

« Je ne l'ai pas utilisée sur ce projet. Ce qu'elle résout, c'est [le problème].
Comme mon cas était petit — [chiffre concret] —, le faire à la main tenait en
[quelques lignes] et ça évitait une dépendance de plus. À partir du moment où
[le seuil], j'irais la chercher, et c'est un outil que je serais curieux
d'utiliser sur un vrai projet. »

Le gabarit universel. Le « chiffre concret » est ce qui empêche la réponse de sonner creuse.

'use client';
import { useState } from 'react';

export default function PageServices({ services }: { services: Service[] }) {
  const [query, setQuery] = useState('');
  const visibles = services.filter((s) => s.nom.includes(query));

  return (
    <section>
      <input value={query} onChange={(e) => setQuery(e.target.value)} />
      {/* ... 180 lignes de contenu parfaitement statique ... */}
    </section>
  );
}

Les questions pièges, et comment ne pas y tomber

Une question piège n'est presque jamais malveillante : sa réponse évidente est mauvaise, et la bonne demande de repérer ce qu'on te demande vraiment. En voici quatre, par fréquence.

« C'est quoi la best practice pour X ? »

Le piège est dans le mot : il t'invite à réciter, et une récitation s'entend — le débit change, les phrases deviennent trop rondes, le vocabulaire est celui des tutoriels. Le réflexe qui sauve : transformer la question générale en question contextuelle. Il n'existe pas de meilleure pratique hors contexte, seulement des choix qui dépendent de la taille, de l'équipe et de l'échéance.

« Ça dépend de deux ou trois choses, je dirais. Sur un projet de la taille du
mien, l'approche par défaut c'est [X], parce que [raison]. Ce qui me ferait
changer d'avis, c'est [le facteur] : à partir de là, [Y] devient meilleur. Est-ce
que dans votre contexte vous êtes plutôt dans le premier cas ou dans le second ? »

La question finale n'est pas une esquive : c'est ce qu'un développeur expérimenté ferait spontanément, et elle transforme l'interrogatoire en conversation — toujours plus favorable au candidat.

« Pourquoi n'as-tu pas fait X ? »

Le piège est émotionnel : la question sonne comme un reproche, donc le réflexe est de se justifier, voire de s'excuser. Or on te demande comment tu as priorisé : dans un test de quatre heures, tout ce qui n'a pas été fait est un arbitrage, et l'intervieweur veut voir si tu l'as fait consciemment. Structure en trois temps : je l'ai vu — voici ce que j'ai fait passer avant et pourquoi — voici ce que ça coûterait de l'ajouter.

« J'y ai pensé, et je l'ai mis de côté volontairement. Avec le temps que j'avais,
j'ai priorisé [ce qui était explicitement demandé] et [ce qui casse l'expérience
si c'est absent]. X est important, mais il n'aurait rien fait tomber si je
l'avais raté, alors que [l'autre chose], oui. Concrètement, l'ajouter serait
une heure : [ce que tu ferais, précisément]. »

Note ce que cette réponse accomplit : elle ne s'excuse pas, elle expose un critère de priorisation. Et le critère « ce qui casse l'expérience si c'est absent » avant « ce qui serait mieux » est exactement celui qu'on applique dans une équipe qui livre.

« Quelle est la complexité de ton algorithme ? »

Le piège est la panique : le mot « complexité » évoque les grandes entrevues d'algorithmique, et beaucoup de juniors se figent en cherchant un souvenir de cours qu'ils n'ont jamais eu. Pour un stage frontend, l'attente est modeste : sais-tu compter tes boucles et dire si ça pose un problème à l'échelle de tes données ?

Quatre repères suffisent. O(1) — accès direct par clé (objet, Map) : le temps ne dépend pas de la taille. O(n) — un parcours : map, filter, find. O(n²) — une boucle dans une boucle sur le même tableau, ça grimpe très vite. O(n×m) — une boucle sur une liste, avec une recherche dans une autre à l'intérieur.

« Ma fonction parcourt la liste des services une fois, et pour chacun elle
regarde si la spécialité est dans le tableau du praticien. C'est donc une boucle
avec une recherche dedans — de l'ordre de n fois m. Avec les tailles réelles,
trois services et cinq spécialités, c'est instantané. Si on passait à des
milliers d'entrées, je construirais un index une seule fois — un objet ou une
Map dont la clé est l'identifiant — et la recherche redeviendrait directe. »

On décrit ce que le code fait, on rattache à la taille réelle des données, on donne le plan B. Aucun jargon obligatoire.

La phrase la plus importante de cette réponse est « avec les tailles réelles, c'est instantané » : elle prouve que tu sais qu'une optimisation sans mesure et sans échelle est du gaspillage — un réflexe que beaucoup mettent des années à acquérir.

« Qu'est-ce qui ne va pas dans ton code ? »

La plus importante du module. Le piège est de répondre « rien, je suis assez content ». Pire réponse possible, pour deux raisons. D'abord c'est faux, et tout le monde le sait — aucun code écrit en quatre heures n'est sans défaut, donc soit tu ne les vois pas, soit tu les caches. Ensuite, cette question n'est pas un test de modestie mais de capacité de revue de code, activité qui occupe une part énorme du travail en équipe : on t'offre l'occasion la plus directe de la démontrer.

C'est donc la question où on marque des points, à condition de la préparer. Deux ou trois faiblesses réelles, hiérarchisées, chacune avec sa correction — et choisies d'architecture ou de robustesse, pas des coquetteries : « j'aurais pu mieux nommer une variable » sonne comme une esquive, « je valide côté client mais pas côté serveur » comme quelqu'un qui comprend où sont les vrais risques.

« Trois choses, dans l'ordre où je les corrigerais.

Un : je valide les fields côté client seulement. Quelqu'un qui appelle
l'endpoint directement passerait à travers. C'est le vrai trou, et c'est ce que
je ferais en premier — un schéma de validation côté serveur avant l'écriture.

Deux : mon composant de page fait 140 lignes. Il mélange la récupération des
données et l'affichage. J'en sortirais la logique de sélection dans un hook, ce
qui le rendrait aussi testable sans monter tout le rendu.

Trois : mes messages d'erreur sont génériques. L'utilisateur voit "une erreur
est survenue" sans savoir quel champ reprendre. »

Trois défauts, classés par gravité, chacun avec sa correction. C'est une revue de code, pas une confession.

Relis la première des trois, découpée : « je valide les fields côté client seulement » (le fait), « quelqu'un qui appelle l'endpoint directement passerait à travers » (la conséquence concrète), « un schéma de validation côté serveur avant l'écriture » (la piste). C'est La critique en trois temps du module Lire et critiquer du code frontend, retournée vers ton propre code. Le seul temps qui change de forme est le troisième : devant ton rendu à toi, la proposition n'a plus besoin d'être posée en question, elle devient un plan.

« Parce que c'est la best practice en React. On dit qu'il faut faire remonter
l'état — le lifting state up — et que les composants doivent être le plus purs
possible. C'est recommandé dans la documentation officielle. »

« Parce que deux composants dépendent de cette valeur : le sélecteur, qui la
change, et le formulaire, qui doit changer de fields quand elle change. Si je
la gardais dans le sélecteur, le formulaire n'aurait aucun moyen d'être au
courant — il faudrait que le sélecteur lui parle, alors qu'ils sont côte à côte.
Donc elle vit dans leur parent commun, et chacun reçoit ce dont il a besoin en
props. C'est ce qu'on appelle faire remonter l'état, mais concrètement c'est
juste : la donnée vit au plus bas endroit d'où tous ceux qui en ont besoin
peuvent la voir. »

const rows = appointments.map((appointment) => ({
  ...appointment,
  serviceLabel:
    services.find((s) => s.id === appointment.serviceId)?.label ?? '—',
}));

Parler de soi sans expérience professionnelle

L'angoisse numéro un des candidats autodidactes, sur une prémisse fausse : « pas d'expérience professionnelle » ne veut pas dire « rien à raconter ». Tu as construit une application mobile complète — base de données locale, synchronisation vers le nuage, tests, couche d'analyse, décisions d'architecture tranchées seul. C'est de l'expérience. Ce qui te manque, ce n'est pas la matière, c'est sa traduction dans le vocabulaire d'une équipe.

Levier principal : arrête de présenter ton projet comme une liste de technologies, présente-le comme une suite de problèmes résolus. Personne ne s'émeut d'entendre « c'est fait en React Native avec Expo, WatermelonDB et Supabase ». Tout le monde écoute quand tu dis « le problème, c'est qu'une application de suivi d'entraînement doit marcher au sous-sol d'un gym, sans réseau. Donc tout est écrit d'abord dans une base locale, et la synchronisation se rattrape quand la connexion revient. Ce qui rend le sujet difficile, c'est le conflit : qu'est-ce qui gagne si la même donnée a changé des deux côtés ? »

Même projet, deux phrases. Mais la seconde démontre que tu as compris un problème d'architecture distribuée, alors que la première ne démontre que ta capacité à lire un package.json.

Troisième levier, sous-estimé : le parcours autodidacte est un argument, pas une excuse. Formule-le une fois, calmement. Un diplômé a suivi un programme qu'on lui a donné ; toi, tu as choisi d'apprendre alors que personne ne t'y obligeait, décidé seul quoi apprendre et dans quel ordre, buté sur des problèmes sans professeur à qui les poser — donc développé la compétence la plus utile en poste : trouver l'information toi-même et savoir quand tu es bloqué. Dis-le comme un fait, pas comme une compensation.

Les trois questions comportementales, et un patron pour toutes

Quel que soit le sujet, la structure gagnante est la même : Situation → Action → Résultat → Ce que j'en ai tiré. Les trois premiers temps font le récit, le quatrième fait la différence — c'est lui qui transforme une anecdote en preuve d'apprentissage, et c'est celui dont l'intervieweur se souviendra.

« Parle-moi d'un bug difficile. » On cherche ta méthode de diagnostic, pas la difficulté du bug. Choisis un bug dont la cause était surprenante mais explicable — pas le plus obscur de ta carrière.

SITUATION — « Un réglage de l'utilisateur revenait à sa valeur par défaut à
chaque redémarrage de l'app. Pas toujours : seulement ce réglage-là. »

ACTION — « J'ai d'abord vérifié que l'écriture partait bien — elle partait. Donc
le problème était après. J'ai relu ce qui se passait au chargement, et j'ai
trouvé : les données persistées passent par un schéma de validation, et ce champ
n'y avait pas été ajouté. Le schéma le retirait silencieusement à la lecture,
puis on réécrivait l'objet nettoyé par-dessus. »

RÉSULTAT — « Ajouté au schéma, plus un test qui échoue si un champ existe d'un
côté et pas de l'autre. »

CE QUE J'EN AI TIRÉ — « Que je cherchais au mauvais endroit : je regardais
l'écriture parce que le symptôme était "ça ne se sauvegarde pas", alors que la
perte avait lieu à la lecture. Depuis, devant un bug de persistance, je vérifie
les deux bouts avant de choisir un camp. »

La dernière phrase vaut les trois autres : elle montre une règle que tu as extraite de l'incident.

« Comment apprends-tu une nouvelle technologie ? » On cherche si ta méthode existe et si elle est réaliste. Une réponse crédible cite des étapes et avoue un coût.

« Je commence par la documentation officielle, mais pas en entier : je cherche
d'abord le modèle mental — qu'est-ce que cet outil croit être vrai du monde. Une
fois que j'ai ça, le reste des pages devient lisible. Ensuite je fais le plus
petit exemple qui marche, isolé, hors du vrai projet, pour ne pas mélanger mes
bugs avec les siens. Et je ne branche dans le projet qu'à la troisième étape.
Ce qui me ralentit le plus, c'est quand je saute la première étape : je copie un
exemple qui marche, et je suis incapable de le débugger quand il dévie. »

« Raconte-moi un désaccord technique. » C'est la plus délicate quand on travaille seul, et elle a une variante honnête : le désaccord avec toi-même, ou avec un conseil reçu en ligne. On cherche si tu peux argumenter sans t'entêter et changer d'avis sans t'écraser.

« Je travaille seul, donc mon vrai cas c'est un désaccord avec une convention
que j'avais adoptée. J'avais lu qu'il fallait mémoïser agressivement tous les
calculs dans les composants, et j'en mettais partout par réflexe. En relisant
mon code, je me suis rendu compte que ça alourdissait la lecture sans que
j'aie jamais mesuré quoi que ce soit. J'ai retiré ce qui n'était pas justifié
et je me suis donné une règle : pas d'optimisation sans un chiffre avant et
après. Ce que j'en tire, c'est que "recommandé" et "nécessaire ici" sont deux
choses différentes, et que la deuxième se vérifie. »

Une position tenue, un argument entendu, un changement d'avis motivé : c'est exactement la mécanique qu'on veut voir dans une revue de code.

Présenter son test technique à l'oral

L'étape décisive. Une seule règle domine tout le reste : ne lis jamais ton code ligne par ligne. C'est le réflexe naturel — écran partagé, premier fichier, on commence par les imports — et la manière la plus sûre de perdre ton auditoire en quatre-vingt-dix secondes : ton interlocuteur ne peut pas lire du code inconnu à la vitesse où tu le commentes, il décroche, puis pose des questions au hasard pour reprendre la main.

La solution : raconter l'architecture, et ne descendre dans le code qu'une fois, sur un chemin choisi. D'où le plan qui suit.

1. Le problème    — « On devait construire X, avec les contraintes Y. »
2. L'architecture — « J'ai découpé en A, B, C ; l'état vit dans A parce que… »
3. Une trace      — « Voici ce qui se passe quand l'utilisateur clique ici,
                     jusqu'au serveur. »
4. Un choix       — « J'ai pris X plutôt que Y parce que… »
5. La suite       — « Avec une journée de plus : validation serveur, tests,
                     accessibilité. »

Pour voir ce plan rempli avec du vrai contenu plutôt qu'avec des crochets, le module Étude de cas : la solution disséquée le déroule de bout en bout sur le projet de prise de rendez-vous. Chaque temps a son piège propre.

1. Le problème, en une phrase. Reformule l'énoncé avec tes mots, contraintes comprises. Ça paraît inutile — « ils connaissent leur énoncé » — mais ça vérifie que vous parlez de la même chose : si tu as mal compris une exigence, tout le monde le sait dans les dix premières secondes plutôt qu'à la fin. Et ça montre que tu sais résumer. Le piège : réciter l'énoncé mot pour mot.

2. L'architecture, en une phrase par pièce. Nomme les trois ou quatre morceaux et dis où vit l'état. Pas de fichiers, pas de noms de fonctions : des rôles. « Il y a la page, qui charge les données et tient l'état de sélection ; le sélecteur, qui remonte un choix ; le formulaire, qui reçoit une configuration et rend des champs ; et un composant de champ, réutilisé pour les trois types. » En quatre phrases, ton interlocuteur a une carte mentale à laquelle raccrocher la suite. Le piège : commencer par l'arborescence des dossiers — personne n'a jamais compris une application en écoutant la liste de ses dossiers.

Ce « composant de champ, réutilisé pour les trois types » porte un nom, et le nommer vaut mieux que le décrire : c'est Le traducteur unique du module Étude de cas : la solution disséquée — un seul endroit du projet traduit le vocabulaire des données ("dropdown", "phone") vers celui du HTML (<select>, type="tel"), et partout ailleurs on parle « config ». Poser un nom de patron à l'oral fait ce que fait un bon nom de variable : ton interlocuteur sait immédiatement où ranger ce que tu viens de dire, et il n'a plus besoin de te demander pourquoi ce composant existe.

3. Une trace, de bout en bout. Le cœur, et ce que presque personne ne fait. Choisis une action utilisateur et suis-la complètement : le clic, le gestionnaire, le changement d'état, le nouveau rendu, l'appel réseau, le traitement serveur, le retour, l'affichage. Une seule trace bien racontée démontre plus de compréhension que dix fichiers survolés, parce qu'elle prouve que tu as le système entier en tête. Le piège : en choisir deux par crainte que la première ne suffise pas. Une seule, complète.

4. Un choix assumé, avec son alternative. Ici tu ressors la grammaire de la section « La grammaire de la réponse technique ». Choisis d'avance lequel — le plus discutable, pas le plus évident. Présenter spontanément un choix contestable désamorce la question qu'on allait te poser et change ton statut : tu n'es plus interrogé, tu exposes. Le piège : choisir un point trivial pour éviter le débat. On le sent, et la vraie question tombe juste après.

5. La suite. Deux ou trois choses concrètes, calibrées au temps du test. Après quatre heures, ne promets pas l'authentification, le déploiement continu et une refonte : promets la validation côté serveur, deux tests sur la logique de sélection, le passage au clavier. Le piège : la liste trop ambitieuse, qui signale qu'on ne sait pas estimer.

La gestion du temps

Si on t'annonce trente minutes, vise dix à douze minutes de présentation et laisse le reste aux questions. Contre-intuitif — on a envie de tout montrer — mais les questions sont la partie où tu apprends ce qui les intéresse, et où l'exposé devient un échange. Une présentation qui déborde force l'intervieweur à te couper.

Répète à voix haute au moins une fois, chronomètre en main. Pas dans ta tête : les deux ne prennent pas le même temps et ne produisent pas les mêmes phrases. C'est probablement l'heure de préparation la plus rentable du processus.

« Non, je n'ai pas eu le temps. Désolé, c'est vrai que j'aurais dû. »

« Pas complètement, non. Ce que j'ai fait par défaut, c'est d'utiliser des
balises natives — de vrais <button>, un vrai <form>, des <label> associés à
leurs fields par htmlFor. Ça donne gratuitement le focus, la navigation au
clavier et l'annonce correcte par un lecteur d'écran, et c'est 80 % du travail.

Ce qui manque, et c'est ce que je ferais en premier : les messages d'erreur ne
sont reliés à leur champ que visuellement — il faudrait aria-describedby et
aria-invalid pour qu'un lecteur d'écran les annonce. Ensuite, après la
soumission, le focus reste où il était : il devrait aller sur le message de
confirmation. Et je vérifierais les contrastes, je ne les ai pas mesurés. »

Le live coding

Tout le monde le redoute, pour une mauvaise raison : on croit qu'on est évalué sur le résultat. On ne l'est pas, ou très peu. Un exercice de live coding est calibré pour être un peu trop long ; il est fréquent que personne ne le finisse. Ce qu'on observe, c'est comment tu travailles quand on te regarde — le seul moment du processus où l'on voit ton processus en direct au lieu de son résultat déjà propre. Quatre comportements font la différence.

Un — clarifie l'énoncé avant de taper. Une minute, reformule, pose deux questions. « Est-ce que la liste peut être vide ? » « Les identifiants sont-ils uniques ? » « Tu veux que je gère l'échec de la requête, ou je me concentre sur le chemin nominal ? » Chacune est un point marqué, pour une raison sans rapport avec l'exercice : en équipe, celui qui clarifie avant de coder est celui qui ne perd pas deux jours à construire la mauvaise chose. Et une bonne question révèle souvent que l'énoncé était volontairement ambigu — c'était l'épreuve.

Deux — pense à voix haute, tout le temps. Le silence est ton pire ennemi : quand tu te tais, ton évaluateur n'a plus rien à évaluer et commence à imaginer le pire. Dis ce que tu fais même quand c'est trivial (« je commence par une fonction qui prend le tableau et rend le tableau filtré, je m'occupe du rendu après »), et surtout ce que tu envisages (« je pourrais faire une boucle imbriquée mais ça va être lent si la liste grossit, donc je vais plutôt construire un index »). Second bénéfice : quand tu penses fort et que tu pars dans la mauvaise direction, on te rattrape. En silence, on te laisse aller au bout.

Trois — fais marcher avant de faire beau. Écris la version bête qui fonctionne, dis explicitement que c'est la version bête, améliore si le temps le permet. « Là je fais un double parcours, c'est du n fois m ; ça marche, et si on a le temps je le remplacerai par une Map. » Tu as du code qui tourne — le socle le plus rassurant qui soit — et tu as prouvé que tu voyais le problème. Chercher l'élégance d'emblée finit souvent en écran à moitié écrit qui ne s'exécute pas.

Quatre — termine en disant ce que tu testerais. Même sans écrire de test, nommer trois cas prend quinze secondes : « le cas nominal, le tableau vide, et le cas où aucun élément ne correspond — c'est celui-là qui casse le plus souvent, parce que ça renvoie undefined et que le rendu explose plus loin. » Tu montres que tu penses aux cas limites sans qu'on te les demande.

Les 48 heures avant, et le jour même

La règle qui gouverne tout : à ce stade, on relit, on n'apprend pas. Un savoir frais est un savoir fragile, et un savoir fragile sous stress devient un savoir faux. Pire, il t'incitera à en parler — et c'est toujours sur les sujets à moitié digérés qu'on se fait démonter. À quarante-huit heures, le rendement est entièrement dans la consolidation.

• Relis tes propres notes, pas des tutoriels. Tes notes sont organisées selon ta tête ; un cours neuf ne l'est pas. Ici, la relecture la plus rentable est celle des encadrés « À retenir » et « 🎤 En entrevue ».
• Prépare trois histoires de projet réutilisables — un bug difficile, une décision d'architecture, un apprentissage. Les mêmes trois répondent à une dizaine de questions, à condition de savoir les raconter en deux minutes. Écris-les au format Situation → Action → Résultat → Ce que j'en ai tiré, et dis-les une fois à voix haute.
• Relis ton propre rendu avec la grille de critique : trois faiblesses, trois corrections. Une heure, et deux questions fréquentes sont couvertes.
• La logistique, la veille : caméra, micro, partage d'écran testé pour de vrai, projet qui démarre sans erreur, éditeur en gros caractères, connexion de secours, de l'eau à portée de main, et cinq minutes d'avance le jour J.
• Écris tes trois questions de fin. Sur papier, à côté de toi. Sous pression, on oublie même celles qu'on avait trouvées excellentes.
• Dors plus que tu ne révises. Pas un conseil de bien-être, un calcul : les deux capacités qui te serviront le plus — mémoire de travail et vitesse de récupération d'un souvenir — sont celles que la fatigue détruit en premier. Une heure de révision à minuit coûte plus qu'elle ne rapporte.

Le jour même : relis tes notes une seule fois, le matin, puis referme tout. Et si tu as le droit à des notes (en visioconférence, tu l'as toujours), garde une seule feuille visible : le plan en cinq temps, tes trois histoires en trois mots chacune, tes trois questions. Pas plus — une feuille dense, on la lit au lieu de parler.

Après l'entrevue

Deux gestes, dont le second est le plus important pour la suite de ta recherche.

Le email de suivi, dans les vingt-quatre heures, cinq à six lignes. Remercie, puis fais une chose que la plupart ne font pas : rebondis sur un point précis de la conversation. Si une question t'a mis en difficulté et que tu as trouvé la réponse depuis, c'est le moment idéal — « vous m'aviez demandé comment j'aurais géré l'invalidation du cache ; j'y ai repensé, et je crois que la bonne approche aurait été… ». Geste rare, et exactement le signal qu'on cherche chez un stagiaire : quelqu'un qui repart avec la question et revient avec la réponse.

Le refus, converti en information. Un refus n'est pas une évaluation de ta valeur : c'est une décision prise avec très peu de données, souvent entre plusieurs candidats corrects, parfois pour des raisons sans rapport avec toi — un budget, un profil déjà en tête, un projet reporté. Mais il contient presque toujours de l'information exploitable.

• Demande un retour, une fois, poliment, sans négocier. « Merci de l'avoir considéré. Si vous avez deux minutes, y a-t-il un point précis sur lequel vous me conseilleriez de travailler ? » Beaucoup ne répondront pas ; ceux qui répondent donnent parfois une phrase qui vaut des semaines de devinettes. Ne discute jamais le retour reçu : tu remercies, tu notes, tu analyses plus tard.
• Note les questions qui ont coincé, le jour même. Toutes celles qui t'ont fait hésiter, y compris — surtout — celles auxquelles tu as fini par bien répondre après un blanc. C'est une carte de tes trous, dressée par des professionnels, gratuitement.
• Rattache chaque question à un module. L'étape qui transforme la liste en plan de travail. « Je n'ai pas su expliquer pourquoi ce composant devait être client » → « Server et Client Components ». « J'ai pataugé sur la validation » → « Formulaires 2 ». « Je n'ai pas su critiquer mon code » → « Lire et critiquer du code frontend ». Tu obtiens deux ou trois modules à relire, priorisés par le terrain plutôt que par ton intuition.

Mené ainsi, un refus devient un diagnostic. Le renversement coûte un effort réel — un refus fait mal, l'envie naturelle est de tourner la page vite. Mais la deuxième entrevue d'une série est presque toujours meilleure que la première, et ce n'est pas de la chance : c'est le retour de la première, exploité.