[Test de développement] FizzBuzz, le test de la mort

[Allwise]

C'est le deuxième qui est faux, y avait une inversion dans le FizzBuzz :
http://fizzbuzz.pastebin.com/EQdtaDuM
J'ai pas dit qu'elle était en une ligne, mais en deux instructions. Je te ferai pas l'affront de te dire que c'est différent :d
J'ai pas cherché à faire un code clair et intelligible, mais le truc le plus court possible, juste pour voir si j'étais capable de trouver une alternative à la solution qui m'était venue naturellement, et pour proposer un truc qui change. Je suis d'accord avec toi, niveau lisibilité ça pue

[srm]

Justement elle n'est pas en deux instructions.

[NicoMSEvent]

J'affectionne ma manière

http://fizzbuzz.pastebin.com/AyejhNtF

[Roworll]

Outre le fait de réussir/louper le test (pondre un code fonctionnel en moins de 10 mn), je pense que l'une des observations intéressantes que l'on peut faire sur ce genre d'exercice concerne les restrictions ou les objectifs que s'imposent les développeurs.

Autant certains vont s'attacher simplement au problème, autant d'autres vont se torturer pour trouver une manière "rapide", élégante" ou "optimisée" de le traiter, avec un impact direct sur ainsi le risque d'erreur et/ou la lisibilité/qualité du code.

On est clairement dans le cas de cette observation

After a fair bit of trial and error I've discovered that people who struggle to code don't just struggle on big problems, or even smallish problems (i.e. write a implementation of a linked list). They struggle with tiny problems.

Relisez l'énoncé du problème. On demande juste un code fonctionnel, pas le plus optimisé ni le plus performant. Juste du fonctionnel. Passer plus de 30 secondes à analyser ce qui est demandé et comment en faire quelque chose de somptueux est en soit un mauvais départ.

Du coup, je me demande dans quelle mesure on peut considérer que ceux qui ont souhaité sortir du lot en présentant une solution "évoluée" ont échoués dans le test, cette recherche de performance ou d'élégance ayant rallongé les délais de la programmation.

[Sephi-Chan]

C'est vrai que ce n'est pas très efficace de chercher des solutions tordues alors qu'une approche naïve est terriblement lisible tout en restant efficace.

[pastebin]YWZQCKVz[/pastebin]

Vive la simplicité !


Sephi-Chan

[Plume]

Il faut quand même considérer si malgré une démarche initiale erronée, le test est réalisé dans les temps impartis. Dans ce cas le test reste réussi.

[Sephi-Chan]

Le critère de réussite dépend uniquement de ce qu'attend l'employeur.
Pour moi, un monoligne ou autre code imbouffable est un échec. La lisibilité prime sur le reste.


Sephi-Chan

[Roworll]

Il faut quand même considérer si malgré une démarche initiale erronée, le test est réalisé dans les temps impartis. Dans ce cas le test reste réussi.

Disons que ça dépends surtout du recruteur.
Cherche-t-il :
- Quelqu'un qui va droit au but ?
- Un coupeur de cheveux en quatre ?
- Un optimiseur fou ?

Si on part du principe que la seule limite est le temps, effectivement, peu importe le chemin, l'essentiel est d'arriver. Mais pour ma part, si je devais endosser le rôle de l'examinateur, d'autres critères rentreraient en ligne de compte
- le temps passé à développer le programme
- les méthodes utilisées
- la clarté du code

Chacun de ces critères peut avoir un poids différent en fonction des affinités de chacun. Personnellement, j'attendrais un code efficace et simple plutôt qu'un truc alambiqué et tout candidat tentant de proposer une recherche expérimentale de la solution verrait ses chances diminuées.

Encore une fois, le postulat à la base est simple et c'est le programmeur qui s'impose de se surpasser au risque d'échouer. Est-ce acceptable pour le recrutement d'un futur collaborateur ?

[Plume]

Quand tu maitrises une technologie, je ne suis pas sûr qu'on puisse toujours parler de risques. Après, c'est au programmeur de connaitre ses capacités et d'agit en conséquence.

[Roworll]

Quand tu maitrises une technologie, je ne suis pas sûr qu'on puisse toujours parler de risques. Après, c'est au programmeur de connaitre ses capacités et d'agit en conséquence.

C'est justement là le problème. Un type qui maîtrise la technique et qui se maîtrise lui même sera bien plus fiable qu'un autre qui ne fait que maîtriser le langage sans connaître ses propres limites.

Je serai d'ailleurs curieux de savoir combien ont tenté, lors de leur toute première approche, de faire par pur défi le code le plus compact, le plus minimaliste ou le plus imaginatif sur le test du FizzBuzz.