Comment affronter un entretien technique des enfers ?

J’ai passé le process d’entretien le plus intense de toute ma vie. Sept heures réparties sur une semaine à la rencontre de 15 personnes. Sept heures. Dont deux heures de coding live et deux heures de system design. Comment cette folie furieuse s’est finie ? Et surtout, comment tu peux utiliser mon expérience pour dominer ton prochain entretien technique ?

Cher lecteur

Ça fait longtemps qu’on n’a pas discuté.

Presque un an qu’on se parle plus. Je t’avais pas habitué à ça. Je m’étais pas habitué à ça.

Je suis devenu papa.

Ma fille avait décidé que la nuit, c’etait pas fait pour dormir. Elle est infiniment plus importante que ce blog. J’ai utilisé les heures que je consacrais normalement à ce blog pour récupérer du sommeil.

Mais récemment, coup de théâtre !

Elle a changé d’avis.

Elle a décidé de dormir la nuit finalement.

Du coup, moi aussi. Je suis en pleine forme.

Je déclare ouvert la saison 3 de Je suis un dev.

C’est reparti comme en 40.

La candidature

On est dimanche soir et aujourd’hui est un jour spécial.

C’est le jour du mois où je vais sur Linkedin pour rigoler un coup.

Linkedin c’est que des posts fous comme celui-là. Ou celui-ci.

Tu l’as vu le barjo qui organise un Hunger Game pour recruter un dev junior ?

Je prends énormément de plaisir à consulter ce concentré de folie humaine qu’est Linkedin.

C’est exceptionnel.

Soudainement, au milieu du chaos, mon oeil est attiré par une annonce de job.

Le job à l’air canon.

L’entreprise à l’air canon.

C’est dans l’industrie qui m’intéresse.

La description de poste me correspond tellement que c’est limite écrit mon nom.

---

OK ça à l’air fou. Je postule ou pas ? Attends, mais j’ai pas prévu de quitter mon job. Pourquoi je me ferais chier ? Bon après, ça serait drôle de faire les entretiens pour voir non ?

---

Après une longue discussion dans ma tête, je décide d’envoyer un CV.

On verra bien.

Mardi matin, je reçois une réponse.

Une vraie réponse d’un humain. J’avais presque oublié cette histoire tellement je l’ai fait sur un coup de tête.

Ça fait longtemps que j’ai pas fait un entretien pour une grosse boîte. Ça fait longtemps que j’ai pas fait un entretien pour un poste aussi costaud. Ça fait longtemps que j’ai pas fait un entretien tout court.

Allez on tente, on y va détente, pour l’amour du rire, no pressure.

Heure 1 : Le recruteur

Les premiers contacts avec une boîte sont presque toujours les mêmes.

Un appel avec un recruteur. Son but va être de déterminer si tu es un être humain normal et si tu corresponds à l’annonce. Ça va clairement être l’heure la plus simple à gérer.

À part si tu pètes un plomb et commences à dire des trucs tout bizzares évidemment.

Captcha

Je regarde fixement l’heure depuis 5 minutes.

Ça y est. Il est 13h pétante. Mon téléphone sonne presque immédiatement.
Un numéro inconnu qui appelle depuis Seattle.

C’est sûr c’est eux.

---

Ha ! Je me chie dessus là. Déjà !? J’étais censé y aller détente, mais en fait y’a zéro détente. C’est la partie facile là Mehdi, t’as rien fait encore. Allez, calme-toi, réponds!

---

Quand je décroche j’entends une voix bienvaillante, mais très rapide qui m’enchaîne un discours corpo à 300km/h. Je comprends que je suis l’appel 3789 de la matinée. Va falloir que j’enchaîne aussi.

Première demande ?

« Présentez-vous. »

Je suis stupéfait.

Je m’y attendais pas du tout.

Je déballe donc mon discours aux petits oignons que j’avais préparé en amont. Trois étoiles. De la grande cuisine. Je me suis pas foutu de sa gueule.

Il est content. J’entends son sourire au téléphone. Ça commence fort.

