Commentaires sur : Comment Repérer Un Bon Développeur En Moins De 15 minutes

Par : Gabriel Kaam

Gabriel Kaam — Tue, 28 Dec 2021 21:11:27 +0000

En réponse à jo.

Hello @JO,

Très bonne remarque par rapport au coeur de métier.
Ce n’est pas précisé dans l’article, mais ce genre de test est bien entendu réservé au dev back ou full stack, je n’attends pas qu’un dev Front ait forcément des notions d’algo.

Ça pourrait être interessant de rédiger une Part II à cette article qui pourrait se focus sur nos entretiens pour les dev Front, à voir.

Pour répondre au feedback de Guy dans le même temps, je précise que de ne pas être en mesure de résoudre le problème « du premier coup » n’est pas du tout un facteur de disqualification!

Au contraire! qu’un dev me dise en entretien « tiens, j’ai oublié comment on se sert du modulo, je peux google vite fait? », je prends ça comme un point Positif.

Personnellement ca m’arrive d’oublier une syntaxe aussi simple qu’un foreach ou switch-case à force de swichter d’un language à un autre, ou tout simplement après quelques semaines passées sans coder.

Le but de ce genre d’exercice n’est pas de tester la capacité d’un dev à régurgiter un code appris par coeur, mais d’entamer une discussion autour d’un problème et voir comment le dev se comporte devant celui-ci.

Par : jo

jo — Sun, 19 Dec 2021 10:19:32 +0000

En réponse à gui.

Je ne comprends pas comment est ce qu’on peut proposer cette vision à des développeurs front end lors des tests.
Et aujourd’hui c’est le cas.

20 ans de développement de site front, de design digital et 10 de back, je suis loin d’être le meilleur en programmation pure mais mon expérience est bien réelle.

Aujourd’hui avec ce simple test provenant des milieux issus d’apprentissage de développement pur, je me retrouve disqualifié face à des débutants sortants de leurs études.

Ou plutôt est-ce le test qui n’est pas du tout en rapport avec mon métier ?
D’ailleurs, est-ce un test de connaître par coeur une réponse pour l’avoir déjà rencontré ?
Tu le dis toi même : qu’est ce qu’ils apprennent pendant leurs études…
Connaitre une solution pour l’avoir apprise ou rencontré, ça s’appelle : par coeur. C’est loin de pouvoir t’apprendre si le codeur est bon.
Tu sais simplement qu’il l’a rencontré et qu’il connait le modulo.
Faire des énormes erreur de code, de simple html/css/js juste pour un formulaire comme sur ce site, ça, ça choque.

Par : gui

gui — Tue, 14 Sep 2021 20:15:47 +0000

Si 70% des candidats échouent au fizz buzz, c’est peut être le test qui est le problème, pas le candidat ?
Demandez leur pourquoi ils ont raté plutôt que de les évincer directement

il y a des développeurs qui ont utilisé l’opérateur % en 2021 ?
Il y en a qui s’en s’ont rappelé l’existence avec ce test ? (moi)

Ce test en carton sert juste à savoir si vous savez ce que signifie a%b==0

Par : 1

Tue, 22 Sep 2020 16:36:39 +0000

ça serait bien que les recruteurs comprennent aussi qu’un développeur qui va dans une boîte : rend service à l’entreprise.

Une entreprise seule ne peut pas gagner d’argent, un développeur seul *peut* gagner de l’argent, il n’a pas besoin de l’entreprise pour ça

Donc aux recruteurs de montrer un peu de tolérance vis à vis des développeurs, car sans eux, pas de site, pas d’app, pas de visibilité numérique.

Donc pas d’argent ? (ou beaucoup moins)

Par : Author-ité XD

Author-ité XD — Tue, 15 Sep 2020 04:45:30 +0000

Hello,
Premier point, personnellement, je trouve le code de ton fizzbuzz très peu lisible, l’indentation du code et la séparation en blocs distincts est un critère de qualité !!

Pas d’accord non plus de manière générale sur la frappe rapide au clavier, ça ne veut ABSOLUMENT rien dire, je prend un exemple: Je me suis blessé à la main, j’écris donc moins vite qu’un autre sur mon portable, mais une fois sur mon clavier ergonomique, je suis beaucoup plus à l’aise, tu vois les gens se balader avec leur clavier ergonomique dans la sacoche du portable ??? Raison pour laquelle ce point ne peut juger de la qualité d’un développeur.

