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

UPDATE: cet article a été rédigé en 2017 (ca date). En 2022 les choses ont un peu évoluées chez KNR, je t’invite à écouter ce podcast où je parle en détail de nos nouveaux process de recrutement. Allez, bisous.

Hello toi,

Que tu sois CTO, porteur de projet ou juste en charge du recrutement des développeurs de ton équipe tech, tu es souvent confronté à cette question :

Comment déterminer rapidement si un développeur est un bon fit pour ton équipe ?

Après avoir été formateur pour la SSII Octo Technology, CTO pour la startup Modalova et enfin CEO de ma propre agence KNR Paris; j’ai eu l’occasion de faire passer un grand nombre d’entretiens à des développeurs venant de tout background. Certains sortant de grandes écoles, certains autodidactes ; certains étaient jeunes, d’autres plus âgés ; des hommes et des femmes.

Au fil de ces entretiens, j’ai pu me rendre compte que certains candidats au CV « parfait » ne savait en réalité par vraiment coder ; ils avaient quelques connaissances en la matière, mais n’étaient pas pour moi de vrais développeurs. J’ai donc mis en place une « roadmap » pour mener mes entretiens techniques, une liste à cocher de choses qu’il me fallait vérifier durant l’entretien avant d’envisager d’intégrer un profil à mon équipe.

Cette roadmap me permet d’éliminer en moyenne 80% des candidats, qui malgré un très bon CV sur papier, n’ont pas les compétences nécessaires pour rejoindre mes équipes.

« Mais Gabriel, me diras-tu, en quoi ta roadmap va-t-elle m’aider à mener MES entretiens à moi ? Je n’ai peut-être pas les même attentes que toi concernant mes développeurs ! »

Et bien, lecteur, je te répondrai que tu as tout à fait raison. C’est pourquoi dans cet article je ne parlerai que des aspects techniques qui me permettent de séparer les bons développeurs des moins bons ( pour ne pas dire mauvais ). Des développeurs, qui pour moi n’en sont pas encore. Des développeurs qui ne seront, à mon sens, pas capable de produire un code de qualité, pouvant être utilisé en production sans la supervision d’un autre développeur plus expérimenté. Disons que les développeurs, que je considère comme « moins bons », auront des difficultés à être autonome, force de propositions et à produire un code sans bug.

Ok, let’s get into in !

Le fameux test Fizzbuzz

Le test Fizzbuzz est un test relativement connu par les développeurs. La simple connaissance de l’existence de ce test témoigne d’une certaine culture en informatique ; mais le fait de ne pas le connaitre n’est pas forcément rédhibitoire. Par exemple: je ne le connaissais pas lorsque j’ai intégré Octo Technology.

L’énoncé du test Fizzbuzz est assez simple : il est demandé au développeur d’écrire un code ( je laisse en général le choix du language au candidat ) pour résoudre le problème suivant :

Soit une liste de nombres ; restons simples, prenons des nombres entiers, positifs, compris entre 1 et 1000 (ici on reste simple pour pas que le candidat perde son temps à réfléchir au type de variable à utiliser s’il décide de passer le test avec un language fortement typé, style C).
Pour chaque nombre n de liste, on veut effectuer les opérations suivantes:

  • si le nombre est divisible par 3 : on affiche Fizz
  • si le nombre est divisible par 5 : on affiche Buzz
  • si le nombre est divisible par 3 et par 5 : on affiche Fizzbuzz ( d’où le nom du test )
  • sinon : on affiche le nombre n

Et voila, c’est tout ; le test à l’air simple comme ça, et d’ailleurs il l’est. Mais j’ai constaté ( avec un certain effroi ) qu’environ 70% des candidats que je recevais en entretien n’étaient pas capables de passer ce simple test. Certains étaient même en école d’ingénieur, pratiquement diplômés, avec 5 années de « développement web » sur leur CV ; mais ne pouvaient pas passer ce simple test. On en arrive à se demander ce qu’ils apprennent à l’école…

repérer un bon développeur moins 15 minutes - nono - kaam and roffler

La première étape est de voir s’ils arrivent à passer le test, un bon développeur devrait vous sortir un code potable en 5, voire 10 minutes, pourrait rencontrer un bug en testant son code avec le nombre 15 ( divisible par 3 et par 5 ) ; mais devrait trouver la solution en moins de 5 minutes.

Maintenant, si la personne ne réussit pas le test ; elle est disqualifiée pour moi. Je pense que ce genre de problème devrait être un jeu d’enfant pour un développeur qui se propose de développer pour vous, de réaliser votre projet ou d’intégrer votre équipe tech. On admettra que le stress de l’entretien peut également jouer en sa défaveur et faire perdre au candidat ses moyens: c’est pourquoi il est important de bien le rassurer : ce test est simple, il n’y a pas de piège, le but du jeu est d’aller au plus simple. Dans ces conditions, si votre candidat a besoin de 30 minutes pour sortir un code potable, c’est NOGO pour moi.

function fizzbuzz($liste) {
  foreach($liste as $n) {
    if($n%3 == 0 && $n%5 == 0) echo 'fizzbuzz';
    elseif($n%3 == 0) echo 'fizz';
    elseif($n%5 == 0) echo 'buzz';
    else echo $n;
    echo "\n";
  }
}
fizzbuzz([1, 2, 3, 4, 5, 7, 15, 20]);

Now you have my attention

OK ! Félicitations, votre dev a réussi le test Fizzbuzz ; il sait donc programmer.

L’idée maintenant est d’essayer d’estimer sa sensibilité à la beauté d’un code clean, épuré et respectant les règles de single-responsability.
Pour faire simple, dans l’exemple de code proposé plus haut, la totalité de la logique de notre code se trouvait dans la fonction fizzbuzz. Or en informatique, on aime bien découper un programme, de manière à ce que chaque bout de code ait un rôle unique ( principe de single-responsability ). En expliquant ce principe à votre développeur, demandez-lui s’il voit un moyen d’améliorer son code pour le rendre plus lisible, en respectant ce principe.

Ici, on essaie de voir comment le développeur répond quand on lui demande « d’améliorer » son code.
Beaucoup de développeurs vont confondre améliorer et optimiser le code. Quand on parle d’optimisation, on parle d’augmenter les performances d’un code ; par exemple le rendre plus rapide, moins gourmand en ressource. C’est très bien de savoir optimiser un code, mais je pense qu’avec les machines que nous avons aujourd’hui ; gagner quelques millisecondes sur l’execution d’un simple programme a moins d’importance qu’auparavant.

Mais je m’égare ! Donc on demande à notre développeur d’améliorer son code. Par améliorer, j’entends le rendre plus beau, plus lisible, plus Charlie, plus apte à être repris par un autre développeur sans qu’ils se disent WTF en lisant les lignes de code, plus faciles à débugger et surtout plus facile à modifier. C’est que j’appelle un bon code, un beau code.

Demandez donc à votre développeur d’améliorer son code ; s’il commence à vous parler d’optimisation pour rendre l’algorithme plus rapide, dites lui simplement que ce n’est pas ce qui lui est demandé ; on cherche seulement à rendre le code plus beau.

Ici, je m’attends en général à ce que le candidat, sorte la partie logique du code qui sert à déterminer si un nombre X est divisible par un nombre Y. Cela permettrait de rendre le code plus DRY ( Don’t Repeat Yourself ) ; et également d’améliorer sa lisibilité. On fera également attention à la façon dont il nomme ses variables et ses fonctions. Un code avec des variables nommées a, b, c, x, y est synonyme d’un développeur qui n’a jamais vraiment travaillé en équipe.

function est_divisible($nombre, $diviseur) {
  return (0 === $nombre % $diviseur);
}

Read between the lines (of code)

Et voilà, on a donc les quelques lignes de codes qui permettent à un développeur de me prouver qu’il sait effectivement coder. Mais est-ce que cela suffit pour se démarquer des autres candidats ? Well, no…

Un bon développeur : c’est aussi (et surtout) un développeur qui maitrise son outil.

