Être bon en entretien technique et être bon développeur sont deux choses bien distinctes. C’est devenu deux compétences différentes. Et plus seulement pour les grandes entreprises. Mais pourquoi ? Et comment bien s’y préparer ?
Root
Pour que tu comprennes l’absurde situation dans laquelle tu es aujourd’hui, il faut qu’on discute de son origine. Comme souvent, dans le milieu de la tech, notre histoire commence chez les géants. Facebook, Amazon, Apple, Netflix, Google, Microsoft et tous les autres. Pour aller plus vite je vais parler des « FAANG », l’acronyme qui vient de la bourse et que tout le monde utilise.
Nous sommes au début des années 2000, les FAANG sont jeunes (Facebook 2004) mais déjà très prestigieuses. Elles sont mondialement connues pour leurs produits, mais aussi pour leurs entretiens d’embauche. Des entretiens hors du commun.
Les tests d’algorithmes et de structures de données étaient déjà présents, mais en moindre mesure. Ces géants recrutaient principalement en posant des questions complètement folles. Des casse-têtes infernaux sous forme d’énigmes. On en a tous entendu parler de ces fameuses questions.
À partir du milieu / fin des années 2000, ces questions sont alors complément bannies, jugées trop compliquées. L’entretien technique chez les FAANG évolue presque exclusivement vers ces fameux entretiens de structure de données et d’algorithmes extrêmes.
Cette nouvelle ère est d’ailleurs « officialisée » par la sortie du bouquin mondialement connu « cracking the code interview« . Ce virage radical va avoir un impact sur tout le reste de l’industrie.
Optimisation
Tu veux être engagé chez les FAANG aujourd’hui ? C’est l’enfer. Accroche-toi, t’es pas prêt.
Déjà, il faut que tu obtiennes un entretien. Avec le nombre de CVs qu’ils reçoivent, c’est plus au moins une bouteille à la mer. Même avec ton CV hors du commun. La plupart des gens obtiennent un entretien via un salarié déjà en poste qui réfère.
T’as obtenu un entretien ? C’est beau, la seconde étape c’est un test technique en visioconférence. Le recruteur va te mettre devant un google doc et te poser une question infernale. Une sorte de casse-tête fou à base d’algorithmes et de structures de données avancées.
Tu vas devoir résoudre ce casse-tête dans des conditions qui vont te mettre à l’aise.
- Avec un compte à rebours au-dessus de la gueule
- Dans un google doc
- Sans internet
- En expliquant en temps réel ton raisonnement au recruteur qui analyse tout ce que tu fais et tout ce que tu dis
Voici une reproduction réaliste de ce qui t’attend.
Je sais pas toi, mais personnellement il me faudrait des mois de préparation juste pour avoir une chance à cette seconde étape. T’as réussi ? T’es trop fort. On peut passer à la partie difficile.
Cette fois, ils te font venir tous frais payés directement chez eux. Ils vont te torturer avec 4 à 5 tests de casse-têtes infernaux d’algorithme avancé. Cette fois ça sera sur un tableau blanc et avec le même principe de temps limité et d’explication temps réel.
Notons que si tu rates un seul de ces tests, y’a peu de chances qu’on te rappelle. Et je vais être honnête, je trouve que tout cet enfer est très justifié chez ces géants.
Bienvenu chez Facebook
Ces entretiens techniques sont intentionnellement extrêmement compliqués. C’est leur moyen de « dégraisser » la masse de candidats. Même un développeur senior avec beaucoup de talent doit passer des mois de travail acharné pour espérer avoir une chance à ces entretiens sans pitié.
Combien sont prêts à faire ces efforts ?
De plus, avec le volume et le trafic qu’ils gèrent, leur besoin côté scaling est ahurissant. Une connaissance poussée des structures de données et des algorithmes pour maximiser les optimisations est vitale chez eux. Sans compter le fait qu’une solution optimisée à l’extrême leur fera gagner énormément d’argent. Engager un profile qui peut faire ça facilement est obligatoire.
Enfin, on va pas se mentir, même si tu peux t’en sortir (mon humble avis) en repérant des patterns dans les casse-têtes, c’est aussi un test de QI. Mais alors c’est quoi le problème ?
Le problème commence quand le reste de la tech s’inspire de ces géants et part sur le même genre d’entretien technique.
Pandémie
Une maladie s’installe progressivement chez toutes les boites qui recrutent des développeurs. J’ai baptisé cette maladie « nous aussi on est les meilleurs ». L’épidémie utilise un mode de transmission qui passe par une façon de penser très commune.
« Les meilleurs fonctionnent comme ça pour avoir les meilleurs. Mais nous aussi on est les meilleurs pas vrai ? On va faire pareil pour continuer à être les meilleurs ! »
L’infection a concerné d’abord l’intégralité des boites de la silicon valley. Progressivement les boites de moyennes tailles et les startups aux États-Unis étaient touchées. Puis l’Europe et enfin le monde entier. L’OMS a classé cette épidémie comme pandémie mondiale autour de l’année 2015. Et ça, jusqu’à aujourd’hui.
Alors j’ai plusieurs choses à te préciser avant que tu prépares ton tweet assassin.
- Ça ne concerne pas 100% des boites. Et putain heureusement que c’est pas 100%. Plus la boite est « prestigieuse », ou se croit prestigieuse, plus tu vas tomber là-dessus.
- Les FAANG c’est l’exemple extrême niveau difficulté. Le boss de fin de niveau. Personne serait engagé nulle part sinon.
- Souvent les boites ne savent même pas qu’elles te font passer ce genre de tests. Ces tests sont faits via des plateformes comme CoderByte. On en parle plus tard.
- Certaines boites faisaient déjà leur test comme ça dans le passé. C’est devenu un standard partout depuis peu.
Le résultat de tout ça c’est qu’on se retrouve avec le même type d’entretien technique réservé aux développeurs un peu partout. Ça crée des situations qui ne devraient pas exister.
Doubles compétences
Y’a peu de temps, un ami développeur à moi a été rejeté pour un poste fait pour lui dans une startup. Objectivement, il est très doué en React et Javascript de façon générale. On lui a demandé d’implémenter un tri fusion pour un poste de développeur Frontend React en visioconférence. Tu vois où je veux en venir ?
Je vais te donner un autre exemple concret. Je connais et je sais utiliser l’algorithme de Dijkstra. Je peux déterminer le plus court chemin entre deux points dans un graphe. J’ai appris ça lors de mon master en informatique. En 10 ans de travail professionnel, je ne l’ai jamais utilisé. Jamais. Ça ne m’a jamais servi et ça ne fait pas de moi un meilleur développeur.
Mais en entretien technique, si. En entretien technique, si on me demande de déterminer le plus court chemin dans un graphe, ça fait de moi un dieu. Et ça fait de celui qui connaît pas l’algo, une sombre merde. Et ça, peu importe son niveau d’expertise pour faire le travail en question.
J’entends tout à fait que connaitre les bases des structures de données et quelques algorithmes est tout à fait bénéfique. Je suis d’accord et je le prêche aussi. Mais est-ce vraiment nécessaire pour tous les postes ? Et où mettre la barre de difficulté ?
Autre exemple : une amie vient de passer six entretiens pour un poste de développeur NodeJS pour une boite un peu connue. Quatre d’entre eux étaient techniques et à base de structure de données et d’algorithmes. On lui a jamais parlé de Node ou de taches réelles de l’entreprise.
Les entretiens techniques sont devenus une compétence à part entière. Pour être développeur, il faut savoir développer des applications fonctionnelles et maintenables. Pour passer l’entretien de développeur il faut maîtriser une masse hallucinante de structures de données et d’algorithme de plus en plus avancé.
Des choses que tu n’utiliseras que rarement dans la vraie vie. Quand tu le feras, tu utiliseras des solutions déjà faites et optimisées. Des solutions trouvables en quelques secondes sur Google. Cette masse de structures de données et d’algorithmes spécifiquement pour les entretiens techniques monte de plus en plus au fil des années. Ce qui nous amène fatalement à la réalité d’aujourd’hui.
Le problème
Même un développeur senior avec beaucoup de talent doit passer des semaines voir des mois de travail pour espérer avoir une chance à ces entretiens. Peu importe d’où tu viens ou ce que tu as accompli. T’as oublié l’algorithme du parcours en profondeur ? Ça dégage !
Et il est là le problème. Cette « double compétence » doit être maintenue ou rattrapée avant ton entretien technique. C’est quand la dernière fois que tu as inversé un arbre binaire au boulot ? Pourtant si tu sais pas le faire de tête en entretien technique, t’es nul.
Le boulot de tous les jours de développeur ne te prépare pas à ce type d’entretiens techniques qui se démocratisent. C’est absurde.
Et là, tu vas me dire « le problème vient de l’entreprise qui fait passer ce genre de tests ». Tu as passé un entretien récemment ? À une certaine époque, ce genre de tests était très rares dans une entreprise dite « non prestigieuse ». Ce qui est rare aujourd’hui c’est de ne pas tomber dessus, peu importe la boite. C’est lié à la pandémie dont je parlais, mais aussi à une autre raison.
Ton entretien est devenu un business
Si y’a un billet à faire, tu peux être sûr que quelqu’un va le faire. Des plateformes automatisées pour tester les développeurs sont aujourd’hui à la disposition des entreprises. C’est tellement facile à mettre en place qu’elles le font toutes. HackerRank, Codingame, Codility, Coderpad, Coderbyte, CodeSignal et j’en passe. C’est que des tests de structures de données et d’algorithmes. Véritable abattoir à la chaîne pour développeur qui n’a pas bossé sa seconde compétence.
On ne cherche plus à te tester sur ce que fait l’entreprise. Fini le contexte avec des vraies tâches de tous les jours. On t’envoie dans un endroit aseptisé où tout le monde passe par le même moule.
Tu sais pas supprimer un nœud dans un arbre binaire ? T’es un mauvais développeur. Rien à foutre que tu sois un expert Javascript pour un poste de web dev. Rien à foutre.
Les développeurs redoutent tellement ces entretiens techniques que d’autres business se sont spécialisés dans leur préparation. Des business entiers comme LeetCode, AlgoExpert ou TechInterviewPro reposent sur cette réalité. Les gens derrière ces plateformes deviennent littéralement millionnaires tellement la demande est énorme. Et si ça fait de l’argent, ça veut dire que c’est pas près de s’arrêter.
Pardon ? Ça t’es jamais arrivé un entretien technique comme ça ? Félicitations, tu es passé entre les filets d’un système qui se resserrent. Je t’invite à postuler dans une entreprise avec un nom un petit peu connu pour tester ce système.
Bref, on peut facilement se plaindre de tout ça, comme je le fais dans cet article. On peut aussi accepter la situation et se préparer en conséquence, comme je le fais le reste du temps.
Comment bien te préparer à cet enfer
Mon premier conseil pour se préparer à tout ça c’est de commencer par comprendre de quoi on parle. Si tu viens d’étude traditionnelle en informatique, ça va être beaucoup de révision. Si tu viens de formation plus courte, ça va être beaucoup de découvertes. J’ai déjà parlé de structure de données et d’algorithmes, tu peux commencer par là. Les ressources sur le sujet sont également légion sur internet.
Voici une liste non exhaustive de la base de ces entretiens techniques.
- Analyse de la complexité des algorithmes
- Complexité en temps
- Complexité en espace
- Structure de données linéaires
- Tableau
- Pile
- File
- Liste liée
- Structure de données non-linéaires
- Arbre
- Graphe
- Algorithmes
- Memoïsation
- Algorithmes de tri
- Algorithmes de parcours
Ça, c’est la base de la base. Ça te permet de comprendre l’énoncé du problème. Si tu veux travailler où tu veux, même dans des boites « prestigieuses », il va falloir en savoir plus.
Je te conseille fortement la bible incontestée des entretiens techniques : « Cracking the code interview« . Au-delà de tous les problèmes de vrais entretiens présents à l’intérieur, c’est surtout pour la façon d’expliquer de Gayle que je conseille ce bouquin. Elle a une capacité à simplifier les concepts compliqués qui rend tout plus simple. C’est ce que j’essaye de faire avec les articles techniques de ce blog. Je suis malheureusement loin d’atteindre son niveau.
Mon second conseil c’est la pratique sur les plateformes dont je te parlais précédemment. Leetcode ou Hackerank sont utilisables en dehors des programmes payants. Ce sont des plateformes qui te permettent de pratiquer des questions réelles d’entretien dans un IDE en ligne. Mais faut surtout pas le faire n’importe comment.
Les priorités pour ta double compétence
Le truc crucial à comprendre c’est que ça sert à rien de te jeter sur Leetcode le jour d’avant l’entretien. C’est mieux de faire ça régulièrement en mode file rouge. Pratiquer de temps en temps quand tu as envie pour un maximum d’efficacité.
C’est super chiant mon truc ? Oui. Mais, je l’ai dit au moins trois fois sur ce blog, c’est pas moi qui fais les entretiens.
Personnellement j’utilise la version gratuite de Leetcode. Je te conseille d’abord de commencer par les questions marquées faciles pour ne pas prendre trop cher. Quand j’ai commencé Leetcode, j’avais du mal avec les faciles. Puis à force d’en faire, c’est devenu facile.
Je suis passé au medium et pareil, j’avais trop de mal. À force d’en faire de temps en temps les mediums sont devenu faisables. Je continue et j’essaye une hard de temps en temps.
C’est à mon sens ce qui va le plus t’aider pour maintenir cette seconde compétence. Plus tu vas bosser cette seconde compétences, plus tu pourra rentrer dans la boite que tu veux. Alors évidemment pour un objectif FAANG, la théorie et Leetcode c’est pas suffisant. Les gens qui ont une chance chez les géants utilisent les grands moyens.
Pour les jeunes je vois beaucoup de récursion, memoïsation (par exemple factorielle) et de gestion de pointeurs, notamment avec des linked list. Je sais pas pourquoi, ils adorent vous faire retourner des linked list ou vous faire valider des palindromes avec deux pointeurs. Essaye de bosser ça en priorité (avec le reste) car c’est vraiment 80% des entretiens pour les jeunes.
Pour les intermédiaires, en plus du même programme que les jeunes, je vois beaucoup de recherche et de parcours de graphe. Je te parle de DFS et BFS. Le grand classico c’est une histoire de labyrinthe à parcourir. Tu vas également croiser des algorithmes de tri.
Pour les plus expérimentés, en plus du même programme que les intermédiaires, on est sur de la programmation dynamique. Je vais être honnête, déjà que le programme pour les intermédiaires je trouve ça intense, le programme pour les expérimentés je transpire fort. Tu vas avoir beaucoup de questions d’architectures également.
Enfin, la grosse erreur c’est de penser qu’un entretien technique n’est que du code. L’entretien technique n’est jamais que technique. C’est d’abord un entretien entre des humains. On va ouvertement critiquer ton code et voir comment tu réagis. Je ferai un article là dessus plus tard, mais il faut que tu penses à ça aussi.