Je prends un incroyable boost de confiance immédiatement.

Sans confiance, t’es mort en entretien. Peu importe le niveau, l’étape ou la planète où tu le passes. C’est ta mana, ton mojo, l’ultime ressource qui te maintient en vie.

Je deviens un absolu tueur pour le reste de l’entretien.

Chauffer les tuyaux

Maintenant que le recruteur sait que tu es un humain à peu près normal, il va essayer de savoir si tu match techniquement et au niveau de l’expérience.

Cette première heure d’entretien sert à déterminer une seule chose.

Es-tu apte à passer les vrais entretiens ?

L’annonce à laquelle je répondais était très claire. Il faut un niveau sérieux en Kubernetes. J’ai donc insisté comme un gros lourd sur mes 5 ans d’expérience dessus.

L’annonce parlait aussi de Golang et TypeScript en langages principaux. J’ai donc insisté sur un projet où j’avais écrit deux microservices dans les deux langages.

Le recruteur il était en feu au téléphone. Il m’a tout de suite demandé mes disponibilités pour la suite des entretiens. Confirmant au passage que je vais à la prochaine étape.

Et c’est là qu’il m’a lâché une dinguerie.

• Recruteur : « Nous fonctionnons avec un système de panel d’entretien. Entre 6 à 7 entretiens d’une à deux heures où vous rencontrez toute l’équipe et certaines équipes connexes. Pas plus de quatre personnes à la fois et étalées sur une semaine. C’est un peu long, mais ça nous assure une qualité exceptionnelle de recrutement »

Pour moi, à l’autre bout du téléphone, c’était la grosse clim.

---

Bordel de merde. Et putain dans quoi je me suis embarqué encore là. Ça va être le festival du stress si je continue. Je l’envoie chier ? On fait quoi ?

---

• Moi : « Super ! Hâte de rencontrer l’équipe ! »

Heure 2 : le management

Quelques heures plus tard, j’ai reçu un mail.

C’était un agenda de tous les calls Zoom avec les heures, la durée et les noms des personnes dans le call.

J’ai immédiatement stalké ces gens sur Linkedin pour savoir qui ils étaient. Le premier call, c’est très clair. Les quatre personnes qui m’attendent sont des directeurs et managers.

La première épreuve est de convaincre le management.

Prévisible

On est le lundi d’après. Il est 12h55. J’ai pas mangé. Trop stressé.

Je fais des tours en rond autour de ma copine qui essaye de travailler dans le salon.

Je décide de monter mon bureau en position debout pour l’entretien.

---

Grâce à ce move, ils vont se dirent que je suis une personne active et pleine d’entrain. Ça fait moins plouc que d’être assis ! Ou alors ça change absolument rien ? Ça change absolument rien.

---

13h, je lance le Zoom.

Ils sont déjà tous là à m’attendre dans un silence de cathédrale.

Je dis bonjour.

Y’a des sourires timides.

Un des quatres m’interpelle sur le Ukulele qu’on voit dans mon arriére-plan. Je l’attrape et lui joue quelques notes. C’est bon c’est la famile, on peut commencer.

Pour ce type d’entretien, il te faut une préparation bien spéciale.

Le management veut savoir certaines choses en particulier. C’est une liste que je sors un peu de mon cul, mais finalement c’est toujours la même chose.

• Est-ce que tu sais communiquer ?
• Est-ce que tu sais gérer ton temps ?
• Est-ce que tu sais gérer ton stress ?
• Est-ce que tu sais gérer les conflits ?
• Est-ce que tu t’intéresses à ton travail ?

Gestion des relations, des émotions, ton organisation et ta vision globale des choses.

Ce genre d’entretien est pas mal prévisible. Les questions se ressemblent toutes plus ou moins. Se préparer à quelques-unes de ces questions est décisif.

• « Parlez-moi d’une occurrence où vous avez géré un conflit? »
• « Parlez-moi d’une occurrence où vous avez livré un travail en retard. »
• « Qu’est-ce qui vous déplaît dans la méthode scrum ? »
• « Quelles sont les qualités indispensables d’un développeur ? »

