Programmation compétitive, le paradoxe de la tech

Programmation compétitive, le paradoxe de la tech

La programmation compétitive prend de l’ampleur. Chaque année, toujours plus de concours et de nouvelles plateformes d’entrainement. Comme une pandémie qui n’en finit pas, toujours plus complexe avec toujours plus de monde concerné. Mais pourquoi un tel engouement ? Et surtout, c’est nécessaire dans ton cas ?



T’es classé combien ?

De façon générale, la plupart des métiers sont très compétitifs. Que ce soit en interne, au sein des membres d’une équipe, ou en externe, justement pour y rentrer. Personne n’y échappe vraiment.

Mais chez les développeurs, cette compétition est exacerbée.

La programmation compétitive est un “sport de l’esprit” pratiqué par des centaines -voir des milliers- de développeurs simultanément. Tous les participants, via internet ou en local, reçoivent les mêmes problèmes à résoudre.

Le plus rapide est le seul gagnant.





Les problèmes en question sont des casse-têtes sous forme de puzzle de logique et/ou de mathématique.

Point important : les compétiteurs ne sont pas jugés sur la qualité ou la réutilisabilité du code. Ce qui compte, c’est la vitesse de résolution du problème et la complexité de la solution en temps et espace.

D’abord, je veux te montrer concrètement à quoi ça ressemble.

Je te présente William Lin. Un jeune étudiant de 18 ans déjà très connu dans le milieu compétitif. Voici une vidéo de lui gagnant une compétition en ligne de Google “Google Kickstart”.

Cette vidéo est absolument HALLUCINANTE.





Déjà, parlons de la vitesse à laquelle juste il comprend les problèmes. C’est limite pas normale ce qui se passe. J’ai failli tomber de ma chaise. Je crois que même si je connaissais les problèmes à l’avance, je serais moins rapide.

Je l’accuse sérieusement d’être un extraterrestre qui nous ressemble à la Men In Black.

Mais le plus impressionnant c’est la vitesse à laquelle il résout le problème. Voici une autre vidéo où la même personne fait un duel avec un autre développeur. La vidéo dure pas longtemps.

Mais comment William a fait pour atteindre un tel niveau ? Il a fait comme tous les autres participants. Il s’est entrainé sur les plateformes.



Automatisation

La programmation compétitive prend de l’ampleur en même temps que le nombre de plateformes dédié aux préparations de ces compétitions. Si tu n’en as jamais utilisé, crois-moi ça va arriver. Petit à petit, tout le monde finit par être forcé de participer.





Je t’en parlais déjà dans l’article sur les entretiens techniques, car les deux sont très liés. Aujourd’hui, des plateformes entières sont dédiées à entrainer, tester et classer les développeurs entre eux.

Voici une liste incomplète :

Je te parie qu’en cherchant un peu plus, tu en trouves une dizaine d’autres.

Détail important : certaines de ces plateformes sont utilisées par les entreprises pour tester les développeurs pendant un entretien. Les boites peuvent automatiquement te mettre dans un classement. Tu finis dans un tableau Excel par rapport à ton score.

Une vraie compétition en ligne, mais pour obtenir un travail.



Pourquoi un tel engouement ?

À la base, la programmation compétitive ne concernait que les passionnés d’algorithme. Ces gens sont toujours là. Ils ont toujours autant de fun et ils ont bien raison. Mais ils ne sont pas responsables de l’explosion du nombre des plateformes et des compétitions.

L’engouement vient des changements dans le marché du travail des développeurs.

Le marché du travail des développeurs est devenu extrêmement élitiste. Le métier se complexifie de plus en plus. La compétition suit.

Il y a une pénurie de développeurs expérimentés pendant que personne n’engage de jeunes développeurs.

Le fait de pouvoir mettre en compétition et classer les candidats sur internet est très pratique pour les entreprises. Tu ne t’es pas entrainé sur les plateformes de programmation compétitive ? Tu seras trié en bas du classement.





Dans ces conditions, des armées entières de développeurs foncent sur ces plateformes et participent à des compétitions.

Dans le passé, seuls les géants de la tech (GAFAM) avaient cette politique élitiste autour du recrutement et des entretiens techniques. Désormais, le phénomène se démocratise.

Et la raison derrière tout ça est très logique finalement. Tester les développeurs est une tâche complexe. Ces plateformes résolvent ce problème. Une manière en ligne, automatique, générique, rapide, et pratique de tester sur de la logique pure.

Et plus le métier se complexifie, plus les entreprises sont élitistes, plus la compétition fait rage, plus la programmation compétitive prend de l’ampleur.

OK, donc ça veut dire qu’il faut que tu te jettes dessus au plus vite ?



Urgence

La réponse dépend de ta situation et de tes objectifs.

Pour certains d’entre vous : c’est indispensable.
Pour d’autres : c’est inutile.

Ça serait malhonnête de ma part de donner la même réponse à tout le monde.

J’ai été relativement négatif avec la programmation compétitive jusqu’ici donc commençons par lister les avantages.



  • Fun

Il y a un fun inexplicable à tomber sur un problème, galérer dessus, et finir par le résoudre avec du code. Cette légère euphorie à comprendre et résoudre le mystère.

C’est d’autant plus vrai quand tu commences à bien prendre l’habitude de la logique de ces exercices. Quand tu commences à toucher ta bille en algorithme et que tu vois déjà les patterns en lisant les énoncés des problèmes.

Ceux qui étaient là avant l’engouement le savent bien et ne sont là que pour le fun.





  • Amélioration de la logique algorithmique

À la base de notre métier se trouvent les algorithmes et la logique pour les mettre en place.

Si tu sens que tu es limite là-dessus, alors il faut la travailler. Ça concerne beaucoup les jeunes développeurs par encore habitués à cette gymnastique du cerveau bien particulière. Mais ça concerne aussi les plus expérimentés d’entre nous.

Personnellement, si demain je passe un entretien, tu peux être sur que je vais passer du temps sur les plateformes.



  • Préparation aux entretiens techniques

Beaucoup d’entretiens techniques ressemblent comme deux gouts d’eau à de la programmation compétitive.

C’est la raison principale de l’engouement autour de tout ça. Ça concerne les jeunes autant que les plus expérimentés. Développeur est l’un des seuls métiers ou même avec 20 ans d’expérience, on te fera passer un test poussé.

C’est ridicule, mais c’est la réalité.



Si tes objectifs court ou moyen terme sont fortement liés à tout ça, alors oui, je te conseille de te mettre à la programmation compétitive.



Comment ?

Le comment est relativement simple.

Direction ces fameuses plateformes de programmation compétitive. La plupart sont gratuites. Mes préférés sont LeetCoode, HackerRank et CodinGame. Choisis celle que tu préfères, on s’en fout en vrai.

Arrivé dessus, lance-toi dans l’exercice le plus facile, puis monte crescendo à ton rythme sans forcer.

Ça va être très dur au début. Ça fait un choc à beaucoup de monde.





Pour pallier au choc et à l’abandon certains qui en découlent, t’es obligé de te préparer avant.

Je te conseille fortement la bible incontestée des entretiens techniques : Cracking the coding interview.

D’abord parce que c’est tout le package au même endroit. De la base de l’algorithmie et des structures de données en passant par la complexité temps/espace, jusqu’aux algorithmes obscurs et les algorithmes de tris et parcours. Pas besoin, d’aller de ressource en ressource et de perdre un temps fou. Tu as tout, au même endroit, à portée de main.

Mais aussi et surtout pour la façon d’expliquer de l’auteur Gayle L. McDowell. Elle a une capacité à simplifier les concepts compliqués qui rend tout plus simple. Et ça, c’est inestimable chez un formateur quand tu débutes.

Maintenant, si tu te reconnais dans aucun des objectifs cités plus haut, alors je vais être honnête, je ne vois aucun intérêt à la programmation compétitive.



Tech Paradox

Tu te rappelles de notre ami William Lin ?

C’est un étudiant qui n’a jamais eu un poste de développeur professionnel. C’est une pointure de la programmation compétitive. Je pense que même en bossant très dur je ne pourrais pas rivaliser avec lui en logique pure.

Je ne veux même pas me comparer à son niveau, ça serait ridicule.

Mais sorti du cadre de la programmation compétitive, William galère pour développer des applications réelles.





Comment peut-il dominer de la difficulté extrême à une vitesse inhumaine et galérer autant à faire une page en React ?

C’est bien tout le paradoxe de la programmation compétitive. C’est obligatoire pour être embauché. Mais tu n’en as pas -ou très peu- besoin dans un réel travail de développeur.





Tu vas me dire que c’est normal de galérer en découvrant un framework Javascript et t’as raison.

J’ai un autre exemple.

Il y a bien longtemps, dans une galaxie lointaine, très lointaine, je bossais sur un projet avec un développeur très talentueux. C’est de loin le développeur le plus talentueux avec qui j’ai jamais travaillé.

Il était responsable de beaucoup de systèmes et il était extrêmement compétent dans son domaine. Je ne sais pas combien il était payé, mais il a été retenu plusieurs fois par l’entreprise via des augmentations.

Bref, le dev que tu veux dans ton équipe.





Ce développeur m’a dit qu’il était incapable de retourner une linked list et que surtout il ne voyait pas l’intérêt de toutes ces plateformes. Il ne comprenait pas pourquoi on testait pas les nouvelles recrues sur des problèmes réels de tous les jours. Que tous ces puzzles n’avaient rien à voir avec ce qu’il faisait tous les jours.

