GitLab — Préparer l’entretien Frontend Engineer

Ce dossier concerne Frontend Engineer dans Engineering/Development : développement du produit. Il ne décrit ni le poste Frontend Engineer de Product/UX, ni l’équipe du site marketing. La page rassemble plusieurs niveaux ; votre offre détermine le niveau attendu et le pays autorisé. Aucun stage ou CDI français actuellement ouvert n’est attesté ici.

La séance vous fait produire une petite fonction testée, une décision d’interface argumentée et une note de revue. Travaillez dans votre langage habituel pour le raisonnement, puis expliquez le comportement en JavaScript. Un exemple modeste, compris et vérifié, permet de discuter précisément vos choix. Tous les exercices sont créés par Avanttoi ; aucune banque de questions d’entretien n’est reprise.

Source f1 annonce un court exercice écrit, un appel recrutement de 30 minutes, un entretien technique de 90 minutes, un entretien comportemental de 45 minutes et un entretien direction Engineering de 60 minutes, puis une éventuelle offre. La page ne décrit pas l’énoncé technique : le cas de ce dossier n’en est pas une reconstitution.

Les exigences communes comprennent framework JavaScript moderne, tests automatisés, Git, HTML sémantique, CSS, JavaScript, concepts navigateur, diagnostic de performance et communication en anglais dans un environnement distant. Le travail avec produit, design et backend est documenté. La dernière modification affichée est le 12 mars 2026 ; publication initiale inconnue. Pays, contrat, équipe exacte et modalités de votre candidature restent à confirmer. Les exigences propres aux niveaux supérieurs ne sont pas imposées ici à tous les candidats.

Première preuve : un état d’interface explicite. Distinguez chargement, résultat vide, erreur et données présentes. Une page qui affiche « aucun résultat » pendant une requête donne une fausse information, même si la fonction de filtrage est correcte.

Deuxième preuve : un test qui protège un comportement. Énoncez entrée, sortie attendue et risque évité avant d’écrire l’assertion. Couvrir dix fois le même chemin n’apporte pas dix protections différentes.

Troisième preuve : un arbitrage lisible. Expliquez ce que vous changez maintenant, ce que vous mesurez et le signal qui justifierait une solution plus complexe. Ces preuves sont une méthode de préparation Avanttoi, pas des critères internes GitLab. Pour votre expérience, séparez vos décisions de celles du collectif et ne fabriquez aucun gain de performance.

Énoncé original — 30 minutes. Une petite interface fictive affiche quatre demandes : (1, open, API), (2, closed, API), (3, open, API docs), (4, open, UI). Chaque triplet contient identifiant numérique unique, état et titre. Les données sont déjà validées ; aucun identifiant dupliqué, titre nul ou état inattendu. Implémentez une recherche insensible à la casse, avec espaces extérieurs ignorés, filtre d’état optionnel « all », ordre décroissant d’identifiant et limite entière positive. Le tableau d’origine doit conserver son ordre. Les titres ne contiennent pas de règles d’accentuation particulières dans cet exercice.

Avant de coder, écrivez les résultats attendus : recherche « API », état open, limite 10 → [3, 1] ; même recherche, limite 1 → [3] ; recherche vide, état all → [4, 3, 2, 1]. Un terme absent donne []. Ce contrat évite de découvrir les règles au fil du code.

Corrigé JavaScript original :

function select(rows, query, status = 'all', limit = 10) {
  const q = query.trim().toLowerCase();
  return rows
    .filter(row => (status === 'all' || row.status === status)
      && row.title.toLowerCase().includes(q))
    .sort((a, b) => b.id - a.id)
    .slice(0, limit);
}

Le filtrage produit un nouveau tableau ; son tri ne réordonne donc pas rows. Les objets sont partagés, mais cette fonction ne modifie aucun de leurs champs. Vérifiez aussi « api », l’état closed et l’absence de mutation sur un tableau gelé. En supposant des titres de longueur bornée et un tri comparatif en O(k log k), le coût est O(n + k log k), où k compte les lignes retenues avant la limite. La limite n’évite pas le tri de ces k lignes. Aucun résultat de performance sur une application réelle n’est prétendu.

Pour l’interface, distinguez zéro correspondance d’un échec réseau et rendez les titres comme du texte. Le cas ne couvre ni pagination serveur, ni annulation de requêtes, ni contrôle d’accès : les ajouter sans besoin compliquerait la réponse.