J’avais préparé cette petite liste. 100% sont tombées durant l’entretien.

J’enchaîne les réponses et en plus de regard approbateur, j’ai des sourires.

Je ne peux pas t’aider pour créer le côté humain et bon feeling dans un entretien. Mais c’est extrêmement important. Avant un dev, on recrute un humain. Un humain avec qui on va bosser tous les jours.

Il faut laisser une belle, unique et agréable marque dans l’esprit de tout le monde.

C’est exactement ce que je faisais.

Ceci dit, j’en vois un qui dit quedal depuis le début.

Ça doit faire une demi-heure déjà que ça a commencé pourtant. Je l’observe de temps en temps. Je vois bien qu’il regarde autre chose.

Il en a vraiment rien à foutre de ma gueule.

Heureusement, c’est pas le cas des trois autres. Ça se passe vraiment bien avec eux. Je crois que j’ai vraiment marqué des points à la dernière question.

• Moi : « Je pense que l’une des qualités les plus importantes c’est la fiabilité. Je ne promets pas la lune pour faire plaisir aux gens. J’essaye pas d’être le plus rapide et le plus impressionnant. J’essaye d’être le plus fiable et plus constant possible. Si je suis en retard, je le dis immédiatement. Mon travail est complet et testé. Mon objectif est d’éviter les surprises. Autant au niveau de mon code qu’au niveau du planning. »

C’était plié.

Ça se voyait sur leur tronche qu’ils voulaient tous m’épouser. J’ai tapé dans le mille. On me parlait déjà de l’étape d’après.

Soudainement, le quatrième, celui qui ne dit rien depuis une heure, lève la tête.

Il a une seule question.

Imprévisible

Je pensais qu’il regardait de la merde sur YouTube. Mais non, pas du tout. Il lisait mon blog.

Oui. Le blog que t’es entrain de lire.

Je ne le dis pas car tu en as certainement rien à foutre, mais ce blog a une version anglaise. Il était sur cette version. Il scannait tout mon contenu à la recherche d’une dinguerie que j’aurais écrit dans le passé.

Évidement, c’est mon blog, y’a que ça des dingueries.

Il est tombé sur un article que j’ai écrit y’a 3 ans. Un article un peu violent pour changer. Un article où je chie littéralement sur les estimations de temps.

En Français, ça s’appelle sobrement

Ton estimation de temps est une blague

C’est internet, il faut que le titre claque un peu sinon personne clique.

• Interviewer 4 : « Je suis tombé sur votre article où vous expliquez que les estimations de temps sont une blague qui ne sont pas tenues. Comment on peut maintenir une fiabilité sur ses livrables quand on pense que toutes ces estimations de temps sont une blague ? »

Gros silence dans le zoom.

C’était malaisant.

On entendait les mouches péter.

J’en revenais pas de sa question de zinzin.

---

Ho le bâtard… il a pris de l’élan pour me faire un double tacle à la gorge. Mais c’est autorisé ça ? Il m’a pas respecté là. Les conventions de Genève on s’en fout ? Bon, du calme. Vu sa question, il a pas lu l’article jusqu’au bout,

---

Pour la plupart, les gens réagissent au titre d’un article. Ils ne le lisent pas. Classique.

Le problème c’est qu’ils ratent le plus important.

La conclusion, la réponse, la résolution, le twist, tu l’appelles comme tu veux : ce qui fait la valeur de l’article finalement.

J’ai partagé mon écran dans le zoom. J’ai commencé à leur lire cette fameuse conclusion. Une conclusion où j’explique que même si les estimations de temps sont une blague, y’a toujours un moyen de limiter les dégâts,

• Ne jamais céder à la facilité et à l’excès de confiance en faisant des estimations de temps sans analyse préalable
• Ne pas donner d’estimation absolue, donner une fourchette de temps. Quand c’est pas possible, donnez la fourchette haute.
• Garder une transparence totale, en temps réel, de la situation d’une tache qui va dépasser l’estimation pour ajuster le planning en amont.

