Envoyé par hugo123
Entièrement d'accord avec toi. Sur le CV on peut avoir par exemple 3 ans d'expérience en PHP, et ne pas en avoir fait depuis 1 ou 2 ans; forcément on aura plus de mal a répondre à certaines questions, alors que le niveau est là...
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Entièrement d'accord avec toi. Sur le CV on peut avoir par exemple 3 ans d'expérience en PHP, et ne pas en avoir fait depuis 1 ou 2 ans; forcément on aura plus de mal a répondre à certaines questions, alors que le niveau est là...
Remarque intéressante : le fait qu'on te fasse passer un tel examen ne vient-il pas du fait que tu sortes de l'école ? Ca a un certain sens sur un jeune diplômé, sans lui refaire passer son diplôme non plus. Mais ensuite...
J'ai eu ça récemment pour .NET. La RH m'a carrément avoué que c'était un extrait des certifs Microsoft.le test le plus débile est le QCM automatisé sur un site web avec un score à la fin.
Sinon en dehors de ça des questions sur les notions de base de la POO. Les questions qui s'approchaient le plus de cas pratiques concernaient SQL Server. Bien. Sauf que je n'ai pas de compétences SQL Server, cela n'apparait pas sur mon CV et j'avais mentionné lors du premier entretien que je n'avais jamais travaillé dessus.
Oui mais 200 candidats en période d'essai, ca ne le fait pas.
Il te faut bien un moyen rapide et simple pour supprimer les boulets.
Par ailleurs ton refus pourrait etre mal interprété:
Le développeur pédant qui ne s'abaisse pas un test débile.
C'est variable, les gros mensonges sont détectables mais les petits passeront inapercus lors de l'entretien.
- 3 ans d'experiences au lieu de 2 ans
- Tu peux ajouter un language que tu as utilisé a l'école dans une expérience professionnelle pour gagner crédibilité.
Je partage cet avis encore une fois, le test permet de faire une premiere selection.
Je pensais comme toi auparavant, maintenant je pense qu'un projet peut avoir besoin de différent profil du débutant a l'expert.
Meme si ta capicité d'analyse est primordiale, la facon dont tu vas l'implementer dépendra de ton expérience.
C'est un autre débat dont on a largement discuté sur ce site mais la technique est sous-estimé en France.
La tu m'as bien fait rire...tu me diras combien ils t'ont payé de l'heure pour ta prestation.
+1
+1
J'ai passé 4/5 entretiens sans qu'on me propose un PC pour montrer ce que je sais faire. J'ai l'impression que c'est comme proposer un poste de boulanger sans goûter le pain.
J'avais fait un joli pavé et tout et pis j'ai fait mauvaise manip donc je refais en bref: pour moi, un informaticien c'est pas quelqu'un qui code, code, code (codec).
Un entretien fait par un non-inité ne doit pas parler technique et c'est ce qui se passe en général, soit du rh, soit un commercial (à qui on doit expliquer parfois ce qu'est developpez.com).
Quand on passe à une étape plus technique, on a déjà eu du ménage donc le nombre de candidats est réduit.
Et là si on est en face de quelqu'un qui s'y connait, il aura plus tendance à parler directement que de passer par de l'écrit. Je pense qu'une méthode plus intéressante serait de mettre le candidat à un tableau, de lui donner une mise en situation (genre un truc bien compliqué) et il doit se débrouiller pour une solution. Bon moyen de voir la gestion du stress, si le candidat est capable de demander des informations ou s'il reste coincé tout seul dans son coin, etc...
J'ai passé pas mal de tests moi aussi en 20 ans... Quelques un totalement loufoques. Des problèmes de logique a résoudre en boucle : au bout du 3° ya quoi de avoir envie de se sauver.
Le mieux je pense est de lui faire faire une analyse et ensuite de le lui faire coder un petit bout de code de cette analyse. (si possible la plus compliquée techniquement). Et qu'il vous explique ce qu'il a fait et pourquoi il a fait comme ça. L'entretien vaut plus que le fait que le code soit fonctionnel ou pas.
Il faut faire subir des tests aux recrutés et ensuite leur faire subir une période d'essai. Les deux sont utiles. Il vous faut un préfiltre. Vous ne pouvez pas faire subir une periode d'essai à tous vos candidats.
Je pense que c'est justement l'idée du truc, tel que présenté par Spolsky en tous cas (sauf qu'on fait ça sur une simple feuille de papier plutôt qu'un tableau). Ainsi, certaines boites vont carrément te poser une question impossible à répondre, histoire de tester ton enthousiasme à chercher des solutions. Microsoft a beaucoup développer cela à une certaine époque :
Amazon.com: How Would You Move Mount Fuji? Microsoft's Cult of the Puzzle - How the World's Smartest Company Selects the Most Creative Thinkers (9780316919166): William Poundstone: Books
Mais c'est en complément du test technique de programmation, pas en remplacement. Car effectivement un informaticien c'est pas quelqu'un qui code code code, mais il code quand même un peu- How Would You Move Mount Fuji?
- how do they make M&Ms?
- what does all the ice in a hockey rink weigh?
- how many piano tuners are there in the world?
Questions like these, which test problem-solving abilities, not specific competencies
J'ai passé un entretien intéressant il y a peu. Pour un poste de conseille, le process est le suivant :
- Entretien avec un RH. Présentation du CV, ect. Si l'entretien est réussi, tu entres comme junior.
- Entretien avec un technique. Les questions sont posées par un expert technique. Schémas d'archi a dessiner et justifier, etc. Si tu réussi l'entretien, tu es expert.
- Entretien avec un architecte. Présenter 20 minutes de préconisation, sur une problèmatique donnée trop vaste pour être présenté en 20 minutes. Perso, on m'a présenté une entreprise ayant trop vite grossi. Elle souhaite rénover son site Internet. On m'a demandé des solutions d'architecture physiques, logicielles et de remanient organisationnel.
Powerpoint en .pdf à fournir sur une clé USB.
Je ne serai pas architecte ^^
Alors, deux remarques par rapport au sujets precédents :
Je ne trouve pas que cela soit inutile, même si je pense qu'on a pas a demander la même rigueur. décrire un algorithme sur papier démontre pour moi une capacité a sortir le nez de son ordinateur, et a faire de la réflexion pure, sans toujours "tester".Pondre du code sur papier c'est nul
Celle la doit être de loin la plus stupide. Mon boulot consiste a réfléchir beaucoup et à coder peu, je n'ai absolument pas besoin d'être aussi rapide qu'une secrétaire pour écrire, étant donné que la réflexion a besoin de temps pour se mettre en place.On peut estimer la qualité d'un dev a sa capacité a utiliser son clavier
je dois utiliser entre 3 et 5 doigts pour écrire depuis des années.(en fonction de la fatigue et du niveau d'alcool ca peut descendre à 1 ou 2.
L'avantage du tableau, c'est que l'examinateur peut voir la réflexion du candidat sur le long et non pas un résultat vrai ou faux à la fin. Je pense que c'est plus enrichissant pour les deux parties (le candidat qui ressort avec l'impression d'être moins bête et l'examinateur qui s'est moins fait chier que s'il avait du lire un bout de code). Sur les questions impossibles, ça peut être sympa avec le côté out of the box mais vu que ça n'a pas trop de rapport avec l'informatique je vois pas trop l'intérêt à part le côté fashion.Je pense que c'est justement l'idée du truc, tel que présenté par Spolsky en tous cas (sauf qu'on fait ça sur une simple feuille de papier plutôt qu'un tableau
Amazon.com: How Would You Move Mount Fuji? Microsoft's Cult of the Puzzle - How the World's Smartest Company Selects the Most Creative Thinkers (9780316919166): William Poundstone: Books
Mais c'est en complément du test technique de programmation, pas en remplacement. Car effectivement un informaticien c'est pas quelqu'un qui code code code, mais il code quand même un peu
Et puis même si on code un peu beaucoup, le côté algorithmique devrait peser plus que le côté écriture dans un langage puisque c'est ce qui permet de s'adapter plus facilement.
Juste pour préciser : il s'agit bien de faire le test "en temps réel" aux côtés du recruteur, et non pas d'enfermer le candidat dans une pièce avec sa feuille blanche.
L'intérêt est de jauger ta capacité à chercher des solutions. Si on te demande "combien y a-t-il de lampadaires dans Paris", et que tu réponds "pouha j'en sais rien du tout moi !", bon ben ça montre un intérêt et une curiosité zéro. Quelqu'un qui pose ce genre de question veut une personne qui a le goût du challenge, qui sache chercher et trouver par lui même des solutions aux problèmes complexes, qui sache persévérer. Voilà l'idée en gros.
C'est un vieux débat : le code vs la conception. Ca finit souvent en troll, chacun prêchant pour sa paroisse. Je pense que dans les faits les 2 sont important. Savoir lequel est le + important est une perte de temps : les deux sont importants. Et ils sont mêmes intimement liés : tu ne peux pas bien maîtriser un langage un poil évolué sans maitriser l'algorithmie (complexité des algos disponibles etc...).
Je vais essayer de dire ce que je pense sans trop heurter les susceptibilités de chacun, mais voilà : l'importance de la maîtrise d'un langage échappe à ceux qui précisément ne maitrisent pas assez un langage pour en percevoir les subtilités. Et ce sont précisément eux qui se font épingler aux tests techniques, alors forcément ils trouvent ça naze de se faire disqualifier sur ce qui de leur point de vue n'a pas grande importance
moi je pense quand même que c'est une connerieJuste pour préciser : il s'agit bien de faire le test "en temps réel" aux côtés du recruteur, et non pas d'enfermer le candidat dans une pièce avec sa feuille blanche.
L'intérêt est de jauger ta capacité à chercher des solutions. Si on te demande "combien y a-t-il de lampadaires dans Paris", et que tu réponds "pouha j'en sais rien du tout moi !", bon ben ça montre un intérêt et une curiosité zéro. Quelqu'un qui pose ce genre de question veut une personne qui a le goût du challenge, qui sache chercher et trouver par lui même des solutions aux problèmes complexes, qui sache persévérer. Voilà l'idée en gros.
C'est un vieux débat : le code vs la conception. Ca finit souvent en troll, chacun prêchant pour sa paroisse. Je pense que dans les faits les 2 sont important. Savoir lequel est le + important est une perte de temps : les deux sont importants. Et ils sont mêmes intimement liés : tu ne peux pas bien maîtriser un langage un poil évolué sans maitriser l'algorithmie (complexité des algos disponibles etc...).
Je vais essayer de dire ce que je pense sans trop heurter les susceptibilités de chacun, mais voilà : l'importance de la maîtrise d'un langage échappe à ceux qui précisément ne maitrisent pas assez un langage pour en percevoir les subtilités. Et ce sont précisément eux qui se font épingler aux tests techniques, alors forcément ils trouvent ça naze de se faire disqualifier sur ce qui de leur point de vue n'a pas grande importance
Pas forcément. Certains tests sont intelligents et bien menés. D'autres sont aberrants. Par exemple, si on vous demande simplement de créer un programme et que l'on regarde votre manière de gérer la demande, oui, c'est intelligent. Si en revanche, on vous demande de citer 3 méthodes et 3 propriétés des datagrids en asp.net c'est moins significatif (outre le fait que normalement plus personne n'est censé utiliser les datagrids...).Je vais essayer de dire ce que je pense sans trop heurter les susceptibilités de chacun, mais voilà : l'importance de la maîtrise d'un langage échappe à ceux qui précisément ne maitrisent pas assez un langage pour en percevoir les subtilités. Et ce sont précisément eux qui se font épingler aux tests techniques, alors forcément ils trouvent ça naze de se faire disqualifier sur ce qui de leur point de vue n'a pas grande importance
De même si la personne qui vous demande ce que c'est qu'une architecture 3-tiers vous regarde avec des yeux de merlan frit lorsque vous commencez à parler de n-tiers, vous savez directement que vous n'avez pas affaire à un spécialiste, et le test à de bonnes chances de ne pas être significatif.
Franchement, pour tous les tests que j'ai passé, je n'ai jamais estimé qu'ils avaient montré mes compétences, ni d'ailleurs mes lacunes. Et très souvent ils n'étaient absolument pas adaptés au poste final.
Personnellement, en tant qu'expert technique dans mon domaine, pour recruter quelqu'un, je préfère discuter avec la personne 1h de différents points techniques, ce qu'elle a fait, aimerait faire.. Voir si elle connait des sites comme developpez.com, codeproject, codeplex, sourceforge... voir si elle fait de l'informatique depuis l'école ou si elle a commencé avant. Savoir si la personne à recruter utilise l'ordinateur au boulot et n'y touche jamais chez elle.. bref, je privilégie sans commune mesure et sans hésitation le dialogue et l'échange verbale plutot que des tests qui valent ce qu'ils valent...
Quand je vois des tests type QCM genre un peu certif microsoft, je me dis que c'est un catalogue, une librairie à connaitre et que le fait d'avoir la certification, certes est un gage qu'on a su répondre à un certain nombre de question, ce n'est pas pour autant qu'on s'est résoudre de "VRAI" problème. J'arrive (alleluia) à différencier un geek d'un informaticien fraichement moulu sans difficulté et sans test...
Après, je veux bien croire que les recruteurs ne sont pas toujours techniques aux premiers entretiens et je peux comprendre que le filtrage soit "utile" pour éviter de monopoliser les cadors de l'entreprise et faire un écrémage pour éviter celà. Pour autant, je pense que la seule évaluation "vraiment" valable, c'est celle qui se fait en entretien "face To face"
"Individuals and interactions over processes and tools" pour les connaisseurs :-)Après, je veux bien croire que les recruteurs ne sont pas toujours techniques aux premiers entretiens et je peux comprendre que le filtrage soit "utile" pour éviter de monopoliser les cadors de l'entreprise et faire un écrémage pour éviter celà. Pour autant, je pense que la seule évaluation "vraiment" valable, c'est celle qui se fait en entretien "face To face"
Tout d'abord, je n'ai pas dit qu'on pouvait estimer la qualité d'un dev, j'ai dis que regarder la façon dont il tappe sur un clavier était révélateur de beaucoup de choses.Celle la doit être de loin la plus stupide. Mon boulot consiste a réfléchir beaucoup et à coder peu, je n'ai absolument pas besoin d'être aussi rapide qu'une secrétaire pour écrire, étant donné que la réflexion a besoin de temps pour se mettre en place.On peut estimer la qualité d'un dev a sa capacité a utiliser son clavier
je dois utiliser entre 3 et 5 doigts pour écrire depuis des années.(en fonction de la fatigue et du niveau d'alcool ca peut descendre à 1 ou 2.
Je vais développer un peu.
Lorsque tu frappes avec une seule main ou avec deux tu es loin d'avoir la même vitesse de frappe. Si tu juges que tapper avec une seule main te permet d'avoir un rythme suffisant au point ne pas avoir voulu l'améliorer, c'est que tu considères que ta vitesse de frappe n'entrave pas ta réflexion.
Autrement dit, que tu ne réfléchis pas plus vite que ce que tu tappes sur ton clavier, ta vitesse de frappe révèle alors ta vitesse de réflexion
Mais il n'y a pas que le nombre de mains ou de doigts utilisés qui est révélateur. On peut aussi regarder l'attitude générale : Est-ce que le candidat as besoin de regarder le clavier lorsqu'il tappe, est-ce qu'il ne regarde que l'écran ou est-ce qu'il passe son temps à passer de l'écran au clavier.
Est-ce qu'il alterne les phases de réflexion et les phases de frappe, ou est-ce qu'il tappe en continu...
Comme je l'ai dit précédemment, le nombre d'années d'expériences ne fait pas la qualité de cette dernière. Si un candidat expérimenté ne sait pas tapper sans regarder le clavier, s'il tappe avec un seul doigt ou autre pratique contre-productive ça montre qu'il n'a pas cherché à s'améliorer.
Ce genre de détail est révélateur d'un certain nombre de traits de personnalité, et il est très difficile de mentir sur ce genre de détails.
C'est la même chose que lors d'un entretien, il y a de la communication verbale (ce que le candidat dit) et de la communication non verbale, (généralement inconsciente), qui en dit souvent tout aussi long.
Par exemple si un mec qui tapes sur son clavier sans regarder l'écran ou faisant des va et vient entre le clavier et l'écran, trouves-tu que c'est éliminatoire ? (j'exagères
Dans l'analyse d'un candidat, quelle proportion prends toutes ces analyses ?
Mosco
C'est bien ce que je dis, ca me parait toujours aussi inutile...Tout d'abord, je n'ai pas dit qu'on pouvait estimer la qualité d'un dev, j'ai dis que regarder la façon dont il tappe sur un clavier était révélateur de beaucoup de choses.
Je vais développer un peu.
Lorsque tu frappes avec une seule main ou avec deux tu es loin d'avoir la même vitesse de frappe. Si tu juges que tapper avec une seule main te permet d'avoir un rythme suffisant au point ne pas avoir voulu l'améliorer, c'est que tu considères que ta vitesse de frappe n'entrave pas ta réflexion.
Autrement dit, que tu ne réfléchis pas plus vite que ce que tu tappes sur ton clavier, ta vitesse de frappe révèle alors ta vitesse de réflexion
Mais il n'y a pas que le nombre de mains ou de doigts utilisés qui est révélateur. On peut aussi regarder l'attitude générale : Est-ce que le candidat as besoin de regarder le clavier lorsqu'il tappe, est-ce qu'il ne regarde que l'écran ou est-ce qu'il passe son temps à passer de l'écran au clavier.
Est-ce qu'il alterne les phases de réflexion et les phases de frappe, ou est-ce qu'il tappe en continu...
Comme je l'ai dit précédemment, le nombre d'années d'expériences ne fait pas la qualité de cette dernière. Si un candidat expérimenté ne sait pas tapper sans regarder le clavier, s'il tappe avec un seul doigt ou autre pratique contre-productive ça montre qu'il n'a pas cherché à s'améliorer.
Ce genre de détail est révélateur d'un certain nombre de traits de personnalité, et il est très difficile de mentir sur ce genre de détails.
C'est la même chose que lors d'un entretien, il y a de la communication verbale (ce que le candidat dit) et de la communication non verbale, (généralement inconsciente), qui en dit souvent tout aussi long.
je dois avoir tous les défauts dont tu parle, je tape malgré tout assez vite et ca ne m'handicape pas pour mon boulot.
J'étais plutôt considéré comme rapide dans mes différents job.
Et je dirais même plus, le mec qui tape sans s'arrêter était en général plutôt mauvais autour de moi... il savait taper(la belle affaire, il a un niveau secrétaire...) mais se poser et réfléchir a un problème tranquillement, ... c'était pas possible.
Mais bon, après, ca dépend de ton boulot, si on te demande de faire des requêtes SQL a la chaine, ou d'optimiser des requêtes existantes, ou la même chose pour des algorithme. En fonction, le niveau de réflexion requis n'est pas le même.
Sachant que parfois, je trouve qu'il est même bon de prendre un papier et d'aller de poser devant un thé dans la salle de pause ou sur l'herbe pour réfléchir a un problème.
A courir après la rapidité, je pense qu'on perd en qualité. Mais bon, il faut de tout pour faire un monde.
Quitte à paraphraser certains intervenants sur ce sujet, je considère également que les tests que peuvent faire passer les entreprises sont inadéquats.
Je comprends bien que les recruteurs aient besoin d'une base pour juger le candidat, et d'autant plus s'ils ne sont pas experts en la matière.
Pour reprendre des exemples qui m'ont paru aberrant... Il y a par exemple les QCM ou codes à pondre avec des parties en Java, .Net, C++, XML...
Très honnêtement, s'il y a des employeurs ici, pouvez-vous me dire combien d'entre vous utilisent ces quatre langages dans leur entreprise ?
De plus, je considère que la programmation passe d'abord par une analyse et par une logique pour répondre à un problème donné. Ensuite qu'on l'écrive en Chinois, en Grec ou en Tamoul ça ne fait pas de différence, il suffit de prendre un dico.
Enfin, les développeurs sont aujourd'hui assez spécialisés. Je travaille personnellement dans une petite SSII et on a, en gros, un expert par langage...
Ensuite, et même si ça a déjà été dit, le gros inconvénient de genre de test est qu'ils font l'impasse sur l'adaptabilité d'une personne. Quelqu'un qui va faire des fautes sur un test parce qu'il ne s'est jamais retrouvé face à une certaine situation n'est pas mauvais pour autant. Ce qui importe c'est à quelle vitesse, en condition de travail réel, il saura trouver une solution à ce problème. (D'ailleurs on m'a toujours dit qu'on apprenait plus de ses erreurs que de ses réussites)
Enfin le dernier problème que je vois, et pas des moindres, est que ça ne laisse pas beaucoup de place pour les jeunes entrant sur le marché du travail. On a beau faire des exercices pratiques en cours, ça ne reflète en aucun cas une situation réelle en entreprise. Un jeune, même sortant d'une école, doit encore apprendre... Et trop souvent on voit des offres d'emplois demandant un jeune de moins de 26 ans, BAC+5 avec 3 ans de spécialisation en 27 langages et 43 ans d'expérience professionnelle. (Bon d'accord j'exagère, mais seulement un peu)
Je me souviens que je répondais à ces annonces en demandant à l'employeur de quelle façon je pouvais avoir de l'expérience professionnelle si aucun d'entre eux ne proposaient de poste pour débutant.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager