Les tests Java (or whatever) pendant les entretiens d'embauche, votre opinion ?
Emmanuel Lecharny
il m'est arrivé une fois, il y a 6 ans, qu'un client me fasse passer un
test Java (dont je n'ai pas eu le résultat). cela vous est-il arrivé et
si oui, qu'en avez-vous pensé ?
Par ailleurs, pour ceux qui sont amenés à recruter, cela fait-il partie
de votre attirail de sélectionneur ? (je met de côté la question des
quotas, on n'est pas à la FFF ici ;)
Merci !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
Baptiste MATHUS
Si tu fais pas uniquement des questions piège, et éventuellement ciblées par rapport au poste, ça donne quand même une idée approchante du niveau du postulant.
Baptiste
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !
Jérôme M.
Swing (oui oui, ça existe encore !). Rien de très violent, juste une
petite vérification pour s'assurer que le MVC était bien assimilé.
Je suis mitigé sur l'intérêt de ces tests car je suis moi-même un peu
mal à l'aise et sous pression dans ce genre de situations. Je pense
qu'ils sont surtout intéressants pour valider les connaissances de
base incontournables qui vont éviter de longs soupirs de désolation
lors des revues de code. En gros, pour effectuer un premier écrémage
parmi les prétendants et vérifier que les compétences annoncées dans
le CV ne s'arrêtent pas à l'épellation de l'acronyme concerné.
Par contre, s'ils sont destinés à estimer la productivité sur un
examen d'une heure par exemple, je trouve ça dangereux et c'est
presque la promesse de passer à côté de très bons profils qui
pourraient compenser leur manque de réussite sur cette partie-là par
un sens de la communication plus aiguisé qu'un cador du code qui
galère pour dire bonjour le matin.
Pour la partie recrutement, je laisse ma place mais suis curieux
d'entendre les réponses ;-) !
Jérôme M.
Le 23/05/11, Emmanuel Lecharny<elec...@gmail.com> a écrit :
Nicolas Martignole
Bof pour les tests. Ca sert à lancer une discussion. Si le gars
n'a pas la fibre magique, tu t'en rends compte en lui faisant passer
le test à l'oral, en discutant avec lui.
J'aime pas l'idée de laisser un candidat 20mn tout
seul dans une salle à côté des toilettes et de la cafète où
des salariés (bourrés du midi) rentrent à 15h en essayant
de prendre un café sur une machine en panne (véridique)
Si le gars est venu, autant passer un max de temps avec lui.
Y'a que les mauvaises SSII qui font passer des tests (obsoletes
pour la plus part) sur des PC fatigués, avec une appli web
codée en PHP (vécu)
Idéalement en tant que sénior, si je dois te recruter, je vais
te demander de venir avec un bout de code. Et puis on va lancer
Eclipse (très loin), on va coder, on va essayer de voir
ce que tu as envie de faire... Bref histoire de voir si tu es
un gars cool, avec qui j'aurai envie de passer 8h par jour.
Voila
Nicolas
Nicolas Martignole
http://www.express-board.fr/quiz
Nicolas
Le 23 mai 2011 15:47, Emmanuel Lecharny <elec...@gmail.com> a écrit :
Jérôme M.
Le 23/05/11, Nicolas Martignole<nic...@martignole.net> a écrit :
Pierre-Yves Ricau
Les tests techniques sont un très bon moyen de faire passer des entretiens sans demander leurs avis aux techniques, qui, tout le monde le sait, n'entendent rien aux ressources humaines et ne sauraient évaluer correctement leurs futurs collègues.
Plus sérieusement, je pense qu'effectivement les tests techniques type QCM peuvent permettre de "préfiltrer", mais en ayant une approche différente : demander au candidat de répondre aux QCM directement en ligne, de chez lui. Comme ça personne ne perd son temps. Et s'il a envie de tricher / googler / appel à un ami, grand bien lui fasse. Ce sont aussi des moyens valides de résoudre un problème. De toute façon il y aura d'autres entretien derrière.
Pierre-Yves Ricau
http://about.me/piwai
Julien Vermillard
> Hello,
>
> il m'est arrivé une fois, il y a 6 ans, qu'un client me fasse passer un test
> Java (dont je n'ai pas eu le résultat). cela vous est-il arrivé et si oui,
> qu'en avez-vous pensé ?
>
> Par ailleurs, pour ceux qui sont amenés à recruter, cela fait-il partie de
> votre attirail de sélectionneur ? (je met de côté la question des quotas, on
> n'est pas à la FFF ici ;)
>
> Merci !
>
l'exercice était de faire une petite appli Swing : sur pression d'un
bouton multiplier les valeurs de deux JTextField. J'avais 30min pour
le faire et écrire la doc associée sous Word.
Sur mes tests de recrutement je demande de trier un tableau de String,
ca permet de détecter les imposteurs, par contre c'est plutôt
difficile d'évaluer le niveau en programmation avec juste des tests.
Je préfère les question ouverte et je demande souvent de m'expliquer
certain concepts.
Julien
yannick grenzinger
je dirai Java 6.1.1.345g selon Oracle -500
Perso après avoir fait des dizaines de langages et 10 fois plus de framework ca me gave bien quand on vient t'interroger avec une liste de questions choppées ici : http://www.interview-questions-java.com/ :D
Jeff MAURY
A+
Jeff
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
"Legacy code" often differs from its suggested alternative by actually working and scaling.
- Bjarne Stroustrup
http://www.jeffmaury.com
http://riadiscuss.jeffmaury.com
http://www.twitter.com/jeffmaury
Alain Defrance
Tu n'utiliseras pas Eclipse -500
Emmanuel Lecharny
> Personnellement, je l'ai appliqué mais le but n'était pas de détecter le
> haut du panier mais plutôt de nettoyer le bas.
Google, ça permet aussi de bien filtrer (le haut et le bas). J'ai même
l'impression que ça devient assez systématique, me trompé-je ?
ehsavoie
J'ai subi le test type QCM où le client bloquait car j'avais mal répondu à une question sur les 50.
J'ai créé et fait passer un test de recrutement où le gars devait 'faire' une appli MVC en 20 minutes, l'idée était surtout de discuter ensuite avec lui de ses choix
(frameworks, patterns, etc.) en ayant ainsi créé artificiellement une base d'échange (vu qu'à l'époque il n'avait pas le temps de finir).
----------
Emmanuel Hugonnet
http://www.ehsavoie.com
http://twitter.com/ehsavoie
--
Thibaud Vibes
Personnellement, je l'ai appliqué mais le but n'était pas de détecter le haut du panier mais plutôt de nettoyer le bas.
Une de mes connaissances a fait un recrutement récemment et a proposé 1 test "sur papier" (de son cru) que j'ai trouvé intéressant néanmoins. Il s'agissait essentiellement de lecture de pseudo-code (C'est une petite boite, les candidats ne se bousculaient pas).
A+
Jeff
1 des questions est "Que fait cette fonction". Sur les 5 qu'il a reçu:
- 1 candidat s'est levé et est parti sans rien remplir quelque minute après avoir eu le sujet.
- 1 a été capable de voir que la condition placée au début de la fonction était toujours vraie et faisait toujours sortir le programme sans rien faire. C'est une question piège, c'est vrai mais ça permet de voir si la personne sait lire/debuguer un code sans outil de debuguage. Je trouvais ça intéressant.
- 3 ont donné une explication de ce que faisait la fonction.
Si j'avais à le faire, j'essaierais de fabriquer des tests (toujours sur papier) qui pousse le candidat a faire "des hypothèses" sur la cause probable du problème. Comme je suis un peu souvent déçu par l'attitude "j'ai un pb, je lance en mode débug, et j'appuie sur F6 pour exécuter mon code pas à pas pour le comprendre", j'essaierais donc de sélectionner des candidats qui sont de bons debuggueur et qui abordent le débuguage de manière plus "scientifique" :
observation > hypothèses > vérification/élimination des hypothèses.
=> chaque questions présenterait le problème et le candidat devrait remplir les 3 zones (un peu comme si il déclarait un ticket dans un tracker de bug)
Au final, le fait de trouver la bonne hypothèse m'importerait moins que la réflexion globale.
Sinon, un peu de pair-programming ça pourrait être sympa, en tout cas j'aimerais bien en tant que candidat faire du pair-programming avec un recruteur.
Thibaud
|
||||
Nicolas Delsaux
> Hello,
>
> il m'est arrivé une fois, il y a 6 ans, qu'un client me fasse passer un test
> Java (dont je n'ai pas eu le résultat). cela vous est-il arrivé et si oui,
> qu'en avez-vous pensé ?
Personnellement, ça m'est arrivé une fois dans une SSII de passer un
QCM technique où la moitié des questions étaient obsolètes.
Je l'ai dit au recruteur à la fin du test, et il a fait une drôle de
tête (genre "putain ca fait dix ans qu'on n'a pas changé ce truc-là et
le mec me dit que c'est trop vieux ?!"). Evidement, c'était mauvais
signe. Evidement, je m'en suis rendu compte après en bossant dans la
boîte. Et évidement, j'ai pas traîné là trop longtemps.
>
> Par ailleurs, pour ceux qui sont amenés à recruter, cela fait-il partie de
> votre attirail de sélectionneur ? (je met de côté la question des quotas, on
> n'est pas à la FFF ici ;)
Bon, dans ma boîte actuelle, avec mes 10 ans de Java, je fais figure
de vieux combattant (je sais bien que ça n'est pas vraiment le cas,
vous énervez pas).
Donc, quand je discute avec quelqu'un qui vient coder, j'ai un
document avec un paquet de questions techniques. je le laisse
générallement en prendre connaissance pendant une vingtaine de minutes
(tout seul. dans la salle. à côté des toilettes où je suis en train de
... nan, vous déconnez là).
Il y a des questions comme :
Quelle est la superclasse de toutes les classes Java ? (un mec m'a
déja répondu "je sais pas", donc je la garde)
Pourquoi n'y a-t-il pas d'héritage multiple en Java ?
Quelle collection Java fournit les avantages suivants : temps de
recherche non dépendant de la position de l'élément recherché, tri
permanent des éléments ? (oui, c'est le TreeSet, et souvent, les gens
ne trouvent pas)
C'est quoi la Session dans une servlet ?
A votre avis, qu'est-ce qui rend le code beau ?
Comment vous faites pour vous tenir au courant de l'actualité Java (et
un gros plus à ceux qui écoutent les castcodeurs).
Et ensuite, on en discute.
Ca permet d'abord de voir si le gars est un branquignol, ensuite de
discuter sur certains aspects de "personnalité" du développeur, et
enfin de voir avec quelles parties il est le plus à l'aise.
En fait, je vois plus ça comme un guide de l'entretien pour le
développeur senior qu'à pas envie de s'emmerder à réinventer les
questions, façon les questions à la con de Google, mais pas à la con.
Ah, et le dernier truc, en général, dedans, j'ajoute toujours une
question sur le truc sur lequel je bosse, genre "si t'as la solution à
mon problème, je veux bien que tu me l'expliques".
Quant aux quotas, je dis toujours oui aux duchesses (dans le but
unique d'augmenter la mixité des équipes, hein :-)
--
Nicolas Delsaux
Philippe Charrière
Baptiste MATHUS
On 5/23/11 4:16 PM, Jeff MAURY wrote:Google, ça permet aussi de bien filtrer (le haut et le bas). J'ai même l'impression que ça devient assez systématique, me trompé-je ?
Personnellement, je l'ai appliqué mais le but n'était pas de détecter le
haut du panier mais plutôt de nettoyer le bas.
Je sais pas si c'est systématique. Mais perso, c'est clair que chaque fois que j'entends un nouveau nom (surtout pour un poste technique), je le google dans les 5 secondes. Et c'est ptête idiot, mais si je le trouve nulle part, déjà il part moins bien (dans notre métier, je vois pas comment tu peux bosser sans les forums, les ml, etc. Bon, après, ya les paranos qui utilisent un pseudo bien obscurs, mais j'ai l'impression que c plus rare, et auquel cas on peut en parler à l'entretien si son CV tient la route).
Baptiste
Moandji Ezana
-
De quelle couleur est le logo de SUN Microsystems désormais ?
Rouge +1000
Emmanuel Lecharny
J'espère que mes clients n'utilisent pas google et ne suivent pas cette
ML ;-)
Nicolas Martignole
Bah à part "debout sur la table, je..." que t'as dit une fois...
:-)
Nicolas
Henri Gomez
>
> Bah à part "debout sur la table, je..." que t'as dit une fois...
> :-)
Et quelques etroneries :)
Jean-Baptiste Lemée
1) Les connaissances acquises
2) La capacités à expliquer un problème
3) La maitrise des outils
4) L'intellect
5) La capacité d'apprentissage (la faible résistance aux changements)
1) Trop d'importance est accordée aux connaissances acquises, un candidat nul qui se fait jeter tous les 6 mois, vous bullshitera facilement en entretien (normal, il en passe plus souvent que vous). Plus important que les connaissances c'est le potentiel.
2) En entretien, je ne parcours pas le CV, je demande au candidat de m'expliquer ce dont il est le plus fier dans sa carrière.
3) et 4) Rien de mieux que coder en pair prog sur un vrai projet cela permet de vérifier rapidement que le mec connait quelques raccourcis, sait écrire du code, comprendre un existant et proposer des améliorations. Il faut être là et qu'il explique à voie haute son raisonnement et sa méthode.
5) idéalement on le colle sur une techno qu'il ne maitrise pas, playframework ou Git au hasard pour voir comment il réagit. S'il aime apprendre c'est gagné.
- le "QCM seul dans son coin" est à bannir.
- Ne pas faire écrire de code est très dangereux.
- Il faut mettre à l'aise le candidat en lui expliquant que rien n'est éliminatoire et que ne pas nul n'est censé tout savoir, au contraire, demander lorsqu'on ne sait pas est une bonne pratique.
Enfin, toujours se rappeller que le marché de l'emploi est à 90% formé de mauvais candidats, les bons candidats sont staffés ou trouve du taff sans passer par la case Monster ou Express Board. Il est beaucoup moins risqué de recruter à la sortie des écoles où 80% des sortants sont de futurs développeurs brillants.
Finalement, ne pas oublier d'utiliser la période d'essai, il faut travailler avec le candidat les premiers jours. En quelques jours, on voit tout de suite le potentiel d'une personne. Les commerciaux et RH sont malheureusement les moins bien placés pour faire ça et compte sur la première mission pour avoir le retour du client. Lequel est souvent aveugle, faisant entièrement confiance au commercial pour lui vendre quelqu'un qui répond à son besoin, et qu'il n'imagine pas en période d'essai.., il mets bien souvent plus de 6 mois pour retomber sur terre, et c'est trop tard.
--
Jean-Laurent de Morlhon
Jocelyn
1. Je trouve qu'il manque dans ta liste l'élément le plus important:
la capacité à bien se comporter dans un groupe. Des cadors hyper-
pointus (ou se considérant comme tels) mais complètement asociaux,
j'en ai trop connu... On dira peut-être que ce n'est pas le but de
l'entretien technique, mais je pense que c'est là qu'on peut le mieux
mettre en évidence la personnalité du candidat. Par exemple, est-il
prompt à dire qu'il ne comprend pas la question, ou qu'il a des
difficultés à résoudre le problème ? Va-t-il essayer de poser un écran
de fumée pour masquer le coup, ou bien va-t-il en parler franchement ?
Après un échec, va-t-il retrouver son sang-froid rapidement ou sera-t-
il perturbé jusqu'au bout ?
2. > Il est beaucoup moins risqué de
> développeurs brillants.
volontairement forcé le trait ? Mais que deviennent donc ces
développeurs brillants dont je n'ai pas eu le plaisir d'être entouré ?
Deviennent-ils tous chefs de projet ou commerciaux ? :)
Sinon puisqu'on en est aux expériences personnelles je vais aussi
parler de la mienne, puisque j'ai eu l'occasion de passer beaucoup
d'entretiens techniques (j'ai beaucoup changé de boite, j'espère ne
pas faire partie des 90% de mauvais se trouvant sur le marché du
travail...) et que j'ai aussi fait passer pas mal d'entretiens.
- Pour ce qui est des QCM, j'en ai passé quelques-uns et je pense que
c'est intéressant face à un gros volume de candidatures, donc pour les
postes de débutants. Effectivement çà va permettre d'écarter ceux qui
n'ont rien compris (s'il est bien fait...). Quand on cherche à
recruter quelqu'un d'expérimenté, je ne vois pas bien l'intérêt, à
moins d'en faire un avec des questions bien dures qu'il faudra de
toute façon compléter par un entretien technique approfondi (c'est
redondant à mon avis). Pour ce genre de profil, l'écrémage devrait
pouvoir se faire à la lecture du CV. A tel point que pour mon dernier
job, j'ai tout simplement refusé l'entretien car on voulait me faire
passer le QCM standard de la société avant même l'entretien et
j'estime qu'après plus de 10 ans dans le métier je n'en suis plus là.
- Les questions techniques, moi j'aime bien. On peut facilement les
adapter au niveau du candidat une fois qu'on s'est fait une base de
quelques dizaines de questions de tous niveaux. Comme le dit aussi
Jean-Laurent, j'invite surtout le candidat à m'expliquer son
raisonnement, ce qui permet de cerner rapidement la personnalité.
Evidemment, l'idéal est de pouvoir compléter par du vrai code, mais
pour un profil expérimenté cela demande vraiment du temps et tout le
monde ne peut pas passer une demi-journée avec quelqu'un (perso
c'était plutôt une demi-heure malheureusement...)
FroMage
mais je pense que ça dépend de la personne et du job en question.
Nous par ex on devait embaucher un gars pour bosser sur Play!
Framework en télétravail alors qu´il en avait jamais fait. On a donc
fait un test réalisable en une ou deux heures (je me souviens plus) à
faire à distance de chez lui tranquille dans son environement,
internet (qui reste indispensable, ça me semble pas réaliste de faire
croire qu´on peut bosser sans internet de nos jours donc pourquoi
faire un test sans ?), dans le seul but de savoir si il était capable d
´apréhender un nouvel outil dans un temps similaire à ce qu´on attend
des mecs qui bossent déjà chez nous. Ça nous a aussi permi de voir
comment il a défini ses priorités dans les specs qu´on lui avait
donné, histoire de sortir un truc fonctionel plutôt que complet.
Je pense que c´était un bon test pour ce cas précis, en tout cas ça
nous a bien servi. Mais je ne pense pas que ce test soit un taille-
unique. À mon avis chaque test doit dépendre du poste, du candidat et
de l´équipe.
Emmanuel Lecharny
> Plusieurs remarques sur ton post:
> 1. Je trouve qu'il manque dans ta liste l'élément le plus important:
> la capacité à bien se comporter dans un groupe. Des cadors hyper-
> pointus (ou se considérant comme tels) mais complètement asociaux,
> j'en ai trop connu... On dira peut-être que ce n'est pas le but de
> l'entretien technique, mais je pense que c'est là qu'on peut le mieux
> mettre en évidence la personnalité du candidat. Par exemple, est-il
> prompt à dire qu'il ne comprend pas la question, ou qu'il a des
> difficultés à résoudre le problème ? Va-t-il essayer de poser un écran
> de fumée pour masquer le coup, ou bien va-t-il en parler franchement ?
> Après un échec, va-t-il retrouver son sang-froid rapidement ou sera-t-
> il perturbé jusqu'au bout ?
ca me rappelle ce que l'on pratiquait dans la boîte ou j'ai travaillé 8
ans : on mettait le postulant en confiance (important : il faut éliminer
le stress et surtout le sortir de son script) et au moment où on le
sentait à l'aise, on lui posait une question piège sur son sujet favori.
L'idée était de voir comment il réagissait : soit il ne tombait pas dans
le piège, soit il reconnaissait direct qu'il n'avait pas la réponse,
soit il vasouillait grave, et là, pas bon. On était autant intéressé par
voir s'il était capable de nous tenir tête, ou bien s'il acceptait de ne
pas savoir.
Un exemple de 'piège' pour une personne qui a mit sur son CV qu'il a
utilisé un moteur de règle était de lui dire qu'on avait aussi travaillé
sur le sujet, et que les plus puissant des moteurs de règles étaient
d'ordre 2, même si généralement on utilisait des moteurs d'ordre 1 ou
1+. Et on lui demande ce qu'il pense des moteurs de règles d'ordre 2...
Mais ça peut aussi être des questions sur ses hobbies (à condition de
bien maîtriser :)
En tout cas, merci pour les réponses. Il me semble qu'effectivement, les
tests style QCM peuvent être utiles pour les débutants, mais pour les
'anciens', c'est juste inutile.
Cyril Lacôte
Renaud Bruyeron
nous est sous la forme d'un test sur un PC (pas un qcm, un vrai test
du type "il faut coder ça, on regarde le résultat ensemble") où le
candidat travaille au milieu de sa (peut-être) future équipe. C'est
intimidant, mais cela permet au candidat de se faire une assez bonne
idée de l'ambiance et de l'environnement.
En java, c'est plus compliqué de faire un test "live" à cause de
l'overhead outils, donc c'est plutôt sous la forme d'études de cas ou
de mini-exercices avec papier+crayon qui permettent à la fois de
tester le cpu (...), les réflexes/intuition, et de placer 3-4 petites
questions plus précises Java pour vérifier le niveau de connaissances.
On module en fonction de l'expérience: pour les débutants, on teste
les bases académiques, pour les seniors/archis, on teste plutôt la
facilité et l'amplitude du "zoom" technique, c'est à dire l'aptitude à
passer de problématiques macros à des détails techniques très précis
("the devil is in the details, but which details?"). Dans tous les
cas, c'est vraiment une discussion assez technique, avec l'exercice
comme excuse pour sortir du CV et discuter de choses concrètes, pour
voir où le candidat est à l'aise, où il l'est moins, et dans le cas où
il l'est moins, comment il "intuite" et comment il répond aux
suggestions.
En principe, les questions de type "qcm" sont principalement un filtre
passe-haut, pour repérer les imposteurs ou les bachoteurs ;-)
Renaud
2011/5/23 Emmanuel Lecharny <elec...@gmail.com>:
> Hello,
>
> il m'est arrivé une fois, il y a 6 ans, qu'un client me fasse passer un test
> Java (dont je n'ai pas eu le résultat). cela vous est-il arrivé et si oui,
> qu'en avez-vous pensé ?
>
> Par ailleurs, pour ceux qui sont amenés à recruter, cela fait-il partie de
> votre attirail de sélectionneur ? (je met de côté la question des quotas, on
> n'est pas à la FFF ici ;)
>
> Merci !
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>
Adam Marcel
Le QCM donne une très mauvaise image sur la boite et la personne en face, car généralement ce sont des managers (Dépassés techniquement &méthodologiquement) qui préfèrent se cacher derrière un QCM (fraichement téléchargé sur internet), parce qu'ils savent qu'ils n'arriveront pas à distinguer le vrai du faux de ce que raconte le candidat, ça permet aussi de se justifier dans le cas d'une mauvaise sélection.
Le codage en live, c'est très mal vu par le candidat, c'est une façon de dire qu'on cherche un codeur ! pas plus ! Donc tes autres qualités humaines et intellectuelles (Logique, raisonnement, aborder un problème) d'ingénieur études et développement...on s'en fout :)
Les questions les plus pertinentes ressemblent à ça (C'est ma méthode) :
- Le gars parle fièrement de son exploit sur un projet très riche techniquement par exemple, une vraie vitrine technologique, et n'hésite pas à mettre en valeur les techno et les méthodes qu'il a utilisé (c'est du full spring, c'est du DDT etc etc), et là la claque tu repères une technologie qui t’intéresse et que tu connais très bien, et tu lui poses une question digne des meilleurs détecteurs de mensonges : Comment tu fais, comment tu utilises cet outil, parle moi d'un cas concret, simple et complet, et là soit il sait soit il ne sait pas, s'il a déjà utilisé la techno, la réponse vient toute seule, sinon il se mélangera les pinceaux.
Et là comme par hasard, la personne devient plus honnête sur les projets suivant car il attend à tout moment la même question.
- Poser des questions générales comme, c'est quoi une bonne application, les éléments essentiels dans la réussite d'un projet... Là on peut facilement distinguer le programmeur, de celui qui réfléchit aux problématiques de perf/prod, de celui qui se penche plus sur les aspects organisationnels, qui a l'esprit critique, qui sait avoir une vision de l'ensemble...
- Après on arrive à des questions techniques, sur les best practices du langage de programmation, les erreurs connues à éviter, la conception technique...
- Après on pourra compléter pour des profils expérimentés avec des questions du genre, j'ai ça et ça comme besoin, proposez moi une architecture technique, ou une organisation de l'équipe de développement, pourquoi ce produit, pourquoi payer la licence de cet outil alors qu'il y a un autre etc etc...Ca permet tout simplement de distinguer les personnes qui savent de quoi ils parlent, des grands tchatcheurs :)
Emmanuel Lecharny
> Ce que j'en pense personnellement :
> Le QCM donne une très mauvaise image sur la boite et la personne en face,
> car généralement ce sont des managers (Dépassés techniquement
> &méthodologiquement) qui préfèrent se cacher derrière un QCM (fraichement
> téléchargé sur internet), parce qu'ils savent qu'ils n'arriveront pas à
> distinguer le vrai du faux de ce que raconte le candidat, ça permet aussi de
> se justifier dans le cas d'une mauvaise sélection.
>
> Le codage en live, c'est très mal vu par le candidat, c'est une façon de
> dire qu'on cherche un codeur ! pas plus ! Donc tes autres qualités humaines
> et intellectuelles (Logique, raisonnement, aborder un problème) d'ingénieur
> études et développement...on s'en fout :)
>
> Les questions les plus pertinentes ressemblent à ça (C'est ma méthode) :
>
> - Le gars parle fièrement de son exploit sur un projet très riche
> techniquement par exemple, une vraie vitrine technologique, et n'hésite pas
> à mettre en valeur les techno et les méthodes qu'il a utilisé (c'est du full
> spring, c'est du DDT etc etc), et là la claque tu repères une technologie
> qui t’intéresse et que tu connais très bien, et tu lui poses une question
> digne des meilleurs détecteurs de mensonges : Comment tu fais, comment tu
> utilises cet outil, parle moi d'un cas concret, simple et complet, et là
> soit il sait soit il ne sait pas, s'il a déjà utilisé la techno, la réponse
> vient toute seule, sinon il se mélangera les pinceaux.
> Et là comme par hasard, la personne devient plus honnête sur les projets
> suivant car il attend à tout moment la même question.
Chez Marben, où j'ai bossé 8 ans (bon, c'est devenu Atos), et Jeff
pourra le confirmer, la pratique était de poser une question qui
n'attendait pas de réponse (un piège, quoi). L'idée était de savoir si
l'impétrant était capable de reconnaître son ignorance, ou mieux, de
détecter le piège. Mais si le candidat partait dans des considérations
fumeuses, voire pire, expliquait que, oui, il avait utilisé la techno
mais qu'il ne s'en rappelait plus précisément, alors ça sentait la boîte
en sapin pour lui...
Ludovic
- des tests psychotechniques, dans une SSII que je ne citerai pas ici, qui me paraissent vraiment hors-sujet.
- J'ai eu aussi des discussion (sans tests) avec des entretiens qui me paraissaient finalement intéressants (à passer, pas à faire passer) pour le poste ciblé
- J'ai eu aussi un entretien où on m'a demandé de codé un test unitaire sur un algo simple. Cet épreuve servait ensuite de support à une discussion sur mes capacités à dire rapidement "je ne sais pas faire" et celles à dire "peux-tu me filer un coup de main ?". C'était, je trouve, assez pertinent pour savoir si un gars que tu rencontres peux "rapidement" rentrer dans une équipe déjà en place (et donc être à la traîne un certain temps sans rester cloîtrer dans son coin).
Baptiste MATHUS
Salut à tous,
Pour ceux que ça intéresse, dernier roundup des JavaPosse était sur le sujet des entretiens et embauches : http://javaposse.com/java-posse-368-roundup-11-interviewing-and-hiring (podcast en anglais).
Baptiste
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
To view this discussion on the web visit https://groups.google.com/d/msg/lescastcodeurs/-/MjZzOVJFa3hxQTBK.
francois
--
![]()
Thibaud Vibes
Baptiste MATHUS
Le 20 sept. 2012 07:47, "francois" <bianzhu...@gmail.com> a écrit :
>
> T'as le droit de faire blablabla quand tes un directeur. Mais demande toi meme si t'es un vrai developpeur ou un debeggeur. En ton avis, pk on utilise les outils pour nous aider a debugger ?? Je comprends ton idee est pour choisir les gens qui est capable de bien developper, mais franchement, avec les tests super piege, what the hell u want to do ??
Pas vu le piège en question, ms ça dépend du niveau.
Si c'était du style id ( condition ¦¦ true ) et que le candidat ne voit pas qu'on va rentrer ds le if à tous les coups, faut pas déconner...
Si un développeur a besoin à tous les coups d'exécuter le code pr savoir ce qu'il va faire, je suis pas près de donner un avis positif sur son recrutement...
Récemment, j'ai par exemple demandé au candidat de me décrire oralement comment il ferait pr trouver le plus petit élément d'une liste d'entiers.
>
> Je prefere recrute les gens qui peuvent bien reflechir l'architecture et qui ont une vue globale de notre projet au lieu d'un debuggeur.
Il faut les deux. Un développeur ou un "architecte" qui ne passerait pas les étapes ci-dessus ferait mieux de se taire et de laisser les gens travailler.
>> Thibaud Vibes
>>
>> Onyme
>> EuraTechnologies
>> 165 av de Bretagne - Bat Leblan - 59000 LILLE
>> Tèl : +33 (0)3 20 42 88 32
>> Fax : +33 (0)9 72 11 01 69
>> Skype : thibaud.vibes
>> www.onyme.com - tvi...@onyme.com
>>
>> Ce message est exclusivement destiné aux personnes dont le nom figure ci-dessus. Il peut contenir des informations confidentielles dont la divulgation est à ce titre rigoureusement interdite. Dans l'hypothèse ou vous auriez reçu ce message par erreur, merci de le renvoyer à l'adresse e-mail ci-dessus, et de détruire toute copie.
>>
>> This message may contain confidential and proprietary material for the sole use of the intended recipient. Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
> Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msg/lescastcodeurs/-/EbLVH7R6nX0J.
Jean Paliès
Jean Paliès
Baptiste MATHUS
Je rejoins un peu François, car quand on m'a fait passer des tests, c'était du genre "parmi les 5 signatures suivantes, laquelle est une des signatures de la méthode checkImage de java.awt.Component ?" ou ce genre de choses (véridique).
Je suis assez d'accord par contre que quand c'est du fonctionnement de code / compréhension / capacité d'analyse c'est beaucoup plus pertinent que de vérifier si tu connais ta javadoc et que tu es capable de coder sans IDE sans jamais faire la moindre erreur, sans accès au net. Tout dépend aussi du poste recherché, mais en règle générale il vaut mieux à mon avis quelqu'un qui comprend bien ce qu'il fait (et les impacts) plutôt que quelqu'un qui connaît très bien le langage.
Jeff MAURY
on a pratiqué les tests mais on a fini par faire des tests off-line (email) avec uniquement le but d'effectuer un filtre pour le 1er entretien (on avait trop vu de soi disant experts Java) qui ne maitrisaient même pas le concept d'exception.
Jeff
--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes lescastcodeurs.
Pour envoyer un message à ce groupe, adressez un e-mail à lescast...@googlegroups.com.
Pour vous désabonner de ce groupe, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Pour plus d'options, consultez la page de ce groupe : http://groups.google.com/group/lescastcodeurs?hl=fr
--
Jeff MAURY
