Discussion :

[LSMetag]

Faut se méfier, des fois les réponses ne sont pas celles attendues.
"el_slapper, tu vas nous faire ce traitement en COBOL/MVS"
"C'est ballot, les données sont sous UNIX, les référentiels sont sous UNIX, nous fournissons le fichier final sous UNIX, et les transferts entre UNIX et MVS ne marchent jamais, ici. Ca va couter bonbon en maintenance. Et on a plein de gens comme Christine qui rêvent de faire du JAVA - et qui savent faire."
"Oui, mais le développement COBOL coute deux fois moins cher que le développement JAVA. La maintenance, c'est pas notre budget, c'est le votre, alors on s'en fout."
"Pauvre Christine...et pauvre budget maintenance."

2 ans plus tard, les transferts plantaient toujours régulièrement. Plus tard, en cours de management, on m'a appris que la MOA était une aberration purement française, parceque c'est donner bien trop de pouvoir au client. J'avais un exemple en tête tout trouvé pour illustrer.



Et, pour revenir au sujet, Christine avait été recruté suite à un test technique en Java. Pour, au final, faire du cobol. Et, contrairement à moi, elle n'aimait pas le cobol.

Pauvre Christine...

Ton exemple est encore plus parlant que le miens ^^. Oui, j'ai abandonné les SSII à cause du système MOE/MOA/DSI justement.

Justement, quand j'avais posé la question, je m'attendais à avoir une réponse constructive, que j'aurais pu câler dans un coin de mon cerveau. Mais le truc "parce qu'on sait pas faire", répondu par le responsable technique qui devait me chapeauter, ça m'a troué le c... (d'autant que c'était une SSII).

[pcaboche]

Non parce qu'en général (de mon expérience), en StartUp, on n'a pas encore l'art de la langue de bois et le caractère faux cul qui va avec.

Ça dépend du "business angel" qu'il y a derrière.

Quand tu vois le nombre de jeunes entreprises qui se lancent pour créer des jeux débiles pour smartphones, t'as vite compris où ils veulent en venir...

Mais bon, toutes les start-ups ne sont pas comme ça non plus.

[LSMetag]

Mon pire souvenir restera un test de 20 pages à faire sur 1 heures, sur environ 10~12 technos différentes, je ne sais même plus en quoi consistait l'offre et je n'ai pas vu un seul tech, on m'a laissé dans une pièce tout seul... C'était un de mes 1ers entretiens, ça a contribué à me déprimer pendant mes quelques mois de chômage, heureusement que des entreprises sont plus réalistes et laissent leur chances à ceux qui prouvent qu'ils ont des capacités, j'avais déjà parlé de ça mais les recruteurs font parfois tout pour que les candidats se sentent comme des m*****.

Je crois qu'on n'est passé par la (les) même entreprise ^^

[noOneIsInnocent]

Je suis d'accord pour dire que l'entretien RH c'est fait pour éliminer le candidat qui n'est pas approprié ...mais même avec ça il y en a qui passent à travers les mailles du filets. Il faut bien comprendre que les personnes qui font passer l'entretien RH ne sont pas forcement des recruteurs. RH et recruteurs sont des métiers différents comme peuvent l'être Développeur et Ergonome.

Quand au sujet à proprement parlé je trouve que c'est utile de faire passer des tests techniques mais ils ne doivent pas être générique ...
Il faut faire les choses proprement. On ne va pas poser les mêmes questions à un débutant qu'à un expert.
Allez demander à un ingénieur d'étude avec une année d’expérience de monter un environnement de développement avec des framework comme Maven, Spring etc ...
ça ne sert à rien ...

[jabbounet]

Personnellement je pense que le test technique quelque soit sa forme doit être fait par quelqu'un de technique.

Il m’arrive de faire passer des entretiens technique pour mon employeur.

Concernant les CV en général:
Je ne suis pas fan de roman, une page de résumé me suffit souvent, deux cela passe encore, trois ou plus je cherche uniquement les cases qui m’intéressent (compétences, dernière expérience significative, nom des entreprises par ou il est passé). Bref faire court évite de diluer le message, surtout que je ne suis pas recruteur et que j'ai envie de continuer mon projet.

Concernant les expériences sur le CV:
Elle sont intéressantes car elles brossent un aperçu rapide du parcours du candidat mais je ne suis pas toujours convaincu de leur pertinence dans le sens ou le candidat est souvent intégré dans un projet de plusieurs personnes et qu'il peut être difficile de juger de son impact tant positif que négatif sur un projet dont on ne sais pas grand chose. Ceci est d'autant plus vrai si ces expériences sont lointaine.

