Comment l'IA change les entretiens techniques chez les développeurs

Il y a encore deux ou trois ans, décrocher un poste dans une startup tech passait souvent par des sessions intensives de Leetcode aux aurores. Ce temps-là est en train de disparaître.

Les outils d'IA comme Claude et GitHub Copilot font désormais partie du quotidien des développeurs. Ils écrivent du code, posent des questions, testent des solutions. Pourtant, beaucoup d'entreprises continuent d'évaluer les candidats avec des méthodes qui n'ont pas évolué. Le résultat est souvent maladroit.

Les limites des tests actuels

Aujourd'hui, les take-home et les entretiens live ont tendance à autoriser l'utilisation de l'IA. C'est logique sur le papier : si les équipes travaillent avec ces outils, pourquoi ne pas recruter des profils qui savent s'en servir ?

Mais dans la pratique, ça pose problème.

Un dépôt GitHub bien propre ne révèle rien sur la façon dont le candidat a travaillé. Le code est là, mais on ne sait pas ce qui vient de lui et ce qui vient de l'IA. Les entretiens où le candidat partage son écran et « pense à voix haute » semblent mieux, but ils coûtent cher en temps : une heure de senior par candidat. À l'échelle, ça ne tient pas.

Et dans les deux cas, on perd ce qui est le plus important : le journal des échanges entre le développeur et son outil d'IA.

Un nouveau regard sur la façon de penser

Pour évaluer un candidat, on pourrait s'intéresser directement à ces échanges. Au lieu de regarder le résultat final, on pourrait suivre la manière dont le candidat pose des questions, teste des approches, corrige des erreurs, et collabore avec l'IA.

Ce serait l<|eos|>