Que testent vraiment les entretiens d'ingénieur frontend ?

À qui vous parlerez réellement

Un cycle d'entretien pour ingénieur frontend passe généralement par trois ou quatre conversations distinctes, chacune vérifiant quelque chose de différent. D'abord un entretien avec un recruteur, surtout logistique et fourchette salariale. Ensuite un appel avec le responsable du recrutement, qui teste vraiment si vous savez décrire clairement votre propre travail — ce que vous avez construit, ce dont vous étiez responsable, ce que vous changeriez. Puis un ou deux tours techniques, généralement avec un ingénieur en poste dans l'équipe que vous rejoindriez, parfois deux ingénieurs dans le même appel pour que l'un observe pendant que l'autre mène. Pour les postes seniors, il y a souvent une conversation séparée sur l'architecture ou la conception système, parfois avec un staff engineer ou un tech lead qui ne sera pas votre manager. S'il y a un exercice à emporter, sa revue constitue un tour distinct en soi — quelqu'un lit votre code avant même de vous parler, et la conversation qui suit est entièrement construite autour de vos décisions, pas du fait que ça fonctionne.

La personne qui mène le tour technique n'est presque jamais des RH. C'est important, car les questions cessent de porter sur votre CV et commencent à vérifier si vos explications tiennent quand quelqu'un qui fait le métier les met à l'épreuve.

L'entretien technique : ce qu'il vérifie

La plupart des entretiens techniques pour ce poste se déroulent sur des éditeurs partagés — CoderPad, CodeSandbox, une session VS Code Live Share — et couvrent un mélange de JavaScript vanilla et de travail spécifique au framework. Schéma courant : d'abord un petit exercice vanilla JS (écrire un debounce, aplatir un tableau imbriqué, implémenter un émetteur d'événements simple), puis une tâche de composant dans ce que l'équipe utilise réellement — React, Vue, Svelte. La partie vanilla existe précisément parce que les frameworks cachent les fondamentaux. Un recruteur qui vous fait écrire debounce à la main ne teste pas si vous pouvez l'écrire de mémoire ; il vérifie si vous comprenez les closures et la boucle d'événements assez bien pour raisonner sur pourquoi debounce en a besoin, ce qui apparaît dès qu'il demande « que se passe-t-il si l'utilisateur démonte le composant alors que le timer est encore en attente ? »

Côté framework, une tâche typique : construire un petit morceau d'UI avec état, un appel API, des états de chargement et d'erreur, et peut-être une liste avec des clés. Ce qui est noté est rarement si ça s'affiche. C'est si vous gérez les parties ennuyeuses — conditions de concurrence si l'appel API se résout dans le désordre, ce qui se passe sur une liste vide, pourquoi vous mettez la clé sur l'élément de liste et pas sur l'index. Un candidat qui obtient un composant fonctionnel mais ne peut pas expliquer pourquoi il a utilisé key={item.id} au lieu de key={index} a produit du résultat sans comprendre, et cet écart est exactement ce que ce tour existe pour trouver.

CSS et mise en page : la partie pour laquelle on se prépare mal

Les entretiens frontend testent encore CSS directement, souvent séparément de JavaScript, parce que c'est la partie pour laquelle les candidats trichent le plus souvent avec les classes utilitaires d'un framework. Attendez-vous à devoir faire une mise en page avec Flexbox ou Grid en direct, sur un tableau blanc ou dans un éditeur partagé, parfois sans framework et sans préprocesseur. La vraie question derrière « comment centreriez-vous ceci » n'est jamais le centrage — c'est si vous comprenez le box model, les contextes d'empilement et la spécificité assez bien pour corriger un bug de mise en page que vous n'avez jamais vu, sur une page que vous n'avez pas écrite, sous un peu de pression temporelle. « Pourquoi utiliseriez-vous Grid ici plutôt que Flexbox » est une question de jugement. Il y a un raisonnement réel et défendable — Grid pour la mise en page bidimensionnelle, Flexbox pour un axe avec dimensionnement piloté par le contenu — et un recruteur qui travaille là-dedans quotidiennement remarquera immédiatement si vous répétez une règle que vous avez lue plutôt qu'une que vous avez réellement appliquée.

Les questions qui ressemblent à de la conversation mais n'en sont pas

Quelques questions reviennent dans les entretiens frontend précisément parce qu'il est difficile d'y répondre bien sans expérience réelle, même si elles sonnent comme de la simple discussion :