En général je demande aux candidats d’amener leur ordinateur en entretien ; ainsi ils peuvent utiliser l’outil sur lequel ils devraient en principe être à l’aise. Durant le test fizzbuzz ; je vais observer la manière dont ils se servent dudit outil ; utilisation d’un IDE, utilisation de raccourci clavier ; est-ce qu’ils utilisent trop souvent leur souris/touchpad ( spoiler alert : c’est mauvais signe ) ; est-ce qu’ils tapent vite au clavier, à deux mains ; en utilisant plusieurs doigts. Ça me donne en principe une idée assez globale de la facilité qu’a le candidat à utiliser son outil ; cela va souvent de pair avec son niveau de compétence.

Un bon développeur maitrise son outil - kaam and roffler

So that’s it ; am I hired?

Not yet, young padawan. Cette article ne traite que de la partie technique des entretiens. J’ai déjà refusé des candidats qui avaient pourtant passé haut-la-main le test Fizzbuzz. Je te donne rendez-vous dans un prochain article où j’explique comment nous recrutons chez KNR et pourquoi des compétences techniques on point ne suffisent pas à faire un bon candidat.

N’oublie pas de t’abonner à la newsletter pour être mis au courant lors de la sortie de l’article !

Es-tu un CTO, porteur de projet, ou même développeur à la recherche d’un poste ? Dis-moi ce que tu as pensé de ma roadmap dans les commentaires ci-dessous !

Gabriel Kaam
Gabriel Kaam
https://knr.paris/