Par tous les moyens possibles, éviter les surprises.

C’est le retour des sourires et la fin de l’entretien.

Malgré ma répartie, j’avoue que j’ai failli perdre mes moyens à la fin.

Ça va pas être la dernière fois que ça va arriver.

Heure 3 et 4 : coding live

Mardi.

Je stalke une dernière fois les participants à cette réunion.

On est sur du gros senior et principal software engineer des familles.

---

Allez, respire. Ils vont pas te manger. Ça va bien se passer. On connaît leur Leetcode à la con. On connaît ce jeu. On a gardé cette seconde compétence. Ça va le faire. Tu as deux heures devant toi. On respire. On y va doucement.

---

Je lance le zoom, je tombe sur trois personnes très sympathiques. Tout le monde se présente très brièvement. On rentre tout de suite dans le vif du sujet.

• Interviewer 1 : « On va te demander de partager ton écran et de cliquer sur le lien. Aujourd’hui, on va faire deux exercices sur cette plateforme. Le premier est simple et va te permettre de t’échauffer un peu. Le second est un peu plus complexe, mais rien d’excessif pour le temps imparti. N’oublie pas de nous parler ! »

Je reconnais immédiatement l’URL. Mes craintes étaient fondées. C’est une plateforme d’entraînement et de test live sur des puzzles de l’enfer à résoudre avec des algorithmes que tu n’utilises jamais dans un vrai travail.

Les deux prochaines heures, ça va être du live coding scruté par des champions du monde du code prêt-à me fusiller à la moindre erreur avec un compte à rebours de la mort sur chaque exercice.

Un putain d’enfer

Je vais m’adresser aux gens qui détestent ça.

Les amis, déjà on est ensemble. Aujourd’hui, on va pas débattre de savoir si ce genre de test est bien ou pas. J’ai déjà fait un article complet sur le sujet.

Oublions cinq minutes ce débat.

La réalité des choses c’est que ce genre de test est maintenant partout. Soit on s’adapte, soit on meurt. J’ai pas prévu de mourir tout de suite, je propose qu’on s’adapte.

J’insiste sur le concept d’adaptation.

Je suis vraiment pas à l’aise.

Je suis pas Mathis Hammel. Je suis pas un génie qui a pour passion de résoudre des puzzles de l’enfer, car c’est drôle. Je suis un con qui fait tout pour faire des choses simples.

Malgré mon expérience et toutes les connaissances que j’ai accumulées, ce type d’entretien est un putain d’enfer qui m’a déjà fait rater des postes dans le passé.

Visage fermé, je serre les fesses.

La plateforme prend au hasard un exercice. Le premier est un classique. C’est pas le même, mais j’ai trouvé un équivalent sur Leetcode.

C’est en effet dans la catégorie facile.

On veut savoir si tu connais et si tu sais utiliser une structure de données linéaires. Ici c’est la pile (ou stack en anglais). Sans ça, l’exercice devient plus complexe à résoudre.

C’est l’idée derrière ce genre d’épreuve.

Donc avant même de t’attaquer aux plateformes d’entraînement, fais en sorte d’avoir une solide connaissance des fondamentaux. Tu as des sources partout sur les internets, mais sache que ton humble serviteur a fait des articles sur ces sujets.

• Comprendre la notation Big O en 7 minutes
• Comprendre les structures de données linéaires en 10 minutes
• Comprendre les structures de données non linéaires en 5 minutes

Le problème c’est qu’avoir les connaissances, c’est pas suffisant.

Il faut en plus que tu suives un plan de match bien précis.

1 – On clarifie

Faut commencer par poser beaucoup de questions. Il faut être sûr de PARFAITEMENT comprendre ce que tu dois faire. N’hésite pas à passer beaucoup de temps ici. C’est vraiment critique pour ta réussite et attendu par ton interviewer.

2 – On analyse à haute voix

