Discussion :

[Carhiboux]

Je m'étonne qu'aussi peu de gens parlent de la période d'essai. J'ai lu avec attention les quelques pages de discussion, et cela est ressorti seulement deux fois dans les derniers messages.

Un entretien d'embauche, c'est fait, à mon sens, non pour juger de la compétences techniques d'un candidat, mais bien de sa personnalité, de son caractère, et de son envie. Et de manière beaucoup plus superficielle de ses compétences théoriques.

La compétence pratique, elle, se juge sur la période d'essai! Qui comme son nom l'indique, est un essai. Si l'essai est concluant, on continue, sinon on mets fin à la collaboration. Et ce dans les deux sens.

Cela dit, je comprends cette forme de confusion dans l'esprit de nombreuses personnes, car beaucoup d'entreprises n'utilisent pas réellement cette période d'essai.

J'ai lu beaucoup d'anecdotes sur les conditions de recrutement. Mais il faut aussi garder en tête qu'avant même la compétence, il y a un autre aspect qui rentre en jeu dans le processus de recrutement. Le feeling.

Cela peut paraitre tout bête, et je pense qu'aucun RH ne l'admettra jamais ouvertement, mais je pense que tout le monde le sent de manière assez intuitive. Si le courant passe bien avec un RH (ou avec la première personne qui vous rencontre dans le cadre d'un entretien), vous avez de fortes chances de passer à l'étape suivante du processus de recrutement.

Et ça, c'est totalement arbitraire. Et assez peu contrôlable. Mais comme ce n'est pas un critère objectif, ou en tout cas, admissible, quand le courant ne passe pas, un recruteur peut chercher à "piéger" le candidat pour avoir une autre raison, plus politiquement correcte, de ne pas donner suite.

Pour ma part, si je devais être amené à faire du recrutement, je pense que mes critères seraient au moins autant comportementaux et sociaux que techniques.

Parce que la technique, elle, on peut la faire progresser.

Et, on ne le dit peut être pas assez, mais travailler avec des gens avec qui on s’entend bien, cela n'a pas de prix. Ni pour nous, ni pour l'employeur, qui sommes tous gagnants à cela.

Alors bien sur, il y a quand même un niveau minimum à avoir pour être acceptable, et avoir plus est toujours un atout.

Mais pour l'avoir vécu, les projets se passent toujours mieux avec un développeur qui touche peut être un peu moins sa bille mais qui communique facilement et est réceptif et volontaire plutôt qu'avec un dev qui sera peut être super calé et capable de vous pondre un algo de la mort qui tue, mais qui ne communique pas et n'en fait qu'à sa tête.

[imikado]

Je m'étonne qu'aussi peu de gens parlent de la période d'essai. J'ai lu avec attention les quelques pages de discussion, et cela est ressorti seulement deux fois dans les derniers messages.

1. C'est un problème de temps: si on devait prendre à l'essai tous les candidats dont le courant passe bien, on perdrai beaucoup de semaines à se rendre compte qu'ils ne font pas l'affaire.
Il ne faut pas oublier que l'on passe du temps à presenter les outils, l'environnement, former aux pratiques de l'entreprise... cela prend du temps
2. Et dans beaucoup d'entreprise, on passe par des SSII, donc on a pas vraiment de "période d'essai"

J'ai lu beaucoup d'anecdotes sur les conditions de recrutement. Mais il faut aussi garder en tête qu'avant même la compétence, il y a un autre aspect qui rentre en jeu dans le processus de recrutement. Le feeling.

Oui le feeling, la bonne humeur c'est mieux, mais si la personne bosse trop lentement, ment sur son état d'avancement, ou a du mal à comprendre ce qu'on lui demande...

Parce que la technique, elle, on peut la faire progresser.

Cela dépend de deux choses:
1. le profil recruté
2. le temps du projet
On a déjà pris en prestation un profil "expérimenté" pour un projet assez serré et on a du se débrouiller pour combler ses défauts (heures supp+week end) pour finir dans les temps
Et ce profil n'aurait pas passé mon test du CRUD...

On s'est posé la question d'arrêter sa mission, mais on avait pas le temps de refaire des recrutements pour former un nouveau venu sur le projet qui avait avancé malgré tout: on s'est dit qu'il valait mieux continuer avec...
note: au niveau feeling, il n'y avait pas de problème, cv ok, entretien oral également

[Carhiboux]

1. C'est un problème de temps: si on devait prendre à l'essai tous les candidats dont le courant passe bien, on perdrai beaucoup de semaines à se rendre compte qu'ils ne font pas l'affaire.
Il ne faut pas oublier que l'on passe du temps à presenter les outils, l'environnement, former aux pratiques de l'entreprise... cela prend du temps

A aucun moment je n'ait dit cela voyons. Je dis juste que le fait que le courant passe bien est une condition nécessaire selon moi. Je n'ai pas dit qu'il s'agissait d'une condition suffisante.

2. Et dans beaucoup d'entreprise, on passe par des SSII, donc on a pas vraiment de "période d'essai"

Il suffit de dire à la SS2I que le bonhomme ne fait pas l'affaire et en demander un autre. Ça ne sera ni la première ni la dernière fois que cela arrivera. Et puis un jour, peut être que les clients arrêterons de croire aveuglément les commerciaux des SS2I qui prétendent leur trouver le mouton à 5 pattes.

Oui le feeling, la bonne humeur c'est mieux, mais si la personne bosse trop lentement, ment sur son état d'avancement, ou a du mal à comprendre ce qu'on lui demande...

Mentir sur son état d'avancement est une faute professionnelle. Et est normalement vite remarqué par le reste de l'équipe ou au moins le CdP.

Pour l'incompréhension, là encore, la période d'essai est là pour corriger le tir si cela n'a pas été décelé lors des entretiens d'embauche. Or je pense que les problème de compréhensions font partie des choses qui sont généralement détectées lors des entretiens. Et les problème de compréhensions peuvent se poser même pour les gens très doués techniquement. Si l'on est doué mais que l'on ne comprends pas le besoin final... cela n'avance pas à grand chose non plus.

La lenteur, c'est une autre problème, mais peut être n'est-ce qu'une question de temps et de confiance? Et c'est aussi très subjectif. Un codeur lent qui ne fait pas d'anomalies ou de régressions est-il "meilleur" qu'un codeur plus rapide qui fait des anomalies et des régressions?

Cela dépend de deux choses:
1. le profil recruté
2. le temps du projet

Je pense au contraire que quel que soit le profil, on peut, et on devrait, toujours progresser.
Raisonner en terme de projet est une vision à trop court terme selon moi, surtout sur des projets courts. C'est la méthode de raisonnement des SS2I et tout ceux qui fréquentent ou ont fréquenté ce monde connaissent les problèmes que cela implique : maquillage de CV pour placer à tous pris ses "ressources", choix dictés par la seule finance, etc...
Encore une fois, le mouton à 5 pattes n'existe pas dans la nature. Si on en veut un, il faut le façonner soi même à partir d'un mouton standard à 4 pattes!

[imikado]

A aucun moment je n'ait dit cela voyons. Je dis juste que le fait que le courant passe bien est une condition nécessaire selon moi. Je n'ai pas dit qu'il s'agissait d'une condition suffisante.

Oui je comprends bien, je disais juste que le test technique était nécessaire, après une personne compétente techniquement mais asociable ou désagréable ne sera pas recrutée

Il suffit de dire à la SS2I que le bonhomme ne fait pas l'affaire et en demander un autre. Ça ne sera ni la première ni la dernière fois que cela arrivera. Et puis un jour, peut être que les clients arrêterons de croire aveuglément les commerciaux des SS2I qui prétendent leur trouver le mouton à 5 pattes.

C'est que l'on fait, mais on met du temps à se rendre compte du niveau réel d'un prestataire: on lui laisse quelques semaines pour s'aclimater à l'environnement, aux outils, on lui fait des formations sur nos marchés...
Chaque recrutement, même d'un prestataire est un investissement de temps pour nous

Mentir sur son état d'avancement est une faute professionnelle. Et est normalement vite remarqué par le reste de l'équipe ou au moins le CdP.

Quand on travail sur un projet, on fait confiance à chaque développeur, il indique plus ou moins régulièrement son état d'avancement sur le projet. Si il nous dit que tout va bien, qu'il pense respecter les délais de livraison des lots qui lui sont attribués on lui fait confiance. C'est au moment de la livraison que l'on apprend qu'en fait il a pas fini encore, il reste quelques trucs à régler, pour voir au final, en creusant qu'à peine 1/5 était réalisé et avec des bugs
Mentir est peut être mal choisi ici, c'est peut être une mauvaise estimation de son état des lieux et de son avancement.

Pour l'incompréhension, là encore, la période d'essai est là pour corriger le tir si cela n'a pas été décelé lors des entretiens d'embauche. Or je pense que les problème de compréhensions font partie des choses qui sont généralement détectées lors des entretiens. Et les problème de compréhensions peuvent se poser même pour les gens très doués techniquement. Si l'on est doué mais que l'on ne comprends pas le besoin final... cela n'avance pas à grand chose non plus.

J'ai déjà répondu sur la période d'essai. Et non les entretiens que l'on faisait jusqu'à présent ne comprenait pas de partie technique, donc en discutant de technologie et de son CV, on ne pouvait pas s'en rendre compte.
Il faut différencier un problème/besoin mal compris par un développeur, qui, de bonne fois pond un code qui ne répond pas au besoin.
Le problème ici: on lui expliquait une première fois un concept, il disais ok, puis 1 semaines apres, reposait la meme question, puis encore 2 semaines après se heurtait à un problème lié au principe en question, obligeant à lui ré-expliquer le concept...

La lenteur, c'est une autre problème, mais peut être n'est-ce qu'une question de temps et de confiance? Et c'est aussi très subjectif. Un codeur lent qui ne fait pas d'anomalies ou de régressions est-il "meilleur" qu'un codeur plus rapide qui fait des anomalies et des régressions?

On travaille sur différents types de projets avec des délais plus ou moins variables, en fonction de ceux-ci on prend régulièrement des profils junior: on sait leur niveau, on connait leur productivité, mais on sait qu'on a du temps.
Pour le projet dont je parle, on avait besoin d'un profil expérimenté pour m'épauler vu les délais, on a indiqué au commercial avant, et au candidat pendant l'entretien, son cv était correct, il était sympathique, avait de l'expérience...
Pour info: il codait lentement ET faisait des anomalies/regressions ET était incapable de respecter ses propres estimations...

Je pense au contraire que quel que soit le profil, on peut, et on devrait, toujours progresser.
Raisonner en terme de projet est une vision à trop court terme selon moi, surtout sur des projets courts. C'est la méthode de raisonnement des SS2I et tout ceux qui fréquentent ou ont fréquenté ce monde connaissent les problèmes que cela implique : maquillage de CV pour placer à tous pris ses "ressources", choix dictés par la seule finance, etc...
Encore une fois, le mouton à 5 pattes n'existe pas dans la nature. Si on en veut un, il faut le façonner soi même à partir d'un mouton standard à 4 pattes!

Comme indiqué au dessus, on emploie également des juniors et l'on a pas les mêmes attente, on est plus patient... c'est normal, on a tous débuté un jour

Mais le test technique devient nécessaire avec l'expérience...
notez que dans mon exemple de CRUD, le premier point est de demander au candidat si il estime avoir le temps de le faire en 45 minutes

[bruneltouopi]

J'ai eu à passer 2 entretiens seulement. mais lors du dernier entretien, on voulait un developpeur PHP mais sur mon profil j'etais developpeur JAVA.
Au bout d'une serie de questions avec les recruteurs.On me pose des questions devant comparer Java au PHP.
Et curieusement un des developpeur de la boite a reconnu mon profil sur developpez.com.
Mais après le fameux test sur le petit code à écrire et un exercice d'analyse.
J'ai les ai gracieusement remercié en expliquant que le profil était mal choisi et que bien que pouvant coder du PHP je n'en n'était pas moins passionné.

Quelque fois tu regardes les différentes technos demandés et tu te demandes si le recruteur n'a pas eu juste eu envie de filtrer d'office les potentiels candidats.

Evidemment j'ai pas encore eu l'occasion d'avoir beaucoup d'entretien d'embauche mais quand je vois ce que certains de mes amis subissent en entretien.il faut dire que le niveau de stress et les questions spychologiques font souvent que les récruteurs passent à coté des talents.
Et quelques fois ils ont déjà des questions et des réponses qu'ils attendent et se figent à ne pas voir le problème résolu sous d'autres angles.
Donc un recrutement est aussi une question de chance, de qualité et de gestion de stress sans compté le coté feeling qu'il peut y avoir.

Personnellement moi j'etais en face de 8 à 10 personnes qui me matait de questions pendant plus de 1h30.Et qui s'est transformé en Debat JEE # PHP

[jabbounet]

+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

Tu ne regarde pas uniquement la syntaxe quand tu fais ce genre d'exercice, tu regarde surtout la façon dont le candidat réfléchi, et les questions qu'il se pose et qu'il pose au recruteur quand il ne connait pas quelque chose. il est important de parler.

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

Ne pas connaitre la syntaxe d'un langage et mettre expert+++ niveau +32 sur un cv me parait risqué.
Si tu pratique une langage de façon quotidienne pendant plusieurs années en développement tu connais au minimum la syntaxe du langage.

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

J'ai eu le cas d'une personne ayant fait une thèse et qui a enseigné l'algorithmie, qu n'as pas réussi faire une exercice d'algorithmie simple (dedans il y'a une boucle et 1 condition)

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.

