Comment j'ai réussi l'entretien d'ingénieur logiciel chez Adobe

TL;DR

• J'ai décroché une offre d'ingénieur produit chez Adobe après avoir failli échouer au round où l'on vous demande de raconter un système que vous avez livré.
• Mon process a compté un appel RH, un test technique d'une heure et quatre rounds onsite : coding pratique, deep dive sur un projet passé, design orienté produit, puis le manager recruteur.
• Le niveau de code était plus proche du travail réel que du LeetCode difficile, et la profondeur de mes réponses sur mes propres arbitrages a pesé bien plus lourd que ma vitesse sur les algorithmes.
• Si je refaisais la préparation, je passerais la première semaine à écrire le journal de décisions de trois projets, et seulement la deuxième sur du code.

Introduction

J'ai postulé chez Adobe un mardi soir depuis mon canapé, avec le même CV que j'avais envoyé à onze autres entreprises ce mois-là. Six ans de full-stack dans une scale-up parisienne, principalement sur l'éditeur d'un produit de documents collaboratifs. J'étais au troisième mois d'un plan de préparation très discipliné et très mal orienté : 40 minutes d'algorithmique avant le travail, 90 après, un tableur avec une colonne rouge-orange-vert par famille de problèmes.

J'ai fini avec une offre d'ingénieur produit sur un poste confirmé, et j'ai failli ne jamais l'avoir à cause d'un round qui n'avait rien à voir avec le tableur.

Comment j'ai décroché l'entretien, et pourquoi c'est particulier depuis la France

La candidature en ligne n'a rien produit pendant six semaines. Ce qui a débloqué la situation est d'un ennui total : via une ancienne collègue, j'ai retrouvé une ingénieure qui travaillait sur la surface produit qui m'intéressait. Message court — le périmètre que je visais, une chose que j'avais construite d'adjacent, la question de savoir si une cooptation était raisonnable. Neuf jours plus tard, j'avais un mail d'une recruteuse. J'avais mis 90 % de mon énergie sur « réussir l'entretien » et 10 % sur « l'obtenir » ; le bon ratio est plutôt 70/30, surtout chez un employeur d'environ 30 000 personnes.

Deuxième particularité locale : les quatre personnes que j'ai rencontrées travaillaient depuis trois pays, aucune depuis la France. Le poste était rattaché à une équipe européenne, en hybride depuis Paris. Si vous êtes à Lyon ou à Toulouse, la question à poser au premier appel n'est pas « y a-t-il un bureau près de chez moi » mais « à quelle équipe et à quel fuseau le poste est-il rattaché, et combien de jours sur site ».

L'appel RH, 30 minutes, début avril

Classique, mais pas décoratif. Elle m'a posé deux questions que je n'attendais pas d'une recruteuse :

• « Quel produit utilisez-vous tous les jours sur lequel vous avez un avis tranché à propos d'une décision de conception précise ? »
• « Citez une chose que vous avez construite où vous trancheriez différemment aujourd'hui. »

J'ai bien répondu à la première : j'avais un avis tranché sur la pile d'annulation d'un éditeur de texte. J'ai mal répondu à la seconde, avec un « on aurait dû écrire plus de tests » qui vaut « mon défaut, c'est que je suis perfectionniste ». Je l'ai vue noter quelque chose.

Elle m'a donné la forme du process : test technique, coding, deep dive sur un projet passé, design, manager recruteur. Quatre à six semaines jusqu'à la décision ; le mien en a pris cinq.

Le test technique, une heure, mi-avril

Éditeur partagé, un ingénieur d'une équipe voisine, et le premier signe que je m'entraînais à la mauvaise chose : mes sessions chronométrées sur PhantomCodeAI, la semaine précédente, portaient toutes sur de l'algorithmique classique. Mauvaise répétition générale.

L'archétype : parser un petit format d'entrée structuré, le normaliser en mémoire, répondre à deux ou trois requêtes dessus. Puis l'étendre. Puis gérer des entrées malformées auxquelles je n'avais pas pensé.

Aucune intuition maligne à trouver. Une seule question était testée : est-ce que j'écris du code qu'une autre personne pourra maintenir ? Des noms lisibles, une structure de données choisie pour les requêtes, une gestion d'erreur qui échoue bruyamment au lieu de retourner discrètement une liste vide.

Je suis passé, mais quand il m'a demandé d'étendre le code, ma conception initiale m'a résisté : je l'avais optimisée pour la première exigence au lieu de la forme du problème. Sa relance : « si vous aviez su que ça arrivait, qu'auriez-vous fait autrement au départ ? » Cette question, sous des habits différents, s'est révélée être tout le process.

Le onsite : quatre rounds, en deux blocs

Coupé en deux par un conflit d'agenda : deux rounds un jeudi, les deux derniers le mardi suivant. Ces cinq jours d'écart sont la seule raison pour laquelle j'ai une offre.

Round 1 : coding pratique, 55 minutes

Un problème concret, cadré côté produit. L'archétype : à partir d'un flux d'actions utilisateur, maintenir une vue dérivée qui répond à une question précise sans tout recalculer, puis supporter l'annulation des N dernières actions.

C'est l'annulation qui devient intéressante. Ma première conception recalculait tout depuis le début : correct et lent. L'interviewer m'a laissé finir, puis a demandé ce qui se passe quand N est grand et le journal long. J'ai comparé à voix haute une opération inverse par type d'action et un snapshot toutes les K actions, choisi les snapshots plus rejeu parce qu'un inverse était ambigu, et dit explicitement que j'échangeais de la mémoire contre de la simplicité. Il avait l'air plus satisfait du raisonnement que du code : c'est tout l'objet du round.

Round 2 : le deep dive sur un projet passé, 50 minutes — le round que j'ai raté

C'est là que je me suis effondré. La consigne : « choisissez quelque chose que vous avez construit ces deux dernières années et racontez-le moi ». J'ai pris la sauvegarde automatique et l'historique de versions de notre éditeur. Bon projet, exécution catastrophique.

Ce que j'ai livré, c'est une visite guidée. Voici le client, la file d'attente, la couche de stockage, la résolution de conflits, et au passage ça tenait quelques milliers de documents simultanés. Chronologique, en forme de schéma d'architecture. Une conférence.

Il me sortait sans cesse de ma visite avec des questions auxquelles je répondais mal :

• « Pourquoi un debounce sur une minuterie plutôt que sur des frontières sémantiques ? »
• « Qu'avez-vous perdu en écrivant le document entier au lieu d'un delta ? »
• « Qui s'est plaint en premier après la mise en production, et de quoi ? »
• « Qu'aviez-vous mesuré avant de décider que c'était le bon arbitrage ? »

J'avais une réponse solide pour deux questions sur quatre, et encore, reconstruites après coup. La vérité honnête : certaines de ces décisions avaient été prises par un tech lead dans une réunion où j'étais présent sans rien contester, et je n'avais jamais reconstitué le raisonnement. Alors j'ai lissé les trous, en disant « on a décidé » un nombre incalculable de fois. Quand il m'a demandé ce que je ferais différemment, j'ai reparlé de tests, et j'ai entendu à quel point c'était mince pendant que la phrase sortait.

À la quarantième minute, il a cessé de relancer et s'est mis à m'expliquer comment son équipe traitait un problème similaire. Je l'ai lu correctement : il avait fini de m'évaluer.

Les cinq jours d'écart

Un week-end et trois soirées, sans ouvrir un seul exercice d'algorithmique. Deux choses.

D'abord, j'ai écrit ce que j'appelle depuis un journal de décisions pour trois projets. Une page chacun, format rigide exprès : la décision, les deux alternatives écartées, la raison précise, le coût payé, la chose mesurée, et ce que je changerais aujourd'hui. Trois à cinq décisions par projet. Quand je n'arrivais pas à remplir une ligne honnêtement, j'allais chercher la réponse — un vieux document de conception, un fil Slack de quatorze mois, deux graphiques de dashboard pour avoir des chiffres au lieu d'adjectifs. La sauvegarde automatique m'a pris quatre heures, dont la moitié à découvrir que je n'avais jamais compris un de ses arbitrages.

Ensuite, j'ai lancé quatre boucles de simulation sur PhantomCodeAI, uniquement sur ce type de round. Les transcriptions rendaient le schéma gênant de clarté : dans les premières minutes de chaque réponse, je racontais une chronologie — « donc d'abord on a construit X, ensuite on a remarqué Y » — au lieu d'ouvrir sur la décision et son coût. Plus de deux minutes avant de dire quoi que ce soit d'évaluable. À la quatrième session, j'ouvrais par « la décision intéressante, c'était A contre B, on a pris A, et ça nous a coûté C ». Petit changement, qui valait tout le process.

Round 3 : design et architecture, 60 minutes

Orienté produit, pas infrastructure. Pas « concevez un raccourcisseur d'URL », mais : concevez le comportement hors-ligne et le modèle de synchronisation d'un outil d'édition où l'utilisateur s'attend à ce que son travail survive à un capot rabattu en pleine phrase. Deux différences nettes avec le system design façon FAANG.

Les contraintes portaient sur l'expérience utilisateur, pas sur le débit. Les relances : « que voit l'utilisateur pendant la réconciliation », « et si deux appareils sont en désaccord et que l'un est le téléphone de l'utilisateur », « quels modes de défaillance acceptez-vous de mettre en production ». Personne n'a demandé de requêtes par seconde ; quand j'ai amené des estimations de capacité, elle m'a laissé parler quatre-vingt-dix secondes puis m'a ramené à la sémantique des conflits.