Personnellement ce qui m’intéresse, c'est ce que le candidat sais faire au moment ou il passe son entretien et sa capacité à évoluer et résoudre des problèmes. Cela passe enter autre chose par un test technique interactif entre moi et le candidat.

la personnalité est aussi importante, le critère est simple dans ce cas, je me pose simplement la question suivante*"est-ce que je supporte / veux travailler / avec cette personne quotidiennement ?"

Après il n'y a pas de miracle, c'est la période d'essai qui filtrera l'erreur de casting si le candidat est recruté et que l'on se rend compte qu'il n’était pas si bien.

[chaplin]

Le dernier entretien technique que j'ai passé, j'étais à la ramasse, je n'avais plus touché un ordinateur depuis 6 mois, ils m'ont gentillement envoyé dans les roses.

Néanmoins, quand j'étais sérieux, lors d'un entretien étaient présent un recruteur, le manager et le CP. Ce dernier voulait me planter sur les technos qu'il utilisait. J'étais d'un calme olympien, très détendu, reconnaissant mes lacunes. Le soir de l'entretien, le recruteur m'appelle en me disant que c'est plutôt cuit, que j'avais la plupart du temps répondu à côté. Je lui dis laissez moi un peu de temps pour me documenter.

Après une investigation minutieuse, j'ai bombardé le recruteur d'emails pour lui finalement envoyer une phrase clé qui prouvait qu'une techno que le CP préconisait ne fonctionnait pas sur le nouvel OS.

En résumé, je leur avait démontré que le CP nous avait baratiné, s'ils voulaient allé droit dans le mûr, c'était leur droit, mais c'était pas mon problème. J'étais embauché!

[imikado]

Elle sont intéressantes car elles brossent un aperçu rapide du parcours du candidat mais je ne suis pas toujours convaincu de leur pertinence dans le sens ou le candidat est souvent intégré dans un projet de plusieurs personnes et qu'il peut être difficile de juger de son impact tant positif que négatif sur un projet dont on ne sais pas grand chose. Ceci est d'autant plus vrai si ces expériences sont lointaine.

+1: j'ai déjà travaillé avec un développeur qui avait, sur son cv fait du symfony (point qui avait joué en sa faveur en lisant son cv) or lors de notre collaboration, remarquant des petits soucis, je l'avais interrogé sur symfony (branche 1) et son expérience dessus: en fait il avait juste développé de manière isolé: ne savait pas "créer une nouvelle application" ni "geler les librairies" (ne connaissait même pas ce principe)

Donc il faut creuser l'expérience indiqué sur les CV pour voir ce qu'a réellement fait le candidat

[el_slapper]

+1: j'ai déjà travaillé avec un développeur qui avait, sur son cv fait du symfony (point qui avait joué en sa faveur en lisant son cv) or lors de notre collaboration, remarquant des petits soucis, je l'avais interrogé sur symfony (branche 1) et son expérience dessus: en fait il avait juste développé de manière isolé: ne savait pas "créer une nouvelle application" ni "geler les librairies" (ne connaissait même pas ce principe)

Donc il faut creuser l'expérience indiqué sur les CV pour voir ce qu'a réellement fait le candidat

Maintenant, est-ce qu'il peut apprendre vite? Parceque je préfère un profil qui ne sait pas faire mais s'adapte vite à un profil qui a déjà fait et ne décramponne pas de ses petites habitudes.

[Aurélien LEQUOY]

+1: j'ai déjà travaillé avec un développeur qui avait, sur son cv fait du symfony (point qui avait joué en sa faveur en lisant son cv) or lors de notre collaboration, remarquant des petits soucis, je l'avais interrogé sur symfony (branche 1) et son expérience dessus: en fait il avait juste développé de manière isolé: ne savait pas "créer une nouvelle application" ni "geler les librairies" (ne connaissait même pas ce principe)

Donc il faut creuser l'expérience indiqué sur les CV pour voir ce qu'a réellement fait le candidat

Pour ça que je demande toujours le contexte quand je fais passer un entretien, et je ne parle même des postes qu'il a pu occupé qui ne corresponde pas au poste.

[imikado]

Maintenant, est-ce qu'il peut apprendre vite? Parceque je préfère un profil qui ne sait pas faire mais s'adapte vite à un profil qui a déjà fait et ne décramponne pas de ses petites habitudes.

Pour ce profil là... on l'a remercié entre temps (ils nous a fait perdre du temps, et laissé du code...)
Bref, mais je suis d'accord que sur d'autre profil plus jeunes ou au moins plus passionné on peut avoir de bonne surprise, mais il faut quand même creuser l'expérience pour na pas avoir de mauvaise surprise

[Eric80]