27 commentaires

  • Bonjour,

    Il n’y aurait pas une erreur dans votre premier Embed?
    Si on applique l’énoncé, la réponse serait plutôt:

    
    function fizzbuzz($liste) {
    	foreach($liste as $n) {
    		if($n%3 === 0 && $n%5 === 0) echo 'fizzbuzz';
    		elseif($n%3 === 0) echo 'fizz';
    		elseif($n%5 === 0) echo 'buzz';
    		else echo $n;
    		echo "\n";
    	}
    }
    fizzbuzz([1, 2, 3, 4, 5, 7, 15, 20]);

    Après c’est peut-être voulu…

  • Sympa comme article ! Ça me rassure d’avoir réussi à le réaliser ce test en quelques minutes ! Difficile à croire que quelqu’un ayant réalisé plusieurs années d’études de dev ne sache pas faire ça…

  • Interessant comme point de vue meme si je trouve le test assez simple mais du coup perturbant lors d’un entretien ^^. Je suis pas specialement d’accord avec le touchpad par exemple. J’utilise souvent de nouveaux IDE car j’aime tester plusieurs choses meme si oui j’utilise souvent les raccourcis claviers. Bref sinon article sympa et plutot bon dans l’ensemble je trouve bon courage. Vous prenez pas de remote ^^ ?

  • Bonjour, merci de votre article, je suis développeuse web débutante en recherche d’emploi et vos conseils sont très utiles. J’ai connu le test FizzBuzz sur OpenClassRoom. Ils le font passer comme évaluation d’un de leurs cours sur Javascript. Néanmoins, je me permets d’attirer votre attention sur le manque de relecture de votre article. Il reste pas mal de fautes, j’ai copié quelques passages ci-dessous, il doit en avoir d’autres que je n’ai pas vu. Pour moi c’est aussi rédhibitoire qu’un développeur ne réussissant pas le test FizzBuzz 😉

    « certains étaient jeunes, d’autres plus âgées »
    « single-responsabiliy »
    « ce que chaque bout de code ait sa role unique ( principe de single-responsabiliy ) »
    « demandez-lui s’il voit un moyen d’améliorer son pour le rendre plus lisible »
    « et pourquoi des compétences techniques on point ne suffise pas »

    1. Hello, merci de ton retour !
      J’ai normalement tout corrigé.
      C’est tout Gabriel ça de donner des leçons sans les respecter 😉.

  • Un bon programmeur n’est pas celui qui tape a 300 a l heure mais celui qui code juste (sans bugs, sans memory leak, dead lock, etc….). J ai vu bien trop de gens coder avec tous leurs doigts des choses simples qui ont des bugs alors que mes deux doigts codent moins vites mais bien plus surement.

  • Quand on recrute un développeur c’est pour qu’il s’adapte à l’équipe et utiliser les outils qu’ on a déjà à disposition. La démarche de filtrage par les test de type fizzbuzz est intéressante mais on fait cela de manière automatique avec des outils comme testcandidat.com ce qui évite de perdre du temps sur des candidats trop loin des attentes.

    1. Évidemment d’accord avec toi Fred . Depuis l’écriture de cette article nous avons mis en place des outils de test technique à distance pour « filtrer » les candidats en amont . Mais rien ne remplace une rencontre face-à-face 😉 un développeur est une personne avant tout

  • Je suis tombé sur cette article un peu par hasard, et je dois dire que je suis désagreablement surpris par cet article revelateur d’une mentalité typiquement française où, on voit les gens comme des machines et pas comme des talents.
    En plus, je trouve que c’est d’une malhonnetete intellectuelle incroyable de croire que les dev ne vont pas sur stackoverflow, ne vont pas se documenter quand ils ont besoin de faire une fonction meme hyper simple des fois….jetez moi la 1ere pierre.

    En 8 ans de dev en amerique du nord, jamais j’ai du sentir que je devais quemander pour un emploi, qu’on me fasse faire des tests digne du cm2 (ha oui j’ai 20/20 maitre?!! c’est bon ca va je tape vite? j’ai bien appris ma lecon?), la France a des années lumières a rattraper sur l’amérique a ce niveau la, c’est pitoyable ces méthodes d’un autre âge..

    Un conseil, réecrivez cet article de toute urgence (sur un ton moins hautain si c’est encore possible), ou supprimez le et revoyez vos méthodes de recrutement (j’imagine meme de management).
    Moi, en tant dev je vois ça, la dernière chose que je veux faire c’est postuler, en attendant j’espère que vous l’avez trouvé votre mouton a 5pattes que vous paierez une misère.

  • Désolé, je suis dev débutant, je pense que même sur ce bout de code vous vous compliquez…
    Ne serais-ce pas mieux comme ça niveau amélioration?

    function fizzbuzz($liste) {
    	foreach($liste as $n) {	
    		$word = ""
    		if($n%3 === 0) $word .='fizz';
    		if($n%5 === 0) $word .='buzz';
    		if( $word == "") $word = n;			
    		echo $word . "\n";		
    	}
    }

    ainsi on évite les else inutiles.

    1. Hello Yoan,

      Merci pour ton commentaire 😉

      La vérité est qu’il n’y a pas de bon, ou de mauvais réponse à cet exercice, moi, si je devais résumer ma vie aujourd’hui avec vous, je dirais que c’est d’abord des rencontres.

      Je n’ai pas testé ton code, mais j’imagine qu’il fonctionne (en dehors des petites fautes de syntaxe). Ce qui m’intéresse par contre, c’est par exemple, le fait que tu qualifies les else « d’inutiles« . Cette phrase m’en apprends beaucoup plus sur toi, que le fait que tu aies réussi à produire un code qui fonctionne .

      Je ne suis pas pointilleux à ce point lors d’un entretien pour un dev Web, mais on pourrait argumenter que les else ne sont pas inutiles, car ils me font économiser entre 0 et 2 instructions à chaque itération de ma boucle. Sans compter la mémoire vive nécessaire à ton code pour stocker la variable $word…

      Attention, ce ne sont pas nécessairement de mauvaises choses. Ce qui m’importe c’est que les choix que va prendre un développeur, soient des choix conscients. Selon le contexte, il est normal et même judicieux de faire des compromis, l’important c’est que le développeur soit conscient de ces compromis.

      C’est la raison pour laquelle je donne un exercice plutôt « simple » lors de ces entretiens, car la réussite seule de l’exercice est une chose, mais je vais également prendre en compte tout ce qui vient « autour » de la capacité du développeur à simplement « pisser du code ».

      C’est dans cet « autour » que je vais pouvoir différencier un bon développeur, d’un très bon développeur par exemple.

  • 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.

    1. 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 ?

  • 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…

  • 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.

  • 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!

  • 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 😉

  • ç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)

  • 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

    1. 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.

      1. 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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *