Parlez-Moi de Vous : Comment Répondre en Entretien Tech

La recruteuse a souri, posé son stylo, et dit : “Alors, parlez-moi de vous.”

Et moi — un ingénieur a priori compétent qui avait passé deux semaines à réviser des algos et du system design — j’ai paniqué. Pas la panique où tu te figes. L’autre. Celle où ta bouche démarre avant ton cerveau.

J’ai parlé de ma licence. Puis de mon premier stage. Puis du framework que j’avais utilisé pendant ce stage. Puis d’un side project de 2019 qui n’avait strictement rien à voir avec le poste. Puis je suis revenu sur ma licence, allez savoir pourquoi. J’ai mentionné un hackathon. Je crois que j’ai parlé de mes hobbies à un moment.

Cinq minutes. J’ai divagué pendant cinq minutes. Le sourire de la recruteuse s’est progressivement transformé en cette expression polie mais lointaine — tu sais, celle qu’on a quand quelqu’un te raconte une histoire qui va nulle part.

Quand je me suis enfin arrêté — pas parce que j’avais fini, mais parce que j’avais plus rien à dire — elle a hoché la tête et elle est passée à la suite. Le reste de l’entretien s’est bien passé. J’ai pas eu le poste. Et je suis quasi certain que ces cinq premières minutes en sont la raison.

Le truc, c’est que “parlez-moi de vous” c’est pas une question difficile. C’est la question la plus facile de l’entretien. Et c’est justement le problème. Personne ne la prépare parce qu’elle a l’air simple. Et puis le moment venu, tu réalises que t’as jamais vraiment réfléchi à quoi répondre.

Depuis, j’ai été de l’autre côté. J’ai fait passer une quarantaine, peut-être cinquantaine d’entretiens. Et la façon dont quelqu’un répond à cette question m’en dit beaucoup — pas sur son CV, mais sur sa capacité à communiquer clairement sous un minimum de pression. Ce qui, pour un ingénieur logiciel, c’est à peu près le quotidien.

Alors voilà ce que j’aurais aimé savoir.

Le framework : Présent, Passé, Futur

Quatre-vingt-dix secondes. C’est tout ce qu’il te faut. Peut-être deux minutes si l’histoire coule naturellement, mais vise quatre-vingt-dix secondes.

Trois parties. Trente secondes chacune.

Présent — ce que tu fais en ce moment. Ton rôle actuel, le type de problèmes sur lesquels tu bosses, les technos que tu utilises au quotidien. Pas ton titre. Ce que tu fais concrètement.

Passé — les moments pertinents qui t’ont mené là. Deux ou trois phrases. Pas ta biographie. Les éléments qui font le lien avec le poste visé.

Futur — pourquoi tu es assis dans cet entretien. Ce qui t’excite dans cette boîte, cette équipe, cette problématique. C’est la partie que la plupart des gens zappent, et c’est celle dont les recruteurs se souviennent le plus.

Voilà. Présent, passé, futur. Trente secondes chaque. Tu parles environ quatre-vingt-dix secondes, le recruteur a une image claire de qui tu es, et la conversation peut passer aux choses sérieuses.

Je sais que ça a l’air trop simple. J’ai pensé pareil la première fois qu’on me l’a dit. Mais simple, c’est le but. Le recruteur ne cherche pas un monologue. Il cherche un signal : est-ce que cette personne sait organiser ses idées et communiquer de façon concise ?

Ce qu’il ne faut PAS faire (j’ai tout vu)

Ne raconte pas ta vie. Un candidat a commencé par me parler de la ville où il avait grandi. Son intérêt d’enfance pour l’informatique. Le métier de son père. Je n’exagère pas — au bout de trois minutes, je savais toujours pas ce qu’il faisait comme boulot aujourd’hui. La question c’est “parlez-moi de vous”, pas “racontez-moi absolument tout sur vous.”

Ne lis pas ton CV à voix haute. Je l’ai, ton CV. Je l’ai lu. Si tu te contentes de le dérouler chronologiquement — “alors j’ai été diplômé en 2019, puis j’ai rejoint l’entreprise X, puis je suis passé chez Y, puis j’ai fait Z” — on perd notre temps tous les deux. La timeline, je la connais déjà. Dis-moi un truc que le CV ne peut pas me dire.

Ne sois pas générique. “Je suis un développeur passionné qui aime résoudre des problèmes et travailler en équipe.” Ça décrit littéralement tous les candidats que je vois aujourd’hui. Concrètement, tu travailles sur quoi ? Quels types de problèmes ? Qu’est-ce qui te distingue des quatre autres personnes à qui je parle cette semaine ?

Ne t’excuse pas et ne te sous-vends pas. “Je suis juste un junior, donc j’ai pas beaucoup d’expérience, mais…” Stop. T’es là parce que t’as été retenu. Assume. Parle de ce que t’as construit, de ce que t’as appris, de ce en quoi t’es bon. La confiance, c’est pas de l’arrogance. C’est de la clarté.

Trois exemples qui fonctionnent

Ce ne sont pas des scripts à apprendre par coeur. Ce sont des structures. Adapte-les à ton histoire.

Profil junior (0-2 ans)

“En ce moment, je suis développeur frontend dans une startup fintech qui s’appelle PayFlow, où je travaille sur le dashboard client — principalement React et TypeScript. J’ai rejoint l’équipe il y a environ un an, c’est mon premier poste après mon diplôme, et pendant cette période j’ai pris en charge la migration de nos composants legacy jQuery vers React, ce qui a réduit la taille de notre bundle de 40%.

Avant ça, j’ai fait un stage de six mois dans une agence digitale où j’ai touché à plein de stacks différentes — Vue, Angular, un peu de backend Node — ce qui m’a appris à monter en compétence vite sur de nouveaux outils.

Ce qui m’intéresse dans ce poste, c’est que vous construisez un design system from scratch, et c’est exactement le type de travail frontend fondamental dans lequel je veux approfondir.”

Pourquoi ça marche : des chiffres précis, des projets concrets, une raison claire d’être là. Pas de remplissage. Environ quatre-vingts secondes.

Profil confirmé (3-5 ans)

“Je suis actuellement ingénieur backend chez DataStream, où je travaille sur notre pipeline de traitement d’événements — on traite environ deux millions d’événements par jour avec Kafka et Go. Mon focus principal cette dernière année a été la fiabilité. J’ai mené un projet de refonte de notre stratégie de retry et dead-letter queue, ce qui a fait passer notre taux d’échec de traitement de 2,3% à moins de 0,1%.

Avant DataStream, j’ai passé deux ans dans un cabinet de conseil, ce qui m’a donné un crash course sur le travail dans des codebases très différentes et la capacité à livrer vite. Mais je voulais aller en profondeur sur les systèmes distribués plutôt que de sauter de projet en projet.

Ce qui m’attire dans ce poste, c’est l’échelle à laquelle vous opérez. Cinquante millions d’utilisateurs actifs quotidiens, c’est un tout autre type de problème, et je veux bosser sur des systèmes où les décisions de fiabilité ont ce genre d’impact.”

Pourquoi ça marche : montre de l’ownership, quantifie l’impact, explique la progression de carrière de façon logique, fait le lien direct avec le poste visé.

Profil senior (6+ ans)

“Je suis senior backend engineer chez CloudBase, où je lead une équipe de cinq personnes qui travaille sur notre API gateway. On gère environ 800 millions de requêtes par jour, et mon focus a été la performance et les coûts — sur l’année écoulée, j’ai porté un changement d’architecture qui a réduit nos coûts compute de 35% tout en améliorant la latence au p99.

Mon parcours mélange plateforme et produit. J’ai passé trois ans dans une boîte B2B SaaS où je suis passé d’IC à tech lead, et avant ça j’étais en agence, ce qui m’a donné cette habitude de penser aux décisions techniques en termes d’impact business, pas juste d’élégance technique.

Je vous contacte parce que je suis votre blog engineering depuis un moment, et le travail que vous faites sur l’edge computing correspond à la direction que je veux donner à ma carrière. L’aspect leadership technique de ce poste m’intéresse particulièrement.”

Pourquoi ça marche : démontre l’échelle, le leadership, la conscience business et un intérêt sincère. Le recruteur comprend immédiatement que cette personne a fait ses devoirs.

Adapter ta réponse selon le type d’entreprise

Le framework reste le même. C’est l’accent qui change.

Startups — ils veulent entendre que tu sais être polyvalent et aller vite. Mets en avant la largeur de tes compétences, la vitesse de livraison, ton aisance avec l’ambiguïté. “J’ai construit le MVP en trois semaines” a plus de poids que “j’ai optimisé un système qui sert des millions d’utilisateurs.” Ils veulent savoir que tu vas survivre au chaos.