Beaucoup de développeurs en poste ne passeraient pas l’entretien technique de leur propre entreprise.

Et ces mêmes développeurs sont ultras compétents et performants à leur poste.

Comment je pourrais te dire que la programmation compétitive est absolument nécessaire pour tout le monde quand ce cas de figure est tant répondu ?



Épilogue

La programmation compétitive est pour moi le plus grand paradoxe dans notre métier. Indispensable, sauf si tu n’en as pas besoin. Ta décision de t’y lancer ou non devrait être prise selon tes objectifs. Au début, ton classement devrait moins t’intéresser que la gymnastique intellectuelle que ça t’apportera. C’est seulement avec cette gymnastique que ton classement finira par grimper.

Qui me parle ?

jesuisundev
Je suis un dev. En ce moment, je suis développeur backend senior / DevOps à Montréal pour un géant du jeux vidéo. Le dev est l'une de mes passions et j'écris comme je parle. Je continue à te parler quotidiennement sur mon Twitter. Tu peux m'insulter à cet e-mail ou le faire directement dans les commentaires juste en dessous. Y'a même une newsletter !

Pour me soutenir, la boutique officielle est disponible ! Sinon désactiver le bloqueur de pub et/ou utiliser les liens affiliés dans les articles, ça m'aide aussi.

