comment-detecter-un-bon-developpeur-en-moins-de-15-minutes-kaam-and-roffler

How to spot a good developer in less than 15 minutes

Gabriel Kaam

Gabriel Kaam

September 22, 2026

27 comments

Table of contents

UPDATE: this article was written in 2017 (ca date). In 2022, things have changed a bit at KNR. I invite you to listen to this podcast where I talk in detail about our new recruitment processes. Come on, kisses.

Hello you,

Whether you’re a CTO, a project manager or just in charge of recruiting developers for your tech team, you’re often faced with this question:

How can you quickly determine whether a developer is a good fit for your team?

After working as a trainer for Octo Technology, CTO for the startup Modalova and finally CEO of my own agency KNR Paris, I’ve had the opportunity to interview a large number of developers from all backgrounds. Some were graduates of prestigious schools, others self-taught; some were young, others older; men and women.

Over the course of these interviews, I came to realize that some candidates with “perfect” CVs didn’t actually know how to code; they had some knowledge of the subject, but I didn’t see them as real developers. So I set up a “roadmap” for conducting my technical interviews, a checklist of things I needed to check during the interview before considering integrating a profile into my team.

This roadmap enables me to eliminate on average 80% of candidates who, despite having a very good CV on paper, don’t have the necessary skills to join my teams.

But Gabriel,” you might ask, “how is your roadmap going to help me conduct MY own interviews? Maybe I don’t have the same expectations of my developers as you do!”

Well, reader, you’re absolutely right. That’s why in this article I’m only going to talk about the technical aspects that enable me to separate the good developers from the not-so-good (not to say bad) ones. Developers, who for me are not yet developers. Developers who, in my opinion, won’t be able to produce quality code that can be used in production without the supervision of another, more experienced developer. Let’s just say that developers, whom I consider to be “less good”, will find it difficult to be autonomous, to make proposals and to produce bug-free code.

Ok, let’s get into it!

The famous Fizzbuzz test

The Fizzbuzz test is a relatively well-known test for developers. Simply knowing that this test exists is proof of a certain level of computer literacy; but not knowing about it isn’t necessarily prohibitive. For example: I didn’t know him when I joined Octo Technology.

The statement of the Fizzbuzz test is quite simple: the developer is asked to write a code (I usually leave the choice of language to the candidate) to solve the following problem:

Let’s take a list of numbers; let’s keep it simple, let’s take positive integers between 1 and 1000 (here we’ll keep it simple so that the candidate doesn’t waste time thinking about the type of variable to use if he decides to take the test with a strongly typed language, such as C). For each number n in the list, we want to perform the following operations:

  • if the number is divisible by 3: Fizz is displayed
  • if the number is divisible by 5: Buzz is displayed
  • if the number is divisible by 3 and 5: Fizzbuzz is displayed (hence the name of the test)
  • otherwise: the number n

And that’s all there is to it; the test looks simple enough, and indeed it is. But I found (to my horror) that around 70% of the candidates I interviewed were unable to pass this simple test. Some were even in engineering school, practically graduated, with 5 years of “web development” on their CVs; but couldn’t pass this simple test. It makes you wonder what they learn at school…

giphy.gif


The first step is to see if they can pass the test. A good developer should be able to produce drinkable code in 5 or even 10 minutes, may encounter a bug when testing his code with the number 15 (divisible by 3 and 5), but should find the solution in less than 5 minutes.

Now, if the person doesn’t pass the test, they’re disqualified as far as I’m concerned. I think this kind of problem should be child’s play for a developer who offers to develop for you, carry out your project or join your tech team. Admittedly, the stress of the interview can also work to the candidate’s disadvantage, causing them to lose their nerve: that’s why it’s important to reassure them: this test is simple, there are no traps, the aim of the game is to keep things as simple as possible. Under these conditions, if your candidate needs 30 minutes to come up with an acceptable code, it’s NOGO for me.

1 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! Congratulations, your dev has passed the Fizzbuzz test, so he knows how to program.

The idea now is to try and estimate its sensitivity to the beauty of clean, uncluttered code that respects the rules of single-responsibility. To put it simply, in the code example proposed above, all the logic in our code was in the fizzbuzz function. Now, in computing, we like to cut up a program so that each piece of code has a unique role (the principle of single-responsibility). As you explain this principle to your developer, ask him if he can see a way to improve his code to make it more readable, while respecting this principle.