Les gens qui font l’entretien veulent surtout savoir comment tu raisonnes. Tu réfléchis et raisonnes dans ta tête comme une personne normale ? Arrête. Faut le faire comme un fou, à haute voix. Pour quelqu’un comme moi, efficace dans sa bulle pour penser, c’est une torture. On est ensemble les amis, c’est pas fini.

3 – On propose une solution

Ne commence surtout pas à coder direct sans proposer d’abord une solution avec un schéma ou du pseudo-code. Déjà parce que tu pourrais partir sur une solution pourrie et là t’es mort. Mais aussi car tu dois faire participer la personne avec qui tu fais l’exercice. Elle doit participer dans toutes les étapes.

4 – On code à haute voix.

Je sais que c’est tout sauf naturel. Mais au fur et à mesure que tu écris le code tu dois parler et justifier chaque étape. Bienvenu dans le dernier sous-sol des enfers. C’est un étage obligatoire.

En respectant ces étapes, j’ai réussi à leur chier cette solution en Python.

class Solution(object):
    def isValid(self, s):
        stack = []
        mapping = {")": "(", "}": "{", "]": "["}
        
        for letter in s:
            if self.isOpenChar(letter):
                stack.append(letter)
            else:
                if stack:
                    if stack[-1] != mapping[letter]:
                        return False
                    else:
                        stack.pop()
                else:
                    return False

        return not stack


    def isOpenChar(self, char):
        if char == '{' or char == '[' or char == '(':
            return True
        
        return False

Un hashmap, une stack et on en parle plus.

Y’a sûrement mieux. Plus malin, plus simple, plus efficace et surtout plus rapide. Mathis va sûrement bien se foutre de ma gueule en regardant la solution.

Je veux pas savoir Mathis.

Ça fait le taf. Tout le monde est content. Ça me fait passer à l’étape suivante.

Parkour !

Second exercice. Toujours pris au hasard. En dirait un casino à l’envers. L’équivalent le plus proche sur Leetcode c’est celui-là. Des algorithmes de parcours.

Y’a pire comme tirage.

Ça reste compliqué à sortir dans ce contexte.

Allez sur le site et faire l’exercice tranquille chez soi, ça va.

Le faire dans le contexte d’un entretien avec trois personnes qui te jugent à chaque mot prononcé et à chaque touche pressée, c’est vraiment éprouvant. Je perds mes moyens.

Si cet exercice te semble compliquer, je t’invite à lire mon article sur le sujet des entretiens.

C’est comme le sport en fait.

Si tu pars pour une course intense alors que tu n’as pas couru de l’année, tu vas te blesser. Par contre, si tu fais des petits joggings fréquemment, tu ne vas pas le sentir passé.

Il suffit de jogger un peu toute l’année pour être efficace.

Également, je te conseille d’acheter la bible pour ce type d’entretien. Le sujet est vaste. Je n’ai ni le temps, ni l’envie et encore moins les compétences pour vraiment te préparer à ce type d’entretien.

La bible le fera.

Je l’ai lu. Je suis retourné sans cesse dessus. Depuis des années. C’est un must.

Ça fait 1h45 qu’on est là. Ressenti 3 ans. Ça s’est passé très moyen.

Des longues hésitations. J’ai essayé de faire passer ça pour du stress. En vrai c’est juste que je prends du temps à percuter ce qu’ils me baragouinent en anglais pendant que je réfléchis à comment résoudre leur merde inutile.

Je te laisse trouver une solution pour cet exercice-là, c’est un bon exercice.

Tous les tests passent aux verts. Mon DFS fonctionne. Y’a des sourires et du soulagement. Mon ascenseur pour sortir des sous-sols de l’enfer vient arrivé.

Fin du zoom.

Il me faut une bière.

Heure 5 et 6 : la méthode S.T.A.R

C’est mercredi matin.

Un énorme café dans les mains, je fixe mon écran vide.

C’est sûrement l’entretien pour lequel je suis le moins stressé.