L’utilisation des raccourcis clavier n’est pas non plus un bon critère, il faut plutôt considérer la manière générale dont l’IDE est utilisé: Est ce que le développeur trouve l’outil rapidement ? Certains devs de longue date n’aiment pas les raccourcis clavier, ça n’en fait pas moins de mauvais développeurs

Sinon, bon article en général, félicitations 😉

Par : Andriana

Andriana — Thu, 03 Sep 2020 19:21:27 +0000

Hello à tous,
J’aimerais aborder un sujet qui revient tous le temps en ce moment, celui du « test technique » lors des processus de recrutement.
Franchement, je trouve que c’est une grosse arnaque pour les candidats mais aussi une énorme perte de temps.
En effet ces tests sont, soi-disant, juste là pour évaluer votre niveau technique mais pas pour vous recaler, hypocrisie à 100%, ratez-le et vous allez voir qu’il n’y aura plus de suite entre vous et le gars qui essaye de vous recruter.
Hormis cela, ces tests sont longs à réaliser, ils demandent entre10min et peuvent aller jusqu’à un semaine pour les entreprises qui sont « super » inspirés. Alors déjà, ce temps perdu est compté sur VOTRE temps pas le leur, et c’est du pur travail bénévole.
Je ne sais pas vous, mais moi j’estime que tout travail mérite salaire, hors pour ce genre de « test technique », il n’y a aucune rémunération derrière. Pourtant, dans plusieurs cas, on vous demande de réaliser des modules, composants et autres et tout cela selon des caractères bien spécifiques.
Et le pire c’est que même si vous faites exactement ce qu’on vous a demandé et que vous réussissez le test, on vous renvoie un petit retour qui dit: Merci de votre participation mais les résultats ne sont pas à ce à quoi on s’y attendait. Et après si vous insistez un peu, on va vouloir chercher la petite bête genre, le header n’est pas conforme à la spec, vous utilisez du code qui n’est pas permis par W3C, un autre candidat réponds mieux à nos attentes ….
Sérieux??? Et vous qui critiquez, peux-t’on jeter un coup d’oeil à votre code? Ou à la journée quotidienne de vos devs ?
L’une des raisons qui me pousse à dire aussi que les tests ne servent à rien, c’est que SELON la loi, vous disposez d’une période d’essai allant de 3 à 6 mois ou l’entreprise peux décider de vous faire partir du jour au lendemain sans avoir forcément de raison valable (un retard répété, quelques déjeuners manqué avec le boss, vos horaires un peu « hors norme » …, bref des choses qui n’ont rien à voir avec votre boulot au quotidien) si l’envie lui chante.
Alors pourquoi nous bassiner avec ces histoires de test?
Il n’existe pas de dev (ou rare) qui maîtrise parfaitement Symfony:Laravel/Magento, React/Vue/Angular et Foundation/Bootstrap/Tailwind avec un peu d’Ops Linux config Webpack/Grunt et qui excel à 95% dans toutes ces technos….
Ce dev n’existe pas, et aussi personne n’as encore inventé une sorte d’intelligence artificielle ou robot qui arrive à maitriser toutes ces technos à la fois. Ceci est bien sur un exemple.

Mais pour les recruteurs, j’ai l’impression qu’ils font le max pour trouver ce genre de candidat qui ….. n’existe pas.

Pourquoi ne pas se fier tout simplement à la réalité, SÉPARER les rôles!!!! comme c’était le cas il y a quelques années! Oui mais ça couterait cher aux entreprises disent t’ils, c’est pour ça qu’on aimerait avoir un dev qui maîtrise « un peu tout. Et moi je dirai, même si il y a un dev qui peux réaliser tout ça, aura t’il le temps de réaliser votre projet à lui tout seul?
Il est temps que les entreprises redescendent un peu sur terre car NOUS les devs on est là et ILS ont besoin de nous comme NOUS on à besoin d’eux.
Alors un peu de tolérance ne ferait pas tant de mal et arrêtons de nous mettre des bâtons dans les roues avec ces histoires de tests car, au final, nous voulons tous la même chose, faire avancer notre société mieux que la concurrence n’est-ce-pas ?
Merci de m’avoir lu jusqu’ici en tout cas. Peace!