Here, we try to see how the developer responds when asked to “improve” his code. Many developers will confuse code improvement with code optimization. When we talk about optimization, we’re talking about increasing the performance of a code; for example, making it faster and less resource-hungry. It’s all very well knowing how to optimize code, but I think that with the machines we have today, saving a few milliseconds on the execution of a simple program is less important than it used to be.

But I digress! So we ask our developer to improve his code. By improve, I mean make it more beautiful, more readable, more Charlie-able, more likely to be taken over by another developer without them thinking WTF when they read the lines of code, easier to debug and above all easier to modify. That’s what I call good code, beautiful code.

So ask your developer to improve his code; if he starts talking about optimization to make the algorithm faster, just tell him that’s not what he’s being asked to do; we’re just looking to make the code more beautiful.

Here, I generally expect the candidate to output the logical part of the code used to determine whether a number X is divisible by a number Y. This would make the code more DRY ( Don’t Repeat Yourself ) ; and also improve its readability. We’ll also pay attention to how it names its variables and functions. Code with variables named a, b, c, x, y is synonymous with a developer who has never really worked in a team.

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

Read between the lines (of code)

And there you have it, the few lines of code that allow a developer to prove to me that he can actually code. But is that enough to set them apart from the other candidates? Well, no…

A good developer is also (and above all) a developer who masters his tool.

I usually ask candidates to bring their computer to the interview, so that they can use the tool they should be comfortable with. During the fizzbuzz test, I’m going to observe how they use the said tool; use of an IDE, use of keyboard shortcuts; do they use their mouse/touchpad too often ( spoiler alert: this is a bad sign ); do they type quickly on the keyboard, with two hands; using several fingers. In principle, this gives me a fairly general idea of the candidate’s ease of use of the tool, which often goes hand in hand with his or her skill level.

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

So that’s it; am I hired?

Not yet, young padawan. This article deals only with the technical side of interviewing. I’ve already turned down candidates who had passed the Fizzbuzz test with flying colors. See you in a future article where I’ll explain how we recruit at KNR and why technical skills alone are not enough to make a good candidate.

Don’t forget to subscribe to our newsletter to be notified when the article is released!

Are you a CTO, project manager or even a developer looking for a job? Tell me what you thought of my roadmap in the comments below!

Thomas Dupont

9/14/2017, 09:17 AM

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

Gabriel Kaam

9/15/2017, 11:29 AM

Héhé, oui c'est voulu, c'était pour voir si tu suivais ... Non, c'est effectivement une faute de typo de ma part ;) C'est corrigé now !

Dylan

10/5/2017, 08:27 PM

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

Gabriel Kaam

10/5/2017, 08:31 PM

Difficile et triste, ça en dit long sur la qualité de l'enseignement en France. Bravo à toi si tu as réussi le test :) et n'oublie pas que nous recrutons toujours ;)

charles dacquay

10/6/2017, 04:14 PM

Hello! 70% ne savent pas faire ce test. Incroyable!

giraud

10/8/2017, 10:30 AM

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 ^^ ?

Lydie Danjean

3/6/2018, 03:06 PM

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"

Thomas Pericoi K&R

3/7/2018, 09:33 AM

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

Yannick

3/10/2018, 02:33 PM

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.

Developpeur web Paris

6/18/2018, 04:41 PM

Super Article ! Vraiment très instructif... :)

BACHA

2/10/2019, 11:29 PM

Un bon développeur est d'abord un craftman.

Fred

3/8/2019, 01:17 PM

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.

cecil

3/11/2019, 10:45 PM

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.

Gabriel Kaam

3/13/2019, 11:15 PM

É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

Gabriel Kaam

3/13/2019, 11:19 PM

https://giphy.com/embed/eBpiVHAzU8XXtvPCae

yoan

3/19/2019, 10:21 AM

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.

Gabriel Kaam

3/19/2019, 11:47 AM

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.

Sanchez

5/28/2019, 01:47 PM

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.

Max

6/10/2019, 07:47 PM

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 ?

Cédric

10/5/2019, 11:25 AM

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

Jon

1/15/2020, 03:29 PM

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.

Andriana

9/3/2020, 07:21 PM

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!

Author-ité XD

9/15/2020, 04:45 AM

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 ;-)

1

9/22/2020, 04:36 PM

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

gui

9/14/2021, 08:15 PM

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

jo

12/19/2021, 10:19 AM

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.

Gabriel Kaam

12/28/2021, 09:11 PM

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.

Leave a Reply

Your email address will not be published.

Collaboration

A project?
Let's talk about it.

Contact us

Our team of experts is ready to listen to you. Let’s meet and discuss your project together!

LOADING