L’entretien technique est une compétence à part entière
Ê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.
À combien estimez-vous le nettoyage de toutes les fenêtres de Manhattan ? Combien de balles de golf peut contenir un bus scolaire ? Comment obtenir 4 litres à partir de deux bouteilles de 3 et 5 litres ?
À 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.
- Structure de données linéaires
- Tableau
- Pile
- File
- Liste liée
- Structure de données non-linéaires
- Arbre
- Graphe
Ç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.
Épilogue
Les entretiens techniques sont à l’image de notre métier, compliqués et vite casse-gueule sans pratique. Ils ont évolué dans le passé et vont évoluer dans le futur. Les structures de données et les algorithmes ne sont pas forcément une mauvaise idée si la difficulté est adaptée au poste. Sinon, on pourrait tester le candidat sur des taches réelles qu’il va accomplir pour le poste. Sur un IDE et avec une connexion internet. Comme dans la vraie vie. Je sais, elle est folle mon idée.
J’adore ce que tu fais, merci pour le partage de tes connaissances. Ca m’aide dans ma reconversion
C’est pas que pour les dev d’ailleurs, je suis devops/sysadmin, j’ai aussi droit à ce genre de trucs. Et c’est effectivement infernal.
Les ssii dès qu’on me parle de tests techniques je racroche au nez !
Tellement vrai !
On me fait passer des tests sur codingame : piloter space x, savoir opérer a coeur ouvert et faire un risotto de chef étoilé en 4 minutes… tout ça pour un job de tma sur un backoffice -_-
Je vais être cash et concis.
Les entreprises qui se permettent de juger nos compétences, en nous faisant passer des tests complètement déconnectés de la réalité du poste visé, ne sont pas dignes de nous recevoir en entretien d’embauche.
Ce ne sont que de minables petites merdes qui se prennent pour des stars, et auxquelles, pour ma part, je voue un mépris sans limite.
Fin.
Certes.
Eux ils s’en foutent si tu les méprise et si tu refuse. Le but justement est d’éliminer les diligentes et les gens qui sont pas motivés. Tu t’es éliminé et quelques autres aussi. Alors y’aura peu être que 1 million de candidatures pour 5000 postes au lieu de 2 millions.
Et puis bon les dev là bas bossent sur des sujet intéréssant, il font le futur et il sont bien mieux payés qu’ailleur ce qui ne gache rien. Si tu refuse leur process, tu refuse ça aussi.
Le probléme reste que si effectivement le seul but est de faire des site web de gestion en SSII c’est ridicule. D’un autre coté, 14 ans d’XP fait quelques disaines d’entretien et j’ai eu à faire ça qu’une fois. Et c’était plus facile que ce qui est décrit ici.
C’est très étonnant. Tout ce dont vous parlez faisait partie du programme de licence info géné à Paris VI fin années 80. Il y avait un module algo et structures de données en S1 et S2. Le livre de chevet était le Aho (c’est le A de awk) Hopcroft Ullman : Structures de données et algorithmes livre que j’ai toujours et qui est passionnant (enfin façon de parler).
Aho et Ullmann ont aussi écrit le « Dragon », autre ouvrage de table de chevet (et pas pour la caler 😃) sur la compilation. Des dieux vivants.
J’ai postulé dans une filiale d’Airbus récemment. Ils font de la sécurité pour ne pas les nommer… Et globalement, tout comme tu l’explique dans ton article, j’ai passé une batterie de tests. En soit ce n’était pas de l’algorithmie mais de réels test de compétence sur la compréhension globale du fonctionnement d’une API.
Jusque là tout allait bien.
Je trouve en revanche dommage qu’en recherchant des profils juniors ils exigent que le junior en question connaisse par exemple les spécificités des dernières versions d’Ecma sur le bout des doigts et qu’il sache faire de l’admin réseau etc. Même si j’assume que mon profil n’ait pas été assez technique, je ne comprends pas pourquoi les boîtes exigent autant de compétences alors que l’offre est faite pour un junior développeur web à peine sorti d’école. Le réseau est un métier à part et les nouvelles normes Ecma s’apprennent avec le temps et l’expérience, à moins d’exiger qu’un junior passe ses soirées devant l’écran. Ce n’est pas viable et je trouve également cela un peu absurde.. Enfin, j’y reviendrai quand même, on lâche rien ^^
Je travaille depuis plus de 3 ans chez un gros (leader fr) éditeur logiciel à destination des banques et des assurances. Je suis passé par un mini-test en entretient, simplement pour justifier que je connaissais au moins les bases. Rien d’insurmontable pour n’importe quel développeur. Du côté de l’entreprise, ça se faisait depuis qu’ils ont réussi à recruter au poste de développeur quelqu’un qui n’avait jamais taper la moindre ligne de code de sa vie…
J’ai certainement eu beaucoup de chance de ne pas tomber sur ces fameux entretiens techniques. Il est certain que je suis nul. Je n’apprends pas les algos par coeur, j’estime que ça n’a aucun intérêt. J’essaye de les assimiler si j’en ai besoin pour un projet particulier et j’oublie ensuite. Parce que ça ne me sert à rien dans mon quotidien professionnel (et que je suis webdev orienté front même si j’ai un petit bagage fullstack).
J’avoue que cet état de fait me fait un peu peur. Plus ce sera généralisé, moins j’ai de chance de pouvoir être embauché ailleurs. Pourtant, sans être un développeur exceptionnel, je pense me débrouiller dans mon travail.
Mais j’ose croire que ça finira par s’effondrer quand on finira par se rendre compte que ces entreprises se coupent de talents…
J’ai de la chance, j’ai passé pas mal d’entretiens au début de la pandémie et pas depuis, je n’ai donc pas connu ça. Mais la plupart des entretiens techniques en ssii à l’ancienne, fallait aussi d’autres compétences que pour développer. Je me souviens que la plupart du temps, on me filait une feuille de questions (parfois des QCM) auxquelles il fallait répondre. Sauf que c’était juste hyper théorique, il fallait se souvenir par coeur de certaines particularités de frameworks, le genre de truc que tu n’utilises quasiment jamais (voire pas du tout, genre en quelle année est sortie telle version, WTF ?!) quand tu bosses avec le framework et que tu n’apprends pas par coeur. Ça pouvait sûrement passer pour un jeune sortant de l’école, mais quand tu bosses c’est pas des trucs que tu retiens.
Vu que c’étaient des SSII et que ça me donnait une idée assez claire du niveau technique de la boîte (le pire : en 2016, on me demande la version de java, et la 8 n’est même pas sur les réponses proposées, le test n’avait jamais été revu depuis sa création !), j’ai pas cherché à développer mes connaissances de ce type. Je préférais largement les tests techniques qui me demandaient de coder, au moins c’était plus en lien avec mon taf. Mais je suis presque toujours tombé sur des trucs que je trouvais faciles et sans piège, ça aidait. Il paraît pourtant que c’était fréquent de voir le candidat échouer à ces tests, donc c’était utile pour écrémer les vrais branques.
J’ai du passer des tests techniques sur ces plateformes pour un poste chez un client (je suis en ssii). Ça m’a fortement déprimé et mis en doute mes compétences.
Tout ça pour une mission tout à fait classique en Angular. Les boites doivent vraiment se calmer, avoir confiance dans le CV de ses devs et connaitre un minimum les différentes technos
Je pense que la conséquence que les boîtes vont se manger, ça va être clair. Soit la boîte est très attractive, et alors ok. Soit la boîte ne l’est pas, et les développeurs corrects qui se présentent vont être refoulés. Ceux qui vont rester, c’est ceux qui ont potassé ces connaissances spécifiques parce qu’ils sont trop mauvais pour être dans une bonne boîte mais qu’ils ont bien compris le système – et des devs corrects qui ont potassé pour une boîte attractive mais n’ont pas réussi le test pour cette boîte attractive.
Si la boite est pas ultra attrative elle n’aura personne en étant exigeante. Les moyens ou mauvais n’auront pas le niveau. Les bon ne viendront jamais ou ne resteront pas plus de quelques mois (soit perte d’argent plus qu’autre chose).
C’est la limite du modèle dont on vous parle ici. y’ plus de demande (hors covid) que d’offre niveau dev. Donc oui l’élite s’amuse sur des conneries. Car là y’a bien 10 dev intéréssés pour 1 poste. Mais pour le poste tout venant quoi qu’on me dise ici, on est sur 10 dev pour 11 ou 12 postes. Donc tout le monde fini par trouver. Hors covid on est à 2-3% de chomage chez les ingénieurs, pas 25% ! Et dans les 2-3% ca inclue plein de gens qui retrouvent en quelques mois voire qui ont démissionné, ça inclue aussi les psychopathe, les gens incapable d’arriver à l’heure ou de se laver le matin…
Oui, c’est effectivement en lien avec le marché de l’emploi. Le développeur correct pour le job ne va pas potasser pour réussir ces tests pour une boîte pas particulièrement attractive. Il se fait refouler et n’en a rien à faire car il peut trouver aussi bien voire mieux sans ces tests à la con.
Maintenant, pour ce qui est des dev médiocres, ils peuvent toujours avoir le niveau pour les tests des boîtes moyennes qui tentent d’imiter les grandes, avec un peu d’entraînement bien ciblé. Ce n’est pas parce que tu es un mauvais professionnel que tu es un mauvais passeur de test ! D’autant plus que ces tests te demandent des connaissances très théoriques qu’il suffit de bien apprendre, et qu’on te demande rien sur le langage que tu vas utiliser concrètement. Ça ne m’étonnerait pas que beaucoup de champions de ces tests se révèlent à la fin être de gros branques une fois en poste. Je parle en particulier des tests passés par des boîtes extérieures à la tienne.
Si la corpo « tech » avait une once de déontologie elle obligerait les responsables recruteurs à passer les tests qu’ils imposent aux autres en toute transparence et dans les mêmes conditions et ne les soumettre aux candidats que s’ils sont bons à 10%.
* à 100%
… quand même …
Actuellement en recherche d’un nouveau job, la plupart des boite me demande de passer des tests ( et aussi à remplir des dossiers technique mais ça c’est une autre histoire). Des tests qui prennent plus d’une heure et 1 entreprise me demande de passer un test de 4h…
C’est complétement ridicule d’envoyer ce genre de tests robotique a un Senior . Franchement après 13 ans dans ce métier j’ai l’impression de revenir a l’école. Totalement dégouté.
Je commence a sérieusement a songer un changement de métier.
Car avec l’Age , ca va pas le faire ces tests avec compte a rebours etc…
Ca n’a rien a avoir avec la réalité!
Dernièrement j’ai eu le droit à ce genre de tests pour une mission (je suis en ssii) je suis tombé de haut c’est que du bachottage. En plus le temps limité pour les réaliser c’est très stressant. Je pense qu’avec un peu d’entrainement tu peux passer tous ces tests haut la main et être une brêle en poste
Je suis tombé récemment sur des tests techniques style coding game en postulant pour une boîte. Malgré mes trois ans d’expérience, le truc m’a complètement ridiculisé : c’est atrocement scolaire et démoralisant. Le fait que la pratique devienne populaire est d’autant plus inquiétante pour mes projets de changement de boîte.
Merci pour la recommandation du livre ceci dit.
Pareil, j’ai postulé pour une ESN qui m’a fait faire un test sur CodingGame, j’ai vraiment eu l’impression de m’être fait humilié. Les conséquences mentales et psychologiques sont bien nombreuses. (coucou syndrome de l’imposteur…)
Il y a ceux qui se sont spécialisés dans l’aide à la préparation des tests, et d’autres comme passtest.fr qui se sont spécialisés dans le service pour sauter purement et simplement les tests automatisés !