c'est pour cela que le candidat doit être capable de se servir de ses expérience pour réussir l'exercice en restituant ce qu'il a pu apprendre.


En général sur ce genre de question tu t'arrange pour n'avoir que des éléments de base du langage qui sont censée être maîtrisé par le candidat. en caricaturant un peu si le candidat me dit que pour faire une boucle "for" ou "while" il doit aller sur le net, je suis inquiet quand a ses capacité d'acquisition du savoir.

Est-ce que pour écrire en français on fait une recherche sur le net avant, personnellement je m'attend à ce que quelqu'un d'expérimenté dans une techno en dev et qui dit la pratiquer 8h/jour au cours des 5 dernières année connaisse les bases du langage.

[e-ric]

Avant d'être recruté chez Xebia, on m'a demandé de réaliser un projet chez moi avec des specs plus ou moins précises. J'avais 2 semaine pour le faire chez et le renvoyer.

T'as bossé gratuitement et t'en es content ?

[Luckyluke34]

J'ai eu le cas d'une personne ayant fait une thèse et qui a enseigné l'algorithmie, qu n'as pas réussi faire une exercice d'algorithmie simple (dedans il y'a une boucle et 1 condition)

Un problème d'amnésie peut-être ?

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.

c'est pour cela que le candidat doit être capable de se servir de ses expérience pour réussir l'exercice en restituant ce qu'il a pu apprendre.