La raison est simple : le Leetcode est derrière moi. Peu de chance qu’ils recommencent avec cette merde. Je pense que cette fois on va parler du vrai métier.

On va parler du vrai monde de la réalité véritable.

Du haut de mon vertigineux ego, je suis confiant.

Je rencontre quatre développeurs seniors. Ce sont ces gens avec qui je travaillerais tous les jours si j’étais pris. Je rencontre mon équipe.

C’est l’heure.

S.T.A.R

J’arrive dans le zoom et personne.

Ils arrivent aux compte-gouttes, les uns après les autres.

Ils ont tous des background drôles genre « The Office » ou des memes à la con,

On discute du temps, de café et de jeux vidéo en attendant tout le monde. Tout de suite, je me sens bien. C’est la maison.

Dès la première question, je comprends la méthode utilisée.

• Interviewer 2 : « Est-ce que tu peux me parler d’une situation où tu as dû scaler les performances d’un système ou d’une application ? »

La méthode S.T.A.R.

Situations, Taches, Actions, Résultats.

Je te laisse aller voir les innombrables ressources sur ce sujet. En quelques mots, c’est une méthode qui te force à utiliser tes vraies situations passées, les décortiquer et prouver tes compétences à travers elles.

Si tu arrives ici avec 3000 heures d’entraînement sur des plateformes de coding mais aucune compétence métier, c’est carton rouge, tu sers à rien ça dégage.

Les try-harder avec un compte premium Leetcode en PLS.

J’ai raconté la fois où j’ai dû scaler un système online de présence d’amis interne d’un jeu vidéo AAA. Ce système devait recevoir maximum 500 000 joueurs le premier jour. Brutalement, l’exigence était passée à 3 millions.

On m’avait demandé de faire en sorte que ça tienne.

L’important à cette étape c’est de donner un maximum de détails. N’hésite pas à étaler ton savoir comme un gros lourd. Car c’est ça que les gens en face essayent de jauger.

• Moi : « La première chose que j’ai faite c’est de rendre le système très bavard en augmentant les logs pour identifier et diagnostiquer les points d’étranglements via des tests de charge de plus en plus lourds. Comme souvent, le premier maillon faible c’est la base de données. Elle explosait en plein vol pendant le test de charge passé les 100K CCU. Les temps de réponse en lecture augmentaient de façon exponentielle jusqu’à crasher tout le système. On pourrait commencer à parler de réplication master/slave pour optimiser la performance des opérations read car répartie sur différents serveurs dédiés à la lecture. On pourrait aussi aborder le sujet complexe du sharding horizontal et/ou vertical qui augmenterait aussi considérablement le temps de réponse de lecture, la donnée étant segmentée et donc répartie un peu partout. Mais je préfère d’abord commencer par des choses plus simples et plus rapides à faire, car plus basiques. De l’optimisation, comme les index par exemple. Les index sont un formidable point d’amélioration de performance surprenamment efficaces et presque à chaque fois ignorés. En étudiant les logs et le code, je me suis rendu compte qu’une quantité gigantesque d’appels à la base n’était pas optimisée du tout! Ce qui … »

Et là, choses assez rare dans n’importe quel entretien, on coupe la parole au candidat.

• Interviewer 1 : « Est-ce que tu peux me dire comment fonctionnent les index au niveau de la base de données ? »

Ça me surprend.

• Moi : « Je sais que plusieurs structures de données sont créées en plus de la donnée originelle. Une copie ordonnée des données autour du ou des champs indexés. Comme on passe d’une recherche non ordonnée à ordonnée, la réponse est plus rapide pour la lecture. Par contre pour l’écriture ça devient plus long, car il faut mettre à jour les nouvelles structures. »

• Interview 4 : « OK. Est-ce que tu peux nous expliquer plus précisément pourquoi cette recherche dans cette copie organisée est aussi rapide ? »

---

Ils vont m’arrêter sur chaque détail à chaque fois que je dis un mot ? C’est un truc de zinzin. Je vais pas avoir réponse à tout. Si ça se trouve, c’est le but. Commence pas à te chier dessus si tu sais pas Mehdi. Poker face, on dit tout de suite si on sait pas.