Barème Avanttoi sur 10 : contrat et résultats attendus, 2 ; filtres, 2 ; ordre et limite, 2 ; absence de mutation, 2 ; limites et états d’interface expliqués, 2. Le code et les cas limites annoncés ont été exécutés avec des assertions ; aucun test interne GitLab n’est utilisé.

Préparez une décision réelle en deux versions : explication de 90 secondes pour un partenaire produit, puis discussion technique de cinq minutes. Donnez le besoin, les options envisagées, le compromis retenu et le résultat effectivement observé. L’absence de métrique chiffrée se dit ; elle ne se remplace pas par un pourcentage plausible.

Questions à poser : quels comportements doivent être protégés avant livraison ? Comment frontend, backend et design clarifient-ils une ambiguïté ? Quel exemple représente une petite itération réussie dans cette équipe ? Confirmez le niveau, le domaine produit, les outils autorisés et le format actuel de l’évaluation. Les réponses peuvent différer entre équipes ; ce dossier n’en suppose aucune.

Demain — 110 minutes. Relisez offre et invitation pendant 15 minutes. Faites le cas sans consulter le corrigé pendant 30 minutes, puis vérifiez-le pendant 15. Travaillez les exercices 1, 3 et 7 pendant 20 minutes. Répétez une décision réelle en anglais pendant 15 minutes. Gardez 15 minutes pour votre environnement, les consignes et deux questions au recruteur.

Cinq jours — 60 minutes par jour. Jour 1 : exercices 1 et 2, états et interactions. Jour 2 : 3 et 4, tests et comportement asynchrone. Jour 3 : cas puis exercice 5, mesure. Jour 4 : 6 à 8, revue et contrat. Jour 5 : 9 et 10, simulation orale et correction de votre point faible. Rejouez un test raté avant d’ajouter une nouvelle technologie.

Checklist : résultats attendus écrits ; exemple exécuté ; clavier essayé ; erreur et état vide distingués ; aucune valeur d’accès dans le projet partagé ; limites connues ; invitation actuelle vérifiée. Pendant une évaluation, suivez les règles d’aide extérieure annoncées. Votre préparation doit améliorer votre autonomie.

Source f1 GitLab Handbook — Frontend Engineer Roles (Engineering/Development) — https://handbook.gitlab.com/job-description-library/engineering/development/frontend/ Consultation : 7 septembre 2026. Dernière modification affichée : 2026-03-12. Publication initiale : inconnue. Métier : Frontend Engineer — Engineering/Development. Pays : selon l’offre. Ce document permet d’établir : compétences communes, collaboration, ordre et durées du recrutement ; pas de détail du test ni de poste France attesté

Sources institutionnelles gratuites : GitLab — GitLab Handbook. Repères sélectionnés, traduits et contextualisés ; exercices, cas et plans originaux : Équipe Avanttoi — Dossier de préparation édité par Marius et Hippolyte. L’ensemble du texte du dossier est proposé sous CC BY-SA 4.0 (https://creativecommons.org/licenses/by-sa/4.0/), avec attribution, indication des modifications et partage dans les mêmes conditions. Le prix rémunère cette préparation structurée ; il ne vend aucune exclusivité sur les informations. Vous pouvez partager et adapter le texte selon la licence, y compris commercialement. Aucun partenariat ni validation de GitLab. Aucun logo, portrait, vidéo, document réservé ou élément tiers n’est reproduit. Les marques restent exclues de la licence. Contenu fourni sans garantie, conformément à la section 5 de la licence.

Portée de la licence du Handbook : https://handbook.gitlab.com/handbook/about/handbook-usage/#external-use-of-the-handbook. Texte légal : https://creativecommons.org/licenses/by-sa/4.0/legalcode.fr .

La date de consultation ne transforme pas une page en preuve d’un recrutement ouvert. Aucune date d’entretien individuel n’est connue, aucun témoignage n’est utilisé. Vérifiez l’offre et l’invitation reçue ; leurs modalités peuvent évoluer. Aucun exercice de ce dossier n’est présenté comme une question réellement posée ou un test interne. Les cas sont fictifs et leurs résultats ne constituent ni un indicateur de performance GitLab ni une garantie d’embauche.