Oui, mais ça ne suffit pas. Ca ne montre pas à quelle vitesse il a appris, s'il a assimilé à force de répétition ou du premier coup. Ca ne montre pas non plus s'il va avoir du mal à remettre en cause ces bases pour basculer sur un paradigme de programmation ou une méthodologie différents.

Est-ce que pour écrire en français on fait une recherche sur le net avant, personnellement je m'attend à ce que quelqu'un d'expérimenté dans une techno en dev et qui dit la pratiquer 8h/jour au cours des 5 dernières année connaisse les bases du langage.

On est d'accord, je parlais bien sûr de la connaissance et de la manipulation des méthodes adéquates pour lire un fichier (c'est l'exemple d'exercice donné par Eric80), pas de la syntaxe de base du langage. Pour moi savoir qu'il faut utiliser un StreamReader et la méthode ReadToEnd() ou je ne sais quoi d'autre ne relève pas des "bases d'un langage", à la rigueur juste des bases d'un sous-ensemble d'un framework/plateforme...

[pmithrandir]

2. selon vous quel test technique serait acceptable ? (vous êtes contre mon idée de CRUD, contre celle de lire un fichier...)

Je testerais plus algorithmie et la connaissance / compréhension des outils normé(UML par exemple) ainsi que des concepts utilisés dans un langages
- Design patern
- thread
- ...

Si les connaissance théoriques sont là et qu'il sait faire un algo avec plus de 3 niveaux de complexité(boucle / récursivité) on a trouvé quelqu'un d’intéressant je pense.

Le CRUD, je t'avoue qu'il me faudra ou 25 secondes avec symfony pour le faire(génération auto) ou plusieurs journées... pour faire un formulaire propre sécurisé et tout... c'est pas si simple que ca je trouve.

[imikado]

Je testerais plus algorithmie et la connaissance / compréhension des outils normé(UML par exemple) ainsi que des concepts utilisés dans un langages
- Design patern
- thread
- ...

Si les connaissance théoriques sont là et qu'il sait faire un algo avec plus de 3 niveaux de complexité(boucle / récursivité) on a trouvé quelqu'un d’intéressant je pense.

Le CRUD, je t'avoue qu'il me faudra ou 25 secondes avec symfony pour le faire(génération auto) ou plusieurs journées... pour faire un formulaire propre sécurisé et tout... c'est pas si simple que ca je trouve.

Pour le CRUD, cela s'entend sans framework/générateur (sinon on met mon framework et il le fait en 4 clics

Créer un CRUD n'est pas compliqué en soit, estimer le temps nécessaire à l'écriture d'un CRUD en 45 minutes c'est deja se poser et poser les bonnes questions.
Mais il faut une fois le CRUD terminé indiquer ce que l'on modifierai/améliorerai si on avait plus de temps (XSS,XSRF...)

