Le test technique d'embauche pour développeur junior : à quoi s'attendre
On vous propose un test technique pour un poste de développeur junior. Faut-il réviser des algorithmes, préparer une application ou savoir expliquer votre code à voix haute ? La première chose à obtenir est le format exact. Le mot « test » ne suffit pas à définir le travail demandé.
Voici une méthode de préparation, notamment si vous arrivez du monde de la reconversion en France : clarifier la consigne, livrer une petite solution vérifiable et savoir discuter de ses limites. L'exercice JavaScript plus bas est créé pour cet article. Ce n'est ni un sujet récupéré chez un employeur ni une simulation validée d'un recrutement.
Avant de réviser, faire préciser le rendez-vous
Ces formats sont des possibilités à distinguer, pas une statistique sur les entreprises françaises. Demandez lequel vous attend avant de choisir vos révisions.
- Exercice chronométré sur une plateforme : vous répondez à des questions ou écrivez du code dans un environnement imposé. Faites préciser le langage, la possibilité d'exécuter les tests et les conditions de surveillance.
- Code en direct : vous travaillez avec une personne qui voit votre écran ou un éditeur partagé. Entraînez-vous à annoncer une hypothèse, puis à la vérifier, sans commenter chaque frappe.
- Travail à rendre chez vous : vous recevez une consigne et une échéance. Demandez aussi le temps de travail attendu : une date de remise ne fixe pas un budget d'heures.
- Discussion ou revue de code : on vous demande d'expliquer un projet, de trouver un défaut ou de proposer une modification. Préparez un exemple de décision et un exemple de bug que vous comprenez réellement.
Un exemple précis vaut mieux qu'une règle inventée sur « les recruteurs ». Dans ses conseils pour les entretiens techniques, consultés le 23 octobre 2026, Microsoft recommande de clarifier les ambiguïtés et de tester sa solution. C'est la procédure décrite par cet employeur, pas un barème universel pour les juniors en France.
Le message à envoyer avant de commencer
Vous pouvez reprendre ces questions dans votre échange avec la personne qui organise le test. Elles servent à cadrer le travail, sans chercher à deviner les réponses attendues.
Quel est le format du test et combien de temps de travail faut-il prévoir ? Quels langages et outils puis-je utiliser ? La documentation, les recherches sur Internet et les assistants IA sont-ils autorisés, et sous quelles conditions ? Quel rendu attendez-vous : fichier, dépôt, démonstration ou application déployée ? Quels critères seront évalués et y aura-t-il un échange sur ma solution ?
Si un travail à domicile paraît trop large pour votre disponibilité, proposez de borner le périmètre : « Je peux consacrer deux heures à cette partie et documenter la suite. Est-ce compatible avec vos attentes ? » Les deux heures sont ici un exemple de limite à négocier, pas une durée normale du marché.
Pour l'IA, obtenez une règle explicite. Si elle est interdite, préparez-vous sans elle. Si elle est autorisée, demandez si vous devez conserver les échanges ou déclarer son usage. Dans les deux cas, entraînez-vous à modifier et justifier la solution que vous rendez. Notre banc de relecture du code produit par une IA donne des exemples de défauts à rechercher.
Un exercice maison : trier les tâches encore ouvertes
Imaginez une liste de tâches d'équipe. Écrivez une fonction tachesOuvertes(taches) qui renvoie les identifiants des tâches non terminées, par priorité décroissante. À priorité égale, l'identifiant le plus petit passe en premier. Le tableau d'entrée et ses objets doivent rester inchangés.
Le contrat de cet exercice est volontairement limité : l'entrée est un tableau dense d'objets valides, chaque id est un entier positif distinct, chaque priorite est un entier de 1 à 3 et chaque terminee est un booléen. Un tableau vide est accepté. Il n'y a ni interface, ni serveur, ni validation de données à construire.
Avant de regarder la correction, écrivez vos cas de test : aucune tâche, toutes terminées, une seule ouverte, priorités différentes, égalité de priorité. Ajoutez une vérification que l'entrée ne change pas. Vous aurez ainsi une définition concrète de « terminé ».
Une correction courte, puis des preuves
Enregistrez ce premier bloc dans solution.mjs. Le suffixe .mjs permet ici d'utiliser les modules JavaScript de Node.
export function tachesOuvertes(taches) {
return taches
.filter((tache) => !tache.terminee)
.sort((a, b) => b.priorite - a.priorite || a.id - b.id)
.map((tache) => tache.id);
}filter crée un nouveau tableau : le tri porte donc sur ce tableau intermédiaire. Il s'agit d'une copie superficielle, comme le précise la documentation de filter sur MDN, consultée le 23 octobre 2026 : les objets restent partagés. Notre fonction ne modifie aucune de leurs propriétés.
b.priorite - a.priorite place la priorité la plus élevée en premier. Si la différence vaut zéro, || utilise a.id - b.id pour départager. Attention à déplacer le tri en début de chaîne : sort modifie le tableau sur lequel il est appelé, selon MDN consulté le 23 octobre 2026.
Enregistrez ce second bloc dans test.mjs, à côté du premier. Les assertions comparent le résultat à une attente fixée à la main. Une assertion fausse interrompt le programme.
import assert from "node:assert/strict";
import { tachesOuvertes } from "./solution.mjs";
const cas = [
["vide", [], []],
["toutes terminées", [
{ id: 1, priorite: 3, terminee: true }
], []],
["une ouverte", [
{ id: 7, priorite: 1, terminee: false }
], [7]],
["priorités et égalité", [
{ id: 8, priorite: 1, terminee: false },
{ id: 4, priorite: 3, terminee: false },
{ id: 2, priorite: 3, terminee: false },
{ id: 1, priorite: 3, terminee: true }
], [2, 4, 8]]
];
for (const [nom, entree, attendu] of cas) {
const avant = structuredClone(entree);
entree.forEach(Object.freeze);
Object.freeze(entree);
const resultat = tachesOuvertes(entree);
assert.deepEqual(resultat, attendu);
assert.deepEqual(entree, avant);
console.log(`${nom} : ${JSON.stringify(resultat)}`);
}
console.log("4 cas validés ; entrées inchangées");Lancez node test.mjs. Exécution réalisée le 23 octobre 2026 avec Node v22.23.3, sans dépendance externe. Voici la sortie standard exacte, avec un saut de ligne final :
vide : []
toutes terminées : []
une ouverte : [7]
priorités et égalité : [2,4,8]
4 cas validés ; entrées inchangéesLes quatre cas passent, y compris avec les tableaux et les objets gelés. Cette preuve concerne ces données et ce contrat. Elle ne démontre ni une performance sur de gros volumes, ni le traitement d'une entrée invalide, ni votre niveau global de développeur. Essayez ensuite de retirer le départage par identifiant : le dernier cas doit échouer.
Ce que vous pouvez expliquer pendant la restitution
Commencez par le comportement : « Je filtre les tâches ouvertes, je trie le résultat, puis je garde les identifiants. » Montrez ensuite le test d'égalité de priorité et celui qui protège l'entrée. Cette présentation rattache chaque choix à une exigence au lieu de réciter le nom des méthodes.
Si on vous demande de gérer une priorité absente, signalez que le contrat initial supposait des objets valides. Demandez quelle règle appliquer : rejeter l'entrée, ignorer la tâche ou fixer une valeur par défaut. Ce sont des comportements différents ; en choisir un sans le dire crée une ambiguïté.
Si vous bloquez pendant un exercice en direct, dites ce qui vous manque : comprendre une consigne, retrouver une méthode ou corriger une erreur précise. Proposez un petit cas concret et déroulez-le à la main. Pour cet exercice, deux tâches de même priorité suffisent à examiner le départage.
Pour un rendu à domicile, joignez une commande d'exécution, la version de l'outil, les hypothèses et les limites connues. Vérifiez aussi que le dépôt est accessible selon la consigne. Si cette partie vous est nouvelle, notre guide des commandes Git et GitHub pour débuter permet de revoir le cycle de livraison.
Préparer une séance utile, sans deviner tout le métier
Reprenez d'abord les technologies et les missions annoncées pour le poste. Choisissez un petit exercice qui les fait travailler, exécutez-le et expliquez-le à voix haute. Pour un poste orienté interface, une fonction de tri seule ne prépare pas aux questions sur le HTML, le CSS ou les interactions dans le navigateur.
Gardez un moment pour relire la consigne et relancer votre solution depuis un dossier propre. Si tout n'est pas fini, distinguez ce qui fonctionne, ce qui échoue et ce que vous feriez ensuite. Un test incomplet reste incomplet ; le décrire précisément rend au moins votre travail vérifiable.
Le but de cette préparation n'est pas de garantir une embauche. C'est d'arriver avec une méthode que vous savez appliquer : clarifier, coder une réponse bornée, vérifier, puis expliquer vos choix.