Big tech — ils veulent de la profondeur et de l’échelle. Quantifie. Millions d’utilisateurs, latences au percentile, projets cross-team. Ils ont une grille de niveaux, et ta réponse doit leur faciliter le placement. Utilise leur vocabulaire. Impact. Scope. Complexité.

Entreprise / grands groupes — ils valorisent la stabilité, la collaboration et le process. Mentionne le travail transversal, la gestion de parties prenantes, le fait de travailler dans un cadre contraint. “J’ai travaillé avec l’équipe compliance pour refondre notre pipeline de données” envoie un signal différent de “j’ai shippé une feature en un weekend.”

Rien de tout ça ne veut dire mentir. Ça veut dire savoir quelle facette de ton expérience réelle mettre en avant. T’es le même ingénieur. Tu ajustes juste l’objectif.

Comment s’entraîner concrètement

Je vais être direct : connaître le framework, ça suffit pas. Il faut que tu t’entraînes à le dire à voix haute. Avec ta bouche. Je précise parce que je connais beaucoup d’ingénieurs qui “s’entraînent” en lisant leur réponse dans leur tête en se disant “ouais, ça sonne bien.” Ça compte pas.

Enregistre-toi. Téléphone, laptop, peu importe. Dis ta réponse. Réécoute. La première fois que tu fais ça, tu vas détester. Tout le monde déteste. Fais-le quand même. Tu vas remarquer les mots de remplissage, les pauses bizarres, les phrases qui vont nulle part. Corrige. Réenregistre.

Chronomètre. Mets un timer de 90 secondes. Si tu parles encore quand il sonne, coupe quelque chose. Le but c’est pas de faire rentrer plus d’informations. C’est de dire moins, mieux.

Dis-le à un humain. Un ami, un mentor, un collègue ingénieur qui cherche aussi. Donne-lui le poste que tu vises et demande : “Après avoir entendu mon intro, est-ce que tu sais ce que je fais, pourquoi je suis bon, et pourquoi je veux ce poste ?” Si la réponse à l’une de ces questions est non, itère.

Prépare deux ou trois variantes. Une pour les startups, une pour les grosses boîtes, une par défaut. Le fond reste le même. L’accent change. Avoir des variantes prêtes, ça t’évitera de bloquer quand l’entreprise ne correspond pas à ce que tu attendais.

Moi, je m’entraînais dans la voiture. Je parlais au pare-brise, comme une personne normale. Il m’a fallu quatre ou cinq itérations avant que ça sonne naturel. Après ça, c’était automatique. Chaque entretien commençait bien, ce qui rendait tout le reste plus facile.

Questions fréquentes

Et si le recruteur dit “parcourez-moi votre CV” à la place ? Même framework, un poil plus chronologique. Pars du premier point pertinent et avance, mais reste concis. Toujours quatre-vingt-dix secondes à deux minutes. Termine toujours par pourquoi tu es là.

Est-ce que je devrais mentionner mes projets perso ou l’open source ? Seulement s’ils sont pertinents pour le poste et suffisamment marquants pour mériter du temps d’antenne. “Je maintiens une lib avec 2 000 stars sur GitHub” — oui. “J’ai une appli de to-do sur GitHub” — probablement pas dans tes 90 secondes.

Comment faire si je suis en reconversion ? Commence par les compétences transférables et le “pourquoi.” “J’ai passé cinq ans en tant qu’ingénieur mécanique, ce qui m’a donné des bases solides en résolution de problèmes. Sur la dernière année, j’ai construit des projets full-stack et j’ai suivi un bootcamp React et Node. Je fais cette transition parce que…” La partie Passé devient ton pont.

Comment gérer un trou dans le parcours ? Brièvement et honnêtement. “J’ai pris une année pour gérer une situation familiale et j’en ai profité pour approfondir mes compétences en architecture cloud.” Puis passe à la suite. N’en fais pas des tonnes. Ne t’excuse pas. Les trous, c’est normal.

Cette question arrive en premier dans quasiment chaque entretien. Réussis-la, et tu donnes le ton pour tout ce qui suit. Rate-la, et tu passes le reste de l’heure à remonter la pente.

Si c’est pas encore fait, jette un oeil au guide complet de préparation aux entretiens techniques pour avoir la vue d’ensemble. Et si c’est les rounds comportementaux qui te posent problème, le guide sur la méthode STAR détaille exactement comment structurer ces réponses.

T’as fini de lire ? Rejoins la communauté en accès anticipé →