• « Décrivez-moi ce qui se passe depuis la saisie d'une URL jusqu'à l'apparition de la page à l'écran. » Cela vérifie si vous comprenez le DNS, le cycle requête/réponse, le parsing, le chemin de rendu critique, et où s'insèrent des choses comme les scripts bloquant le rendu ou defer/async. Une réponse superficielle s'arrête à « le navigateur récupère le HTML et le rend ». Une vraie réponse mentionne la différence entre parsing et rendu, pourquoi le CSS bloque le rendu et le JS peut bloquer le parsing, et où s'insère l'hydratation si l'app est rendue côté serveur.
• « Parlez-moi d'une fuite mémoire que vous avez déboguée. » Celle-ci filtre vite. Les gens qui l'ont vraiment fait nomment l'outil — l'onglet Memory de Chrome DevTools, un snapshot de heap, des nœuds DOM détachés, un écouteur d'événements jamais retiré au démontage — et décrivent un correctif spécifique. Les gens qui ne l'ont pas fait disent « je chercherais des fuites mémoire dans le code » et ne vont pas plus loin.
• « Pourquoi avez-vous choisi [Redux / Context / Zustand / ce que vous avez utilisé] pour l'état ici ? » Le recruteur connaît déjà la réponse à « que fait Redux ». Il demande si vous l'avez pesé contre des alternatives pour ce problème spécifique — l'état était-il partagé entre de nombreux composants distants, aviez-vous besoin du débogage par voyage dans le temps, ou l'avez-vous pris par habitude. « Redux est bon pour l'état global » reformule un fait que tout le monde dans la pièce connaît déjà.
• « Comment rendriez-vous cette liste navigable au clavier / comment un lecteur d'écran lirait-il ce composant ? » Les questions d'accessibilité sont un signal fort car si peu de candidats ont réellement utilisé un lecteur d'écran ou lu WCAG au-delà d'un résumé de blog. Nommer des rôles ARIA que vous avez mémorisés sans expliquer quel élément HTML natif les aurait rendus inutiles se lit comme une connaissance de surface, pas de la pratique.

À quoi ressemble une réponse superficielle de l'intérieur

Quelqu'un qui examine régulièrement des candidats frontend peut entendre une réponse répétée en une phrase ou deux. Elle tend à avoir trois caractéristiques : elle nomme l'outil sans décrire le mécanisme (« React utilise un DOM virtuel pour la performance » sans mention de la réconciliation ou de quand le diffing aide vraiment versus quand il ne le fait pas), elle traite une question de compromis comme une question factuelle (« CSS-in-JS est meilleur parce que c'est scopé », sans reconnaissance du coût d'exécution ou des alternatives au moment de la construction comme vanilla-extract), et elle ne peut pas survivre à une question de suivi. Si vous dites « j'ai amélioré le temps de chargement », et que la question honnête suivante — « de combien, et avec quoi l'avez-vous mesuré, Lighthouse ou autre chose ? » — vous rend vague, c'est l'écart que l'entretien était conçu pour trouver. La même chose s'applique aux bases de sécurité : nommer XSS et CSRF n'est pas la même chose qu'expliquer pourquoi React échappe les valeurs par défaut et où cette protection s'arrête (dangerouslySetInnerHTML brut, scripts tiers, innerHTML depuis une réponse API).

Le point controversé : algorithmes et exercices à emporter

Il y a un vrai désaccord dans l'industrie sur la question de savoir si les ingénieurs frontend doivent affronter des tours d'algorithmes style LeetCode, étant donné que le travail est surtout UI, état et comportement navigateur plutôt que conception de structures de données. Certaines entreprises les gardent parce qu'ils sont faciles à noter de manière cohérente entre candidats ; d'autres les ont abandonnés en faveur du pairing sur des tâches UI réalistes, arguant que le tour d'algorithmes mesure la pratique de l'entretien plus que la compétence au travail. Aucune vue n'a réglé l'argument, et vous rencontrerez les deux types de recruteur, donc ça vaut le coup de demander directement au recruteur ce que le tour technique contient réellement plutôt que de deviner. Les exercices à emporter ont une division similaire : certaines équipes les utilisent pour respecter le temps des candidats par rapport au codage en direct, d'autres les ont abandonnés parce que des exercices de plusieurs heures non payés filtrent les gens avec moins de temps libre plutôt que moins de compétence. Si on vous en donne un, la conversation de suivi à ce sujet compte généralement plus que l'exercice lui-même — attendez-vous à ce qu'on vous demande pourquoi vous avez structuré les composants comme vous l'avez fait, pas juste si ça fonctionne.

Que faire ensuite

Relisez l'annonce d'emploi réelle et notez chaque framework, outil et pattern qu'elle nomme — React versus Vue, TypeScript, une bibliothèque d'état spécifique, SSR versus CSR, un design system. Les recruteurs posent des questions sur ce qui est sur la page devant eux. Choisissez deux ou trois de vos propres projets passés et répétez, à voix haute, les compromis spécifiques que vous avez faits dans chacun — non pas ce que le projet faisait, mais pourquoi vous avez choisi une approche plutôt que l'alternative que vous n'avez pas prise. Entraînez-vous à expliquer une vraie session de débogage en détail, en nommant l'outil que vous avez utilisé. Si les questions de mise en page CSS vous rendent nerveux, passez une heure à construire une mise en page avec Grid et Flexbox à partir de rien, sans framework, jusqu'à ce que vous puissiez expliquer le choix sans vérifier quoi que ce soit.

jobmarket.pro lit l'annonce pour vous, la met en correspondance avec votre historique de projet réel, et prépare la candidature à partir de cela — donc ce qui passe devant le recruteur s'aligne déjà avec ce que vous pouvez défendre quand il vous met à l'épreuve.