Le cadrage était testé explicitement. Vers la quarantième minute : « vous avez un ingénieur et six semaines. Qu'est-ce qu'il y a dans la v1 ? » J'ai coupé le hors-ligne complet, gardé la récupération après crash depuis un buffer local, et fait une v1 en dernier-écrivain-gagne avec une bannière de conflit visible : une fusion silencieuse et fausse est pire qu'une fusion honnête et moche. Elle a insisté — la bannière, ce n'était pas une esquive ? J'ai dit que si, que c'était le bon choix pour six semaines, et que je voudrais de la télémétrie sur sa fréquence avant de décider si la v2 avait besoin d'une vraie fusion.

C'est le moment où le process a basculé : plus une évaluation, mais deux personnes qui se disputent sur une décision produit. J'ai continué à argumenter plutôt qu'acquiescer, ce que je n'aurais pas osé un mois plus tôt.

Round 4 : le manager recruteur, 50 minutes

À peine technique, et lourd de conséquences. Il m'a demandé ce que je voulais faire dans deux ans, quel type de retour je prends mal, et ce que je ferais si une designer et moi n'étions pas d'accord sur le fait qu'une fonctionnalité est prête. Puis une situation réelle de son équipe — une fonctionnalité qui part avec un défaut connu — et : que couperiez-vous, garderiez-vous, décaleriez-vous ?

J'ai utilisé le réflexe du journal de décisions sans l'avoir prévu : au lieu d'une philosophie générale, j'ai nommé ce que je couperais, pourquoi la coupe était peu coûteuse, et ce que je mesurerais après la mise en production pour savoir si j'avais eu tort. Il a contesté un choix ; j'ai tenu deux points, cédé sur le troisième, et expliqué pourquoi.

Vers la fin : « qu'est-ce que nous faisons aujourd'hui sur quoi vous nous contrediriez ? » Question à préparer. J'ai nommé un comportement précis du produit, expliqué pourquoi c'était le mauvais réglage par défaut, puis dit ce qu'il me faudrait savoir avant de faire confiance à mon propre avis. Il a ri : la moitié de son équipe pensait comme moi. Il a ensuite demandé mes questions, et j'en avais six écrites — ce n'est pas un trait de caractère, c'est de la préparation.

L'attente, puis l'appel

Onze jours de silence. Au huitième, j'ai envoyé à la recruteuse un message court pour demander s'il lui manquait quelque chose : c'est la dose maximale de relance acceptable.

L'appel est arrivé un vendredi après-midi. Offre sur le poste d'ingénieur produit, dans l'équipe avec laquelle j'avais parlé, sous le manager avec qui je m'étais disputé. Le détail du débrief auquel je repense : le deep dive est remonté comme le signal le plus faible, et les rounds design et manager l'ont rattrapé.

La négociation, version française

Je ne publierai pas de chiffres : un seul point de données vaut moins que rien. La forme de ce que j'ai demandé se transpose, elle, et une partie est spécifiquement française.

1. La fourchette et ma position dedans. Pas « vous pouvez faire mieux ? », mais « quelle est la fourchette pour ce niveau et cette localisation, où se situe cette offre dedans, et qu'est-ce qui la ferait bouger ? »
2. Le préavis, tout de suite. Trois mois en statut cadre, annoncés au premier appel. La date de démarrage a été le point le plus facile : trois semaines de plus, accordées immédiatement.
3. Le calendrier d'acquisition des actions. Peu d'employeurs français proposent des RSU, donc peu de candidats savent les lire. J'ai demandé la cadence d'acquisition et la politique de refresh, pas seulement le montant initial.
4. Les jours de télétravail et le périmètre du premier projet, par écrit. Rien de contractuel, juste de la clarté. La réponse était précise, signe que l'équipe avait réfléchi au besoin plutôt qu'ouvert un poste par habitude.

Un élément a bougé, les autres non. Résultat normal.

Le plan de deux semaines que je referais

Avec quatorze jours devant moi, voici comment je les passerais — notez la faible part de code.

Jours 1 à 3 : les journaux de décisions. Trois projets, une page chacun, le format ci-dessus. Si une ligne reste vide, cherchez la réponse dans les vieux documents de conception, les tickets et les dashboards. Au moins un chiffre réel par projet. Le point le plus rentable, et presque personne ne le fait.

Jour 4 : répéter les ouvertures. Pour chacune des douze décisions, dites la première phrase à voix haute jusqu'à ce qu'elle commence par l'arbitrage, pas par la chronologie.

Jours 5 à 7 : du code pratique, dans un vrai éditeur. Prenez des exercices auxquels on ajoute une deuxième puis une troisième exigence une fois terminés, et écrivez les tests. Si toute votre préparation vit sur une plateforme qui note des cas de test cachés, vous entraînez le mauvais réflexe — le guide pour les postes seniors et la décomposition full-stack détaillent ce schéma.