[pcaboche]

Est-ce que pour écrire en français on fait une recherche sur le net avant, ...

Euh... ouais !

Bien que le Français soit ma langue naturelle, il m'arrive très souvent de faire des recherches sur internet, le plus souvent afin de vérifier l'orthographe et la conjuguaison (et quand je vois le niveau de certaines interventions sur internet, je me dis que certains feraient bien d'en faire de même ).

Pourquoi ? Parce que bien que maîtrisant les principes de base, il y a des toujours des détails du langages qui restent abscons ou peu intuitifs...

De même en informatique, même pour les langages que j'utilise tous les jours, il y a certains détails que je suis obligé de chercher régulièrement, soit parce que je suis soudainement pris d'un doute, soit parce que je trouve certains points de la syntaxe absolument pas naturels.

Et en informatique comme en Français, soit tu te débrouilles avec les limites de la grammaire du langage, soit tu choisis une autre tournure de phrase pour exprimer la même idée (parfois de manière plus simple).

[thierryler]

Pour le coup du fichier (sujet que je connais par cœur a force de donner des cours/formations/articles), vous aurez aussi tout le temps un mec en face de vous pour vous dire que nio et nio2 sont tellement mieux que io et que votre code est donc bof... Sauf que le mec ne sait pas les différences entre Bio et Nio et qu'il ne comprendra pas pourquoi io est souvent le bon choix... Bref. Comme on disait, c'est 20 secondes sous Google ça... Raison de plus d'utiliser son iphone si on peut, et même si quelqu'un regarde, en lui expliquant que vous vous mettez en condition réelle... Bon après, la bonne réponse à propos de la lecture d'un fichier, ce n'est pas d'utiliser des Reader ou des BufferedReader ou encore des SuperTopCoolDoubleBufReader... Non la bonne réponse, c'est d'utiliser JUnit... pour écrire des tests. Si vous avez 12 ans de Java derrière vous, c'est insultant si le mec attend vraiment que tu lises le fichier...

[thierryler]

Avant d'être recruté chez Xebia, on m'a demandé de réaliser un projet chez moi avec des specs plus ou moins précises. J'avais 2 semaine pour le faire chez et le renvoyer.

Un de mes stagiaire a fait le test des tondeuses chez Xebia. Sans l'aider j'ai regardé ce qu'il a produit et comment ça s'est passé. Et franchement je trouve que c'est un des meilleurs tests que j'ai pu voir. Vraiment intéressant et enrichissant pour le candidat. Si quelqu'un de Xebia veut bien nous expliquer tout le processus... Par contre, il faut vraiment que le candidat soit motivé.

[thierryler]

A mon sens, un bon entretien technique, c'est surtout une discussion avec le candidat. On lui demande ce qu'il sait faire, ce qu'il ne sait pas faire, on fonction des réponses on approfondit sans le harceler. L'idée est de voir comment il répond, si c'est clair, s'il maîtrise le sujet, etc. Le recruteur n'a même pas besoin de maîtriser lui-même le sujet pour poser des questions dessus. On peut aussi demander au mec ce qu'il aime, n'aime pas, si des sujets l'intéressent, ceux pour lesquels il veut consacrer du temps ou ceux qui sont juste intriguant, etc.

[imikado]

A mon sens, un bon entretien technique, c'est surtout une discussion avec le candidat. On lui demande ce qu'il sait faire, ce qu'il ne sait pas faire, on fonction des réponses on approfondit sans le harceler. L'idée est de voir comment il répond, si c'est clair, s'il maîtrise le sujet, etc.

Si je n'avait jamais eu d'expérience de mauvaise surprise je serais d'accord avec vous. A moins de faire des petits exercices à l'oral (si vous souhaitez trouver les élèves d'une classe non present dans la table de sport vous faites quel type de jointure ? ) Mais ça revient à un QCM avec explication derrière...
Malheureusement on a eu un cas d'un candidat qui selon lui maîtrisait le SQL, php... (cohérent avec son cv et on expérience) et en pratique avait du mal avec les jointure externe

[asfez]

J'ai de la peine à comprendre ce rejet allergique du test technique. Cela me donne le sentiment qu'il relève quasi du crime de lèse majesté de demander à une personne de démontrer que ce qu'elle dit dans son CV n'est pas du chiqué. Quand quelqu'un dit qu'il maîtrise un langage, il doit être capable de le montrer. On ne demande pas à un prof de français de savoir lire un livre de grammaire et de savoir chercher dans un dictionnaire, on lui demande de savoir la grammaire et de connaître du vocabulaire.

Dans notre boîte quand on passe une annonce, on demande au candidat de faire une auto-évaluation de 1 à 5 sur leur maîtrise de différentes technologies / langages. Doit-on s'arrêter là, choisir le plus sympa et commencer une période d'essai (et dire non aux autres) ? Puis un mois plus tard, dire "Excusez-nous on s'est trompé" et tout recommencer. C'est du suicide.

Il y a une quantité non négligeable de personnes qui se surévaluent et / ou racontent n'importe quoi à propos de leurs compétences. Les tests techniques permettent d'en écarter une bonne partie. Si pour un poste il y a 15 candidats, trouver le meilleur est idéal mais échapper aux pires est indispensable.

Moins sérieusement, si quelqu'un dit qu'il apprends vite et qu'il a quelques années d'expérience... alors il devrait savoir beaucoup. Il devrait statistiquement être mieux à même de répondre à des questions précises. Ou alors, il apprend vite et oublie vite au quel cas je préfère quelqu'un qui apprend plus lentement mais qui se constitue un plus gros bagage. Parce que Google, c'est génial et indispensable mais ça prends du temps. Et un développeur qui n'a pas besoin d'aller constamment se documenter sur Internet avance bien plus vite.

[jabbounet]

Euh... ouais !

Bien que le Français soit ma langue naturelle, il m'arrive très souvent de faire des recherches sur internet, le plus souvent afin de vérifier l'orthographe et la conjuguaison (et quand je vois le niveau de certaines interventions sur internet, je me dis que certains feraient bien d'en faire de même ).

Pourquoi ? Parce que bien que maîtrisant les principes de base, il y a des toujours des détails du langages qui restent abscons ou peu intuitifs...

De même en informatique, même pour les langages que j'utilise tous les jours, il y a certains détails que je suis obligé de chercher régulièrement, soit parce que je suis soudainement pris d'un doute, soit parce que je trouve certains points de la syntaxe absolument pas naturels.

Et en informatique comme en Français, soit tu te débrouilles avec les limites de la grammaire du langage, soit tu choisis une autre tournure de phrase pour exprimer la même idée (parfois de manière plus simple).

pour les détails oui, mais ce type de test est plutôt pour de la conversation courante.
Il ne faut pas avoir peur de demander des précisions au recruteur sur un des objets manipulé dans l'exercice si on ne se souviens pas des paramètre d'une méthode ou d'un constructeur, cela peut être bien vu de poser des questions sur ce que l'on ne sais pas, maintenant il ne faut pas pousser non plus en demandant les détail du fonctionnement d'un "if" par exemple car la on retombe sur la partie courante du langage.

[pcaboche]

Il y a une quantité non négligeable de personnes qui se surévaluent et / ou racontent n'importe quoi à propos de leurs compétences.

On a déjà évoqué ce problème.

C'est comme pour le Tour de France : il y a tellement de coureurs qui se dopent que si tu refuses de te doper (de sur-évaluer ton CV), tu ne peux même pas passer les qualifications (la préselection des CV par les RH).

Dans notre boîte quand on passe une annonce, on demande au candidat de faire une auto-évaluation de 1 à 5 sur leur maîtrise de différentes technologies / langages.

On a aussi évoqué ce problème : tout le monde n'utilise pas le même barême. Certains se notent "large" tandis que d'autres sont plus stricts.

Et comme évoqué précédemment, parfois tu te fais rejeter parce que "t'as pas été assez modeste" dans tes réponses.

Désolé mais si le recruteur sait faire son boulot, il n'a pas besoin de cette "auto-évaluation" : il commence par poser des questions générales, demande dans quel domaine le candidat se sent le plus à l'aise (parce qu'on ne peut raisonnablement pas tout connaître sur tous les domaines), oriente les questions dans ce sens, et il arrive à se faire une idée du niveau et de l'attitude du candidat.

J'ai de la peine à comprendre ce rejet allergique du test technique.

Ce n'est pas tant le test technique en lui même, mais l'usage qui en est fait.

Le plus souvent, ce n'est pas pour montrer les compétences réelles du candidat, mais bien pour démonter ce dernier.

C'est un peu comme si tu rentrais dans une boutique de luxe, et que tu disais "elle a l'air bien votre montre, mais elle n'est pas si parfaite que ça. Regardez, là il manque un peu de brillant. Vous pouvez me la faire au prix d'une Swatch ?".

C'est juste insultant.

Si l'entreprise souhaite se payer un consultant de qualité, il faut qu'elle ait les moyens de ses prétentions. C'est comme pour les montres : à un moment, il faut se décider si on recherche une certaine qualité sur la Rue du Rhône (ou la Bahnhofstrasse), ou bien si on souhaite rabattre les prix sur le souk de Marrakech...

[imikado]

L'idée du CRUD n'est pas pour démonter le candidat mais permet de voir plusieurs choses:
1. sa capacité à estimer une charge (pense -t il faire le CRUD en 45 minutes en totalité ou non)
2. voir le code produit (indentation, commentaires...)
3. le resultat (ca fonctionne oui/non , ou pas loin juste un bug à corrigé et c'est bon.)
4. discuter de ce qu'il aurait fait/améliorer si il avait plus de temps (voir sa culture autour d'un sujet concret: va -t-il parler de sécurisation XSS/XSRF...)
5. bien sur exclure ceux qui ont triché sur le CV: pas d'accès internet, juste la doc php, et de quoi coder (smarphone confisqué)

Parce que si c'est concluant dès les premières semaine c'est ce qu'on va lui demander: estimer une chager, coder proprement...

[pmithrandir]

Une chose aussi, même si il y a un entretien technique, si vous êtes refusé, ce n'est pas obligatoirement a cause de ca, même si c'est ce qu'on vous dit.

On recrute aussi des gens avec qui on a envie de bosser, on en a donc dégagé parce que :
- très très bizarre
- odeur insoutenable
- saleté
- comportement improbable
- aucun bon feeling
- inadéquation avec le poste, le niveau ou le salaire.(qu'on peut moduler un peu, mais pas trop)

Et je pense que les RH sont pas aller leur raconter ca... elles ont juste du dire que le test n'avait pas été concluant, rester vague, etc... voir carrément mentir.