Par : Jon

Jon — Wed, 15 Jan 2020 15:29:14 +0000

Ce que tu dis à propos de la diversité etc est très juste. Sauf que si t’es pas capable de passer ce test, tu vas rien compléter du tout. Si ce test te fais peur, je pense que tu sur estimes tes compétences. Un bon programmeur écrit des centaines de lignes de codes. Doit organiser beaucoup d’objets différents. Penser à toutes les exceptions, gérer un maximum d’erreurs etc. Avec la force de l’habitude ça devient facile. Mais pour un débutant, ça peut sembler énorme. Et une fonction comme celle là ne doit pas prendre plus de 2 minutes à être écrite. Si la traduction dans ton esprit n’est pas instantanée alors c’est évident que tu es débutant.

Ceci étant dit, j’ai appris en autodidacte également, alors je te félicites et t’encourages. Mais si je me bases sur tes dires, tu es encore un bon débutant en programmation.

Par : Cédric

Cédric — Sat, 05 Oct 2019 11:25:40 +0000

Je suis tombé sur cette page en cherchant les techniques de recrutement utilisées sur google car j’aimerais beaucoup en faire mon métier en reconversion. Je dois avouer être surpris, je suis 100% autodidacte et je n’ai pas acquis la théorie que vous tous développeur pro avez suite à vos études…Je pense que je n’aurai pas développé ce test aussi simplement et sans doute pas en 10 minutes, pourtant dans le domaine ou je pratique par passion, le dev 3d c++ je pense ne pas être un mauvais élément et je pense que je pourrais apporter beaucoup au sein d’une équipe de devs.
Certains sont bon en anglais, d’autres en algorithme, d’autres en cryptographie et la liste est longue… Le rôle d’une équipe n’est il pas de se compléter ?
J’espère arriver à trouver un job dans ce domaine avec mes lacunes que je comblerais au fil des années par l’expérience, mais à lire ce type d’article ça fait vraiment peur…

Par : Max

Max — Mon, 10 Jun 2019 19:47:37 +0000

En réponse à Sanchez. Oui, mais si maintenant, tu décides que fizz n'est pas du à un module de a vers b , mais par une division ? Et que dans 3 semaines, que buzz est obtenu via une API ?

Par : Sanchez

Sanchez — Tue, 28 May 2019 13:47:53 +0000

Bonjour, article intéressant car il raconte bien le recrutement tel qu’il se passe en France (j’ai envie de dire malheureusement pour la France). J’avais fait fizzbuzz à l’école et pourtant je me suis retrouvé à flipper pendant le test pensant que j’avais oublié un piège.
Sinon la remarque sur la beauté du code est pertinente, mais comme toujours la notion de beauté est très subjective. On défini en général du code élégant comme du code pensé pour sa maintenabilité à long terme. Et d’accord le rendre plus lisible en remplaçant du code par du texte fait partie des stratégies qui le rendent plus maintenable.Mais concernant l’exemple choisi, je pense que a % b == 0 est universellement reconnu par un dev comme du code permettant de savoir si a est un multiple de b donc l’extraction de ce code vers une méthode est purement esthétique et sans réelle plus-value. D’ailleurs, l’extraction de code dans une autre méthode devrait répondre à des objectifs précis: Par exemple rendre une partie du code réutilisable à plusieurs endroits. Également, c’est très important, limiter le nombre de lignes dans une méthode en remplaçant plusieurs lignes par un appel vers une autre méthode. Quand on dépasse les mille lignes cela commence à devenir urgent pour la lisibilité. Également dans le cas où le code est si incompréhensible qu’il nécessite un commentaire, ce qu’on veut à tout prix éviter.
Par contre extraire une ligne pour la remplacer par une ligne vérifiant qu’un modulo soit nul ne me parait pas particulièrement intéressant et j’espère que vous ne basez pas vos recrutements la dessus.
Personnellement je trouve que séparer la boucle et le traitement dans deux méthodes différentes aurait été plus pertinent.