squale92Le 13/10/2014 à 19:50
En lisant les autres posts, maintenant :
Ah, je n'ai pas forcément répondu à tout -- j'ai un peu hésité sur la dernière question, en me demandant quel header Location serait finalement renvoyé au navigateur, vu qu'il n'y a pas de exit/die après chaque ^^
Je suis assez d'accord : tu as là des questions qui permettent de voir si le gars en face de toi a quelques notions. Mais pas de juger d'un niveau autre que "en a déjà vu un peu" (certes, tu peux avoir besoin de ce niveau de filtre, mais la partie intéressante de l'entretien ne sera clairement pas ce questionnaire -- ah, aussi : si tu le fais passer par écrit, c'est vraiment pas sympa pour le candidat : c'est le genre de trucs qui passe bien mieux dans une conversation que sur papier où ça fait "froid" comme ambiance. Enfin, perso, une boite qui me fait passer un entretien de ce type sur papier tout seul dans une salle, je vais vraiment pas avoir envie de bosser pour eux...).
Le :: tu connais le message d'erreur dès que tu as fait du PHP pendant quelques jours, à mes yeux : ça fait partie de la culture générale du langage (et savoir expliquer d'où vient le nom est un bon point : pareil, culture générale)
la rapidité, c'est bien dans certains cas, mais clairement pas pour un stockage de mots de passe. Au contraire, il est intéressant d'utiliser une fonction volontairement lente, pour luter contre le brute-force (j'ai déjà eu à l'expliquer à des mecs ayant plusieurs années d'XP -- ça peut être sympa pour ton candidat que tu lui expliques, aussi, s'il partait sur md5 pour sa rapidité)
C'est pas facile de faire passer des entretiens techniques et de juger quelqu'un en une demi-heure à une heure, t'inquiète pas
Avant que je fasse passer mon tout premier entretien il y a des années, mon manager m'a dit que la question qu'il me poserait à la fin serait "est-ce que tu veux bosser avec lui ?" -- finalement, le niveau technique n'est qu'un point parmi d'autres (et tu peux être mieux placé qu'un RH pour juger l'aspect "humain" d'un développeur, aussi)
Aergh, même pas vu ces trucs là
C'est carrément pas le genre d'erreur que je vois dans du code autour de moi : du code comme ça ne compile même pas (donc aucune chance que les tests passent et que ça soit commité)... Et même avant ça, c'est souligné en rouge dans l'IDE, donc ça a peu de chance d'arriver jusqu'à l'étape F5 du développement ^^
(sans compter que mélanger à ce point syntaxe traditionnelle et syntaxe alternative, je n'ai jamais vu ça)
A faire en live avec la personne (sur papier ou sur tableau), pour voir sa façon de raisonner, qui est souvent plus importante que le code final !
Pour finir, comme dit par d'autres : ce test me semble plus orienté "piège à débutants" que "on cherche un développeur cakephp".
Tu peux aussi, dans la conversation (qui est LE truc important d'un entretien à mes yeux -- mes deux dernières boites, je suis allé les voir en entretien seulement après avoir vu plusieurs fois mes futurs collègues autour d'un verre, hors-boulot, sans même savoir que j'allais bosser avec eux un jour), parler plus librement. J'aime bien parler de veille, en entretiens : voir un peu si c'est juste un boulot pour le candidat, ou s'il est vraiment intéressé par ce qu'il fait.
Ah, je n'ai pas forcément répondu à tout -- j'ai un peu hésité sur la dernière question, en me demandant quel header Location serait finalement renvoyé au navigateur, vu qu'il n'y a pas de exit/die après chaque ^^
squalyl (./2) :
je ne vois aucune question liée à ce que tu cherches vraiment, c'est à dire des gens compétents sur des frameworks. Pose des questions compliquées, là tu ne testes rien.
Je suis assez d'accord : tu as là des questions qui permettent de voir si le gars en face de toi a quelques notions. Mais pas de juger d'un niveau autre que "en a déjà vu un peu" (certes, tu peux avoir besoin de ce niveau de filtre, mais la partie intéressante de l'entretien ne sera clairement pas ce questionnaire -- ah, aussi : si tu le fais passer par écrit, c'est vraiment pas sympa pour le candidat : c'est le genre de trucs qui passe bien mieux dans une conversation que sur papier où ça fait "froid" comme ambiance. Enfin, perso, une boite qui me fait passer un entretien de ce type sur papier tout seul dans une salle, je vais vraiment pas avoir envie de bosser pour eux...).
Meowcate (./3) :
Pour infos, je suis tombé sur ce terme en cherchant des questions possibles d'entretien, quelqu'un a proposé cela en guise de "blague". Du coup je l'ai reprise, pour me demander comment les candidats vont réagir, et ceux qui répondent ont de bonnes chances d'avoir cherché sur leur smartphone. Certains de ceux que j'ai déjà vu ont simplement laissé la question vide, j'en ai un qui a au moins tenté "C'est une variable globale ou une constante" du fait qu'elle est écrite en majuscule conformément à la convention PHP, ce à quoi il a mérité d'avoir une "bonne réponse".
Le :: tu connais le message d'erreur dès que tu as fait du PHP pendant quelques jours, à mes yeux : ça fait partie de la culture générale du langage (et savoir expliquer d'où vient le nom est un bon point : pareil, culture générale)
Meowcate (./7) :
Je considère md5 comme la plus mauvaise réponse possible à mon sens, l'un d'eux l'a choisi en argumentant sur la rapidité des différents algorithmes. D'autres ont mis md5 sans réfléchir. Il y en a un qui a songé à sa réponse plutôt que par automatisme. C'est justement ce genre de comportement que je cherche à faire sortir par mon test.
la rapidité, c'est bien dans certains cas, mais clairement pas pour un stockage de mots de passe. Au contraire, il est intéressant d'utiliser une fonction volontairement lente, pour luter contre le brute-force (j'ai déjà eu à l'expliquer à des mecs ayant plusieurs années d'XP -- ça peut être sympa pour ton candidat que tu lui expliques, aussi, s'il partait sur md5 pour sa rapidité)
Meowcate (./7) :
Après, je suis codeur, pas DRH. J'ai cherché pas mal d'exemples de codes et de questions de recruteurs pour savoir ce que je voulais chercher, je suis peut-être totalement à côté.
C'est pas facile de faire passer des entretiens techniques et de juger quelqu'un en une demi-heure à une heure, t'inquiète pas
Avant que je fasse passer mon tout premier entretien il y a des années, mon manager m'a dit que la question qu'il me poserait à la fin serait "est-ce que tu veux bosser avec lui ?" -- finalement, le niveau technique n'est qu'un point parmi d'autres (et tu peux être mieux placé qu'un RH pour juger l'aspect "humain" d'un développeur, aussi)
Meowcate (./10) :
Godzil : dans l'idée, la 7 c'était une typo, la 11 c'était une erreur d'avoir soit fait un : au lieu de {, soit } au lieu de endif (puisque "endswitch" n'existe pas). Malgré cela, certains ont vu cette erreur en 11 mais pas en 7.
Aergh, même pas vu ces trucs là
C'est carrément pas le genre d'erreur que je vois dans du code autour de moi : du code comme ça ne compile même pas (donc aucune chance que les tests passent et que ça soit commité)... Et même avant ça, c'est souligné en rouge dans l'IDE, donc ça a peu de chance d'arriver jusqu'à l'étape F5 du développement ^^
(sans compter que mélanger à ce point syntaxe traditionnelle et syntaxe alternative, je n'ai jamais vu ça)
Zerosquare (./14) :
Je suis d'accord que pénaliser quelqu'un pour un caractère oublié est contreproductif. Par contre, un test de code, même basique, permet d'éliminer les beaux parleurs qui sont infoutus de coder concrètement. Et apparemment, il y en a un paquet !Un exemple "célèbre" que tu connais peut-être déjà : Fizzbuzz
A faire en live avec la personne (sur papier ou sur tableau), pour voir sa façon de raisonner, qui est souvent plus importante que le code final !
Pour finir, comme dit par d'autres : ce test me semble plus orienté "piège à débutants" que "on cherche un développeur cakephp".
Tu peux aussi, dans la conversation (qui est LE truc important d'un entretien à mes yeux -- mes deux dernières boites, je suis allé les voir en entretien seulement après avoir vu plusieurs fois mes futurs collègues autour d'un verre, hors-boulot, sans même savoir que j'allais bosser avec eux un jour), parler plus librement
. J'aime bien parler de veille, en entretiens : voir un peu si c'est juste un boulot pour le candidat, ou s'il est vraiment intéressé par ce qu'il fait.