Un candidat mid-level, en entretien à distance, répond à « Quelle est la différence entre switchMap et mergeMap ? » par une définition parfaite, après une pause de trois secondes. Deux questions plus tard, vous lui demandez lequel il utiliserait dans une barre de recherche, et pourquoi. Silence. La première question a mesuré sa vitesse à consulter un assistant IA ; la seconde a mesuré ce que vous aviez réellement besoin de savoir.
J'ai été des deux côtés de la table d'entretien, et une question me revient de plus en plus souvent : aujourd'hui, avec un assistant IA dans chaque éditeur, les questions d'entretien classiques ont-elles encore un sens ?
Ce qui a vraiment changé
Les questions « de manuel » — définitions, différences entre deux concepts, listes de caractéristiques — ont toujours été une approximation : on supposait que celui qui connaît la théorie sait aussi l'appliquer. C'était une approximation acceptable quand se souvenir demandait un effort. Aujourd'hui, se souvenir ne coûte rien : n'importe quelle définition est à un prompt près, pendant l'entretien et surtout après, dans le vrai travail.
Et c'est précisément là le point : le développeur que vous recrutez travaillera avec l'IA. Ce qui compte n'est plus ce qu'il sait par cœur, mais trois choses que l'IA ne fait pas à sa place :
- Jugement : choisir entre deux solutions correctes selon le contexte.
- Vérification : remarquer quand le code généré est faux, même s'il compile.
- Contexte : comprendre le vrai problème avant d'écrire la moindre ligne.
Mid et senior : les questions classiques ne suffisent plus
Pour un profil mid ou senior, les questions théoriques isolées sont presque inutiles : un bon candidat les réussit, mais un candidat médiocre avec un second écran aussi. Il ne faut pas les supprimer complètement — il faut s'en servir comme point de départ pour creuser. Voici cinq formats qui fonctionnent.
1. Revue de code généré par l'IA
Donnez au candidat un extrait plausible, comme ceux qu'un assistant produit tous les jours, et demandez-lui de le relire comme la pull request d'un collègue :
// Product search bar
this.results$ = this.query$.pipe(
debounceTime(300),
mergeMap(q => this.api.search(q))
);Le code fonctionne presque toujours. Un senior doit remarquer qu'avec mergeMap, une réponse lente pour « ang » peut arriver après celle pour « angular » et écraser les bons résultats : il faut switchMap, qui annule la requête précédente. Points bonus s'il demande ce qui se passe avec une chaîne vide ou une erreur HTTP, qui ici fermerait le stream pour de bon.
Le même exercice fonctionne côté backend :
async function getOrders(userIds) {
const result = [];
for (const id of userIds) {
result.push(await db.orders.find({ userId: id }));
}
return result;
}Ici, on cherche les N requêtes séquentielles, l'absence de pagination et la proposition d'une requête unique avec $in. Aucune définition à réciter : soit on voit le problème, soit on ne le voit pas.
2. Des scénarios plutôt que des définitions
Au lieu de « Qu'est-ce que la change detection ? », demandez : « Un tableau de 5 000 lignes devient lent quand l'utilisateur tape dans le filtre. Voici le profiler : par où commencez-vous ? ». Au lieu de « Qu'est-ce que Redis ? » : « Nous avons un cache en mémoire et passons d'une à trois instances du backend. Qu'est-ce qui casse ? ». Les réponses montrent tout de suite si le candidat a résolu des problèmes similaires ou s'il en a seulement entendu parler.
3. Le récit d'un vrai problème
« Racontez-moi le bug le plus difficile que vous avez résolu en production » reste l'une des meilleures questions, à condition de creuser avec des relances : comment l'avez-vous remarqué ? Quelle hypothèse avez-vous écartée en premier ? Qu'avez-vous changé pour que cela ne se reproduise plus ? Une expérience vécue tient cinq niveaux de « pourquoi » ; une histoire préparée s'effondre au deuxième.
4. Pair programming avec l'IA autorisée
Au lieu d'interdire les outils, autorisez-les et observez comment ils sont utilisés. Une tâche de 30 à 40 minutes sur un petit dépôt réel, avec l'assistant IA activé. Vous n'évaluez pas le résultat mais le processus : le candidat lit-il le code avant de demander ? Ses prompts sont-ils précis ou vagues ? Rejette-t-il une suggestion erronée, ou l'accepte-t-il parce qu'elle compile ? Ajoute-t-il un test ?
5. Compromis et décisions
Chez un senior, ce qui compte, c'est la capacité à décider sous contraintes : « Nous avons deux semaines et une équipe de trois personnes : on réécrit le module ou on le sécurise avec des tests ? ». Il n'y a pas de bonne réponse : il y a un raisonnement qui pèse le risque, le coût et la réversibilité, et c'est exactement ce que vous voulez entendre.
Junior : comment l'entretien devrait se dérouler
Avec les juniors, le problème est inverse. Ils n'ont pas d'expérience à raconter, et une revue de code complexe les pénaliserait injustement. Mais c'est justement pour eux que le risque lié à l'IA est le plus élevé : il est facile de produire du code qui fonctionne sans le comprendre. L'entretien doit donc mesurer la compréhension et la capacité d'apprentissage, pas la quantité de connaissances.
Un déroulé de 60 minutes que j'utilise et recommande :
| Durée | Activité | Ce qui est évalué |
|---|---|---|
| 10 min | Un projet personnel ou universitaire : ce que vous avez fait vous-même, ce que vous feriez autrement | Lucidité, honnêteté |
| 15 min | Lire un court extrait de code et prédire sa sortie, ligne par ligne | Fondamentaux réels |
| 20 min | Petite tâche avec IA autorisée, puis questions sur chaque ligne écrite | Compréhension, vérification |
| 10 min | La documentation d'une API jamais vue : l'utiliser pour un cas simple | Capacité d'apprendre |
| 5 min | Questions du candidat | Curiosité, intérêt |
Un exemple d'exercice de lecture, idéal pour un junior JavaScript :
for (var i = 0; i < 3; i++) {
setTimeout(() => console.log(i), 0);
}
// Qu'affiche ce code ? Et avec let à la place de var ?Peu importe que le junior connaisse la réponse par cœur (3 3 3, puis 0 1 2) : ce qui compte, c'est qu'avec un peu d'aide, il parvienne à expliquer pourquoi — la portée de la variable et l'exécution asynchrone. C'est une question classique, mais utilisée pour faire raisonner, pas pour vérifier un souvenir.
Dans la partie avec l'IA, la question clé vient après le code : « Que se passe-t-il si le tableau est vide ? Et si on reçoit null ? ». Un junior qui a compris raisonne, même s'il se trompe ; celui qui a seulement collé la réponse ne sait pas par où commencer. Dans les deux cas, vous obtenez une information précieuse.
Question classique → version actualisée
| Question classique | Version actualisée |
|---|---|
| Qu'est-ce qu'une closure ? | Ce code a une fuite mémoire : où, et pourquoi ? |
| Différence entre SQL et NoSQL ? | Pour ce cas d'usage, lequel choisissez-vous et que perdez-vous ? |
| Quels sont les principes SOLID ? | Cette classe est difficile à tester : comment la restructurez-vous ? |
| Qu'est-ce que le lazy loading ? | Le bundle initial pèse 4 Mo : que vérifiez-vous en premier ? |
| Comment fonctionne un JWT ? | Un token volé reste valide 30 jours : que changez-vous ? |
Ce qu'il faut supprimer (ou presque)
- Les définitions apprises par cœur comme seule épreuve : elles mesurent la recherche, pas la compétence.
- Les exercices à la maison de 8 heures : une IA les termine en une demi-heure, et ils pénalisent ceux qui ont moins de temps libre.
- Le live coding sans internet ni outils : il évalue une situation qui n'existe pas dans le vrai travail.
- Interdire l'IA en entretien et l'exiger dès le premier jour : c'est incohérent, et les meilleurs candidats le remarquent.
En résumé
Les questions classiques ne sont pas mortes, mais seules, elles ne mesurent plus ce qui compte. Pour les mid et senior, il faut des revues de code, des scénarios réels et des décisions sous contraintes, idéalement avec l'IA sur la table pour voir comment ils la maîtrisent. Pour les juniors, il faut des exercices de lecture de code, des questions sur le « pourquoi » et une épreuve d'apprentissage : non pas ce qu'ils savent déjà, mais à quelle vitesse et avec quelle honnêteté ils apprennent. Dans un monde où le code se génère en quelques secondes, le vrai talent, c'est de savoir quand ce code est faux. Si vous vous préparez de l'autre côté de la table, vous trouverez les questions techniques classées par niveau dans le guide des 25 questions d'entretien frontend/Angular.