---

• Moi : « J’imagine que tout simplement sur une liste non ordonnée la vitesse de recherche est linéaire, donc O(n). On passe sur chaque ligne pour trouver l’information. Plus la table est grande, plus c’est long. Selon comment sont organisées les données indexées on va être sur un ordre de vitesse plus grand. J’ai le vague souvenir de mes cours de SQL qui parlaient d’arbre binaire. Arbre binaire ça veut dire recherche dichotomique. Recherche dichotomique ça veut dire O(log n). Ce qui est plus rapide que O(n). Après, comment exactement les index sont structurés pour faire fonctionner cette recherche dichotomique, je sais pas. »
• Interviewer 4 : « OK. Tu peux continuer »

Toutes les cinq minutes, ils m’ont arrêté dans mon histoire pour faire le même cinéma.

Ce fut la discussion technique la plus intéressante que j’ai jamais eue.

Super S.T.A.R

Ils ont pris la méthode S.T.A.R, et ils ont ajouté un super twist dessus.

Je trouve qu’il y’a une beauté technique ici.

Est que tu sais vraiment ce que tu as fait ? L’as tu construit avec intérêt et souci du détail ? Ou bien quelqu’un d’autre la fait pour toi et tu as vaguement touché le sujet ?

Si tu t’inventes une vie, tu ne passes pas les filets de cette savante méthode de questionnement.

Seule la vraie compétence métier te permettra d’accéder au prochain niveau.

Et le véritable twist de cette méthode c’est que, j’ai pas vraiment de conseil à te donner !

Seuls ton investissement professionnel et les compétences qu’elles ont engendrées peuvent t’aider.

C’est le dernier quart d’heure. C’est à mon tour de leur poser des questions. Ça s’est tellement bien passé que j’ai l’impression que je me suis fait des amis.

Je ferme le zoom fatigué et content.

J’ai hâte d’en finir demain.

Heure 7 : system design

Je me suis réveillé à la rache ce jeudi matin. J’en ai vraiment plein le cul. J’ai même plus envie de les faire ces deux dernières heures.

J’ai regardé vite fait les gens que je vais rencontrer. Un architecte et un directeur technique. C’est évident ce qu’on va me demander.

Architecture de systéme.

---

J’y vais vraiment les mains dans les poches. C’est abusé. En meme temps, du system design je fait ça presque tous les jours en ce moment. C’est plus ou moins mon taf. Ça va le faire, fais-toi confiance un peu.

---

A peine le temps de boire mon café que c’est deja l’heure de lancer le zoom.

Confiance

Je tombe sur deux vieux de la veille hyper sympa avec qui le courant passe tout de suite.

Ça débute avec les traditionnelles présentations.

Puis vient le moment de rentrer dans le vif du sujet.

• Interviewer 2 : « On va t’envoyer un lien. C’est simplement une session de whiteboarding collaboratif. Tu vas partager ton écran et on va construire un système ensemble. Tu vas nous expliquer toutes les étapes. »
• Moi : « OK super! Je suis prêt, on construit quoi? »
• Interviewer 1 : « On veut que tu architectes un concurrent direct à Twitter. On veut exactement les mêmes features. Tu peux nous poser toutes les questions que tu veux. »

Y’a pas plus classique pour un entretien d’architecture systéme.

On prend un système dit « connu » comme un réseau social. On sait qu’il y a beaucoup de problématiques à traiter. Il y a énormément de connaissances à avoir pour répondre correctement à une question pareille.

Je connais le sujet. Je sais à peu près comment architecturer un truc pareil. Je suis devant le whiteboard collaboratif. Les deux m’écoutent. Y’a plus qu’a !

Et là, j’ai commencé à faire un truc que je pensais pas possible de ma part et certainement pas à cette étape.

J’ai paniqué.

Panique

Pour réussir un entretien d’architecture de système, tu peux pas improviser.

Évidemment, il faut la connaissance en elle-même. Je peux pas t’aider là-dessus. Il faut avoir construit et/ou participer à la construction de nombreux systèmes.

Mais ça suffit pas.

Il y a une manière de répondre à ce genre de questions. Et le pire c’est que cette méthode, ce framework, je le connais. Je l’ai déjà pratiqué. Je l’avais appris et répété il y a plusieurs années auparavant.

Ça s’appelle le framework P.E.D.A.L.S pour :

Process Requirements

Estimate

Design service

Articulate Data

Scale

Je vais pas t’expliquer chacune des étapes aujourd’hui.

Il faudrait en faire un article entier.

Ceci dit, t’as pas besoin de moi pour comprendre ce framework. Je l’ai appris en détail en achetant ce bouquin. Je te le conseille fortement. Même si tu passes pas d’entretien d’architecture.

Si tu en passes un, le bouquin est obligatoire.

Il y en a d’autres. Tu lis celui que tu veux. L’important c’est d’avoir la méthode, le framework. Et surtout de la répéter avant au lieu d’y aller les mains dans les poches comme moi.

Comme un gros débile, j’ai commencé à partir dans tous les sens.

Dans n’importe quel ordre. De façon frénétique. On aurait dit un fou.

J’ai commencé par la fin en désignant immédiatement un système qui scale. J’ai ensuite demandé les requirements pour des choses que j’avais déjà évaluées au pifomètre. Je parlais de data sans à aucun moment aborder l’API.

Je disais que de la merde.

Au milieu de l’entretien, j’étais perdu dans mes explications. Je sentais qu’ils avaient lâché aussi. Le pire c’est que le résultat final sur le whiteboard était pas si mauvais que ça.

Mais c’est comme avoir le bon résultat en math sans avoir fait une belle démonstration qui montre que tu as vraiment compris : ça sert à rien.

Normalement, on passe à une seconde question. C’est pas le cas ce jour-là. Ils m’ont bombardé de questions techniques sur l’architecture de façon générale.

Au début je répondais. Vers la fin c’était trop pour moi.

J’ai commencé à dire beaucoup de « je ne sais pas ».

Ils ont poliment écourté.

Fin du zoom.

C’était une catastrophe.

Verdict

On est le mardi d’après.

Je suis censé recevoir un appel à tout moment pour m’annoncer le verdict.

Le téléphone sonne. Un appel de Seattle. Je réponds. C’est la même personne que j’ai eue durant la première heure.

Après deux/trois politesses, c’est l’heure du verdict.

Je m’attends à tout et à rien en même temps.

J’ai vraiment aucune idée de ce qu’ils ont décidé.

• Recruteur : « C’est assez rare pour être souligné : vous avez fait l’unanimité dans le panel. Chaque personne que vous avez rencontrée recommande votre embauche. Bravo! On va vous envoyer une offre officielle dans les heures qui viennent. Je vous laisse découvrir l’offre par vous-mêmes, mais sachez qu’on a fait des efforts pour vous convaincre. »

Mission accomplie.

Et ça finit sur un putain de feux d’artifice.

J’en revenais pas.

Quelques heures plus tard, je reçois mon offre. Ils ont en effet des arguments. Ils ont pris le chiffre de la compensation totale que j’ai demandé et ils me l’ont donné en compensation de base.

Donc avant bonus, RSU stock et autres primes et vacances.

Ça fait beaucoup. J’ai 5 jours devant moi pour répondre à cette offre. Elle expire sans possibilité d’en avoir une autre après ce délai.

J’ai passé les trois jours suivants à peser le pour et le contre.

C’était à mon tour de les évaluer.

Épilogue

L’histoire ne dit pas si j’accepte ou je refuse cette offre. Pour des raisons évidentes. Mon expérience était assez atypique. Mais je pense qu’elle peut énormément t’aider à gérer ce qui t’attend. Car, tôt ou tard, si tu veux faire avancer ta carrière, tu vas en avoir besoin. Pour sortir en un morceau des enfers, il faut y rentrer bien préparé.