Jours 8 à 10 : du design orienté produit. Trois outils que vous utilisez, une sous-fonctionnalité difficile chacun : annulation à travers une frontière réseau, édition hors-ligne, versionnement, permissions partagées. Répondez à « qu'y a-t-il dans la v1 avec un ingénieur et six semaines » et « que voit l'utilisateur quand ça se passe mal ». Sautez les calculs de capacité ; côté interface, le guide front-end est la base la plus proche.

Jour 11 : le round manager. Écrivez : pourquoi cette équipe, ce que vous voulez dans deux ans, un désaccord perdu, une chose du produit sur laquelle vous les contrediriez. Puis vos six questions. Les questions comportementales servent de liste de contrôle.

Jours 12 et 13 : deux boucles complètes de simulation, à la suite. J'ai fait les miennes sur PhantomCodeAI parce que j'avais besoin de la transcription plus que d'un avis amical, et je vérifiais une seule chose : est-ce que je redérivais vers la chronologie sous pression. Faites-en une fatigué, l'état dans lequel vous serez au quatrième round.

Jour 14 : rien. Relisez les journaux.

Ce que je me dirais en mars

Les trois mois d'algorithmique n'ont pas été perdus : ils ont rendu les rounds de code calmes, et le calme vaut cher. Mais leur proportion était absurde. Mon process récompensait la profondeur sur un système que j'avais réellement construit et la capacité à défendre une décision produit face à un désaccord poli. Je n'avais consacré presque aucun temps à l'un ni à l'autre.

Si vous vous entraînez depuis des mois sur le modèle FAANG et que vous passez un entretien dans une entreprise dont le métier est l'artisanat produit, l'ajustement n'est pas « préparer plus », c'est préparer autrement : en visant la partie de votre expérience que vous n'avez jamais eu à expliquer à un inconnu autorisé à continuer de demander pourquoi. Écrivez le journal de décisions d'abord.

Questions fréquentes

Combien de rounds compte le process Adobe ?

Le mien a compté un appel RH de 30 minutes, un test technique d'une heure dans un éditeur partagé, puis quatre rounds onsite répartis sur deux journées. Le format varie selon l'équipe et le poste ouvert, donc considérez ceci comme l'expérience d'une seule personne. Quand j'ai demandé le détail du programme à ma recruteuse, elle me l'a envoyé sans difficulté, avec le nom des rounds et leur angle.

Le niveau de code est-il plus difficile que sur LeetCode ?

Il n'est pas plus difficile, il est différent. Les exercices de mon process ressemblaient à une petite tâche réaliste à laquelle on ajoute deux exigences en cours de route, pas à une énigme avec une astuce unique à trouver. On m'a demandé de bien nommer mes variables, de gérer une entrée malformée et d'étendre deux fois mon propre code, ce qui pénalise directement l'habitude de réciter une solution mémorisée.

Quel est le round qui a failli me coûter l'offre ?

Le deep dive sur un projet passé. J'ai livré une visite guidée chronologique de mon architecture au lieu de défendre les trois ou quatre décisions qu'elle contenait, et j'ai été incapable d'expliquer pourquoi j'avais écarté les alternatives. Chez Adobe, ce round est un vrai signal d'évaluation et pas un échauffement : je m'en suis sorti uniquement parce que mon onsite était coupé en deux blocs.

Les entretiens se déroulent-ils en français quand on postule depuis la France ?

Dans mon cas, seul le premier appel RH a commencé en français. Les cinq rounds suivants se sont tenus en anglais, avec des personnes basées dans trois pays et aucune en France. C'est la norme quand le poste est rattaché à une équipe d'ingénierie européenne. Entraînez-vous à raconter un arbitrage technique en anglais à voix haute : c'est un exercice très différent de savoir le raconter en français.

Que peut-on négocier concrètement depuis la France ?

Je n'ai pas obtenu tout ce que j'ai demandé, et c'est normal. J'ai demandé la fourchette du niveau et ce qui, précisément, ferait bouger ma position dedans ; j'ai négocié la date de démarrage en tenant compte de mes trois mois de préavis cadre ; j'ai fait préciser le nombre de jours de télétravail et le périmètre de mon premier projet par écrit. Sur les actions, j'ai demandé le calendrier d'acquisition, un point que peu d'employeurs français proposent et qu'on évalue donc mal.

Faut-il une cooptation pour être rappelé ?

Ma candidature spontanée est restée six semaines sans réponse ; une cooptation a déclenché un mail de recruteuse en neuf jours. La cooptation ne supprime aucune étape d'évaluation et ne vous fait passer aucun round plus facilement, elle fait juste ouvrir votre dossier par un humain. Sur une entreprise d'environ 30 000 personnes, c'est exactement la différence qui compte.