Dans le dernier projet que j ai fait (proj .NET), l entretien avec le chef de projet et l architecte du soft surquel je devais bosser s'est terminé par un mini test technique: j'avais 3 min pour écrire le bout de code nécessaire pour lire une ligne dans un fichier texte (genre un using (StreamReader...). Cela m a surpris sur le moment mais aussi semblé tellement trivial que je me suis demandé "à quoi bon?".
Plus tard (une fois engagé sur le projet), les 2 collègues m ont raconté que plusieurs candidats ayant un énorme bagout étaient tombé sur ce test basique...

[thierryler]

Plus tard (une fois engagé sur le projet), les 2 collègues m ont raconté que plusieurs candidats ayant un énorme bagout étaient tombé sur ce test basique...

Peut être aussi parce qu'un développeur expérimenté n'en a rien à faire de lire un fichier, surtout en 3 minutes...

[Olivier P.]

Je suis chef de projet en SSII et je réalise des entretiens techniques lors de nos recrutements. Dans ce cadre, je fais passer un test technique.
Aussi je vous apporte mon témoignage.

Tout d'abord, il n'est pas toujours évident pour un candidat de montrer ses réalisations. En effet, un développeur ne fait pas forcément du pur web visible.
Beaucoup travaillent sur des intranets, du code privatif, ou dans la "tuyauterie" d'une application. Ensuite, ce n'est pas parce que vous avez participé à l'élaboration d'un site web, que vous l'avez réalisé de A à Z.

Ensuite, pour rebondir sur l'exemple du plombier à qui on ne fait pas passer d'entretien technique avant de le faire venir à la maison, c'est vrai et pas vrai...
C'est pas toujours le cas, mais d'une manière générale, on appelle un plombier (ou autre) car il nous est recommandé par quelqu'un.
Or en SSII, pour ceux qui y travaillent, nous savons très bien que la recommandation ne se pratique pas.
Qui irait appeler un manager concurrent pour lui demander des informations sur un prestataire ?

Donc, un test technique est un excellent outil pour juger la personne.

Cela dit, il y a test technique et test technique....
Le notre n'est pas adhérent à une technologie ou à un langage. Il n'est pas non plus sous forme de QCM. Il est orienté autour de la culture informatique et la conception "grosse maille" d'une application.

Alors certes, il ne permet pas forcément de repérer les très bons, stress ou autre oblige, mais pas contre, il permet à coup sur d'écarter les mauvais.

[imikado]

Peut être aussi parce qu'un développeur expérimenté n'en a rien à faire de lire un fichier, surtout en 3 minutes...

1. un développeur expérimenté de doit jamais parser des fichiers plats ?
2. selon vous quel test technique serait acceptable ? (vous êtes contre mon idée de CRUD, contre celle de lire un fichier...)

Je vous rappelle que ceux-ci sont la pour éviter d'embaucher un profil qui sera remercié 1 semaine après (et aura fait perdre du temps au deux parties)
Quel test technique feriez-vous passer à un futur collègue ?

[el_slapper]

(.../....)
Tout d'abord, il n'est pas toujours évident pour un candidat de montrer ses réalisations. En effet, un développeur ne fait pas forcément du pur web visible.
Beaucoup travaillent sur des intranets, du code privatif, ou dans la "tuyauterie" d'une application. Ensuite, ce n'est pas parce que vous avez participé à l'élaboration d'un site web, que vous l'avez réalisé de A à Z.

+1. Perso, je bosse pour des applis internes à des grands comptes(banques, assurances). Par définition, 100% de mon travail est protégé par le secret professionel.

Ensuite, pour rebondir sur l'exemple du plombier à qui on ne fait pas passer d'entretien technique avant de le faire venir à la maison, c'est vrai et pas vrai...
C'est pas toujours le cas, mais d'une manière générale, on appelle un plombier (ou autre) car il nous est recommandé par quelqu'un.
Or en SSII, pour ceux qui y travaillent, nous savons très bien que la recommandation ne se pratique pas.
Qui irait appeler un manager concurrent pour lui demander des informations sur un prestataire ?

Il est arrivé qu'on me demande de recommander des gens, mais c'est en effet rarrissime, et c'était le client qui demandait. +1, donc

Donc, un test technique est un excellent outil pour juger la personne.

Cela dit, il y a test technique et test technique....
Le notre n'est pas adhérent à une technologie ou à un langage. Il n'est pas non plus sous forme de QCM. Il est orienté autour de la culture informatique et la conception "grosse maille" d'une application.

J'ai eu ça une fois. Une spec vague, il fallait faire un dessin de chaine, et un plan de test succint. C'est très révélateur. Mais c'est plus un test de pensée qu'un test technique.

Celà dit, si un jour j'ai à recruter, j'essayerais peut-être le test Jeff Atwood : j'emmène le candidat et toute l'équipe à la machine à café, et je demande au candidat de parler de ses projets.

Alors certes, il ne permet pas forcément de repérer les très bons, stress ou autre oblige, mais pas contre, il permet à coup sur d'écarter les mauvais.

En même temps, un cador qui ne tient pas le stress, c'est souvent rédhibitoire.

[Olivier P.]

Celà dit, si un jour j'ai à recruter, j'essayerais peut-être le test Jeff Atwood : j'emmène le candidat et toute l'équipe à la machine à café, et je demande au candidat de parler de ses projets.

Délicat... Demander à quelqu'un de parler devant des "inconnus" peut être une vraie épreuve autrement plus stressante ...

D'autant, qu'on cherche à juger ses compétences techniques, pas oratoires.

[el_slapper]

Délicat... Demander à quelqu'un de parler devant des "inconnus" peut être une vraie épreuve autrement plus stressante ....

C'est pour ça que ça se passe à la machine à café. Ca n'est pas parfait, mais c'est certainement moins intimidant que de passer au tableau blanc.

D'autant, qu'on cherche à juger ses compétences techniques, pas oratoires.

Pas seulement. Les gens de l'équipe sont là pour poser des questions techniques, mais on évaluera aussi la manière dont il répond. Surtout, dans la vraie vie, on lui posera sans doute bien plus de questions à la machine à café qu'au tableau blanc. Si il ne sait pas répondre pour des raisons de communication, alors il aura des problèmes à communiquer avec le reste de l'équipe. Et si il n'est, techniquement, qu'une outre gonflée, les multiples questionneurs finiront par le detecter.



Enfin, ça, c'est la théorie. Je n'ai jamais eu l'occasion d'essayer.

[Olivier P.]

C'est pas faux en effet.

Attention tout de même, on a le droit d'être timide, pas à l'aise devant un "public" et malgré tout bon communiquant en comité restreint lorsqu'un climat de confiance est établi, ou devant un client.

Nous voyons nos candidats 2 fois. Une fois dans le cadre d'un échange très ouvert, permettant de détecter les valeurs humaines de la personne, et un deuxième, technique.
Les interlocuteurs ne sont pas les mêmes dans les deux entretiens.

Nous discutons ensuite entre nous pour juger les valeurs humaines et techniques de la personne.

Ceci n'est pas une vérité, nous faisons aussi des erreurs bien sur. Mais cela reste relativement fiable.

[Luckyluke34]

j'avais 3 min pour écrire le bout de code nécessaire pour lire une ligne dans un fichier texte (genre un using (StreamReader...).

Peut être aussi parce qu'un développeur expérimenté n'en a rien à faire de lire un fichier, surtout en 3 minutes...

+1. A la limite si on s'en souvient pas ça se retrouve en 20 sec sur le net.

Avait-on accès à Google et/ou msdn pour ce test ? Si ce n'était pas le cas :

- Se servir de ce genre de test pour donner un + aux développeurs ayant une bonne mémoire et/ou étant habitués à manipuler des fichiers, OK.

- Se servir de ce genre de test de façon éliminatoire... c'est juste se couper d'énormément de gens qui ne connaissent peut-être pas la syntaxe par coeur.

plusieurs candidats ayant un énorme bagout étaient tombé sur ce test basique

C'est quoi "tombés" ? Ne connaissaient pas les méthodes à utiliser par coeur ? Ont rendu feuille blanche ? N'ont pas fini dans les temps ? Ont fini mais rendu un résultat buggé ? ...

Sinon je pense que el_slapper a la bonne solution : tester les compétences d'une personne à un instant T c'est bien, mesurer sa capacité à évoluer et apprendre, c'est mieux.

[Luckyluke34]

Or en SSII, pour ceux qui y travaillent, nous savons très bien que la recommandation ne se pratique pas.
Qui irait appeler un manager concurrent pour lui demander des informations sur un prestataire ?

On ne doit pas travailler dans les mêmes alors

J'ai vu :

• Plusieurs managers chargés de recrutement en SSII appeler des concurrents/amis/ex-collègues pour se renseigner sur des candidats.
• Un manager appeler un recruteur de SSII pour le mettre le en garde contre un collaborateur récemment parti et qui était en train de candidater dans la SSII en question.

Par ailleurs, j'ai connu plusieurs processus de recrutement où on demandait les coordonnées de 2 personnes qui avaient encadré le candidat dans des expériences précédentes et pouvaient le recommander. J'ai l'impression que ça se pratique de plus en plus.

Evidemment ça ne doit pas remplacer ni même venir au même niveau qu'une évaluation technique, mais recueillir l'avis de gens qui ont précédemment travaillé avec le candidat peut être un élément parmi d'autres dans un faisceau d'indices qui va amener au recrutement ou pas.