17 commentaires sur “Programmation compétitive, le paradoxe de la tech”

  1. C’est juste ridicule. La prog competitive en elle-même, pourquoi pas après tout ? Le principal souci réside dans le fait que les entreprises mettent en place ce genre de tests sans prendre la peine de se demander si c’est réellement pertinent. La réponse est, comme tu le développe dans ma dernière partie de ton article, Non. Évidemment que non. C’est juste de la feneantise pour moi. C’est bien pratique car la plupart des gens a cette vision complètement tordue et biaisée du dev : un geek à lunettes, fort en maths (et pas en pommes) et en logique pur. Pour eux, c’est ça la programmation. Tout simplement parce qu’ils n’ont pas pris 5 minutes pour se renseigner sur le sujet. Bref perso cette pratique me gonfle.

  2. En tant que vieux de la vieille : premier poste dev en 1989 ! Je te rejoins tellement !
    Pendant ma formation et dans mes premiers postes, on adorait se défier entre collègues avec des “problèmes” posés tous les mois dans la revue l’Ordinateur individuel, ça allait du problème à résoudre en 3 lignes de code ou 200 octets au “Pour une longue soirée d’hiver” : que du bonheur ! La satisfaction intellectuelle était là, l’émulation aussi, c’était un jeu !
    Puis lors d’un entretien d’embauche en 2008 (déjà!), je me suis fait allumer au debriefing : “J’ai apprécié nos échanges et votre approche blablabla, c’est dommage pour quelqu’un se présentant expert avec 20 ans d’expérience d’être recaler sur un algorithme de tri !” J’ai répondu simplement : “Je n’ai pas postulé pour un poste d’enseignant, je ne vois pas en quoi la maitrise “par coeur” du tri à bulles est un avantage pour ce poste ! Utilisez votre algorithme pour trier les autres candidats, moi, je me suis trompé sur le poste, je retire ma candidature.” Je me suis levé et suis parti.
    C’est tellement facile de mettre les gens dans des cases !
    Quelque temps plus tard, un autre m’a dit : “On va maintenant faire une mise en situation : voilà notre problème, vous avez 10 minutes nous présenter comment vous y prenez !” là, j’ai pu démontrer mes compétences et j’ai été embauché !
    Je ne suis pas un prof, je ne suis pas une bête à concours, je suis un dev 😉

  3. Même souci dans certaines boites : les tests sont faits par des gens brillants, très brillants (trop ?), mais pas des devs de métier.

    Résultat : certes, le test met la barre haute, mais est-il vraiment indispensable d’être capable de résoudre un problème mathématique d’ensembles ou de donner son avis sur je-ne-sais-quelle-conjecture ou problème à la con… si derrière, les bases des devs ne sont pas là => genre améliorer une codebase, la refacto, etc.

    Pire, si la boite a trop de gens câblés comme ça, la dette technique due à de la sur ou sous-ingénierie fera très mal au derche. Et les fondamentaux seront pas là : automatisation, tests, etc.

  4. Voilà, ça a été bien dit.

    Rares sont les entreprises qui ont réllemment besoin de développer une solution à un problème logique dans un temps imparti très réduit (dizaines de minutes).
    Et d’ailleurs, j’aimerais bien savoir si une telle entreprise existe — a part d’éventuelles equipes de “gamers” professionnels spécialisés dans ce genre de compétition, je ne vois pas.

    En réalité, les systèmes qu’on nous demande de créer doivent souvent durer une (des ?) dizaine(s) d’années, et par des équipes renouvelées régulièrement. Donc être maintenables, testables, robustes, évolutifs, de qualité, etc.
    Et on a le temps de les mettre en place, en tout cas plus de temps que les 30minutes imparties pour un exercice de code.

    On m’a une fois demandé de passer un test technique sur ces plateformes. J’ai voulu tenter le coup, et j’ai commencé à m’entrainer sur coding game.
    J’ai vite laché l’affaire quand j’ai compris que ça ne menerait à rien, que ça ne correspondait pas à ce que je pouvait apporter en entreprise, et que ce n’est pas le genre de travail que je recherche.

    J’espère que les entreprises sauront rester raisonnables et ne tomberont pas dans le piège d’exiger ces tests à chaque recrutement. J’en entends trop se plaindre de ne pas arriver à recruter de “bons développeurs”, ça n’arrangera pas leurs affaires.

    1. Ces tests sont présent aussi pour les juniors, mais le niveau est adapté.
      En s’entrainant seulement sur les questions très facile et facile des plateformes, tu t’en sors très bien.
      En tous cas mieux que la plupart des gens !

  5. Je trouve que le dev compétitif c’est exactement la même chose que les tests de “logique”. Avant d’en faire tu à l’impression d’être une sous merde , tout le monde est trop fort et toi tu arrive à rien. Et puis, une fois que t’en a bouffé assez , tu rends compte que c’est toujours la même “logique” ou les même problèmes qui sont tournés d’une manière différente.
    La vraie compétition est donc dans la vitesse de compréhension de l’énoncé et la vitesse de frappe (j’exagère à peine).

    Après ca reste des petits exos d’algorithmie sympa et en faire un peu en période de recherche d’emploi peux éviter de se faire sniper sur une question à la con.

    1. J’imagine que c’est pour ça qu’il donne l’impression de comprendre l’énoncé à une vitesse surhumaine. Quand t’en as fait 10000 qui se ressemblent tous, ça va forcément beaucoup plus vite.

  6. J’ai vite fait regarder la vidéo. Ça pue les nombres magiques, des noms de variables à gerber, un namespace std qui finira par créer des conflits tôt ou tard. Même cet E.T. dans 2 ans, il reprend son code, il fait un AVC.

    1. En fait le gars c’est un compilateur.
      On lui donne en entrée des instructions, il pond en sortie un code imbitable mais qui marche sur le moment dans le contexte donné.

      Et à la modif suivante, il faudra tout recompiler/recommencer.

  7. Je trouve ton article très pertinent et surtout bien équilibré sur cette question.
    D’un point de vue purement pragmatique, ces tests comme méthodes d’embauche sont pour la plus part des postes de développeurs (ou autres) de vastes blagues (sauf évidement pour les cas où l’algorithmie pure serait au cœur du poste). Ça arrange surtout les recruteurs qui peuvent par ce biais mettre des scores sur leurs candidats ; le syndrome du classement Excel en somme.
    Je trouve ça très dommageable pour la profession et ça donne une image encore plus détestable des recrutements déjà que cette dernière était bien entachée !
    Enfin, je pense que ça doit être un levier pour parfois limiter la rémunération des futurs employés : “On va vous prendre mais au vu de vos résultats aux test, nous estimons votre rémunération à xxxxx k€”.
    Bienvenue dans le nouveau monde, Prost !

    1. Honnêtement, les meilleurs entretiens dont j’ai souvenir, ce sont ceux où il y a au moins un développeur de l’équipe qui recrute et où l’échange se fait sur le(s) projet(s) de l’équipe et où le but du recruteur est de voir si les propositions de solutions du candidat sont pertinentes. C’est nettement plus intéressant que de rajouter un memoize sur un appel récursif ou savoir ce que retourne : int a=5; ++a += a++ + ++a; Sur cette dernière, le gars qui me code qqch comme ça passe par la fenêtre.

  8. J’ai vécu ça lors de l’embauche de mon job actuel, entretien technique poussé, je ne m’étais pas préparé à l’avance, résultat des course 6/40 au test. Malgré cela, et surtout grâce à mes anciens référents, j’obtiens quand même le poste. Après 1 an dans l’entreprise, je passe second du lead tech et je suis en charge d’une petite équipe.

  9. En fait le problème vient plutôt des RH qui utilisent les tests avec une idée biaisée du métier (Le mythe moderne du super Hacker)
    De là, la question que je me pose : mais qui fait passer des tests au RH ?
    Il y a peut être une idée à creuser, faire un site pour mettre les RH en compétition entre eux 🙂

T'en penses quoi ?

Your email address will not be published. Required fields are marked *