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
J'estime que sans forcément être grand un expert (ce n'est en effet pas son travail), un chef de projet doit savoir un minimum de programmation pour savoir ce qu'il gère.Envoyé par Priato
En effet, demander de coder sur papier n'est pas une bonne idée.
Personnellement, j'ai eu droit à des programmes à réaliser et envoyer avant l'entretien ou à des questionnaires.
A mon boulot on a des QCM à l'entretient d'embauche, bon pas en tant que développeur mais en tant qu'administrateur par contre
Ce minimum tu le définis comment ? Un mec qui durant 10 ans a été chef de projet (et un bon) doit il forcément connaitre le dernier langage/plateforme à la mode ? Et dans ce cas le minimum c'est quoi, savoir créer une fenetre? savoir faire une boucle if ? Qu'est ce que ca apportera dans un véritable projet si ce n'est que l'équipe de developpeur (experte) se foute de sa gue**.
Développeur et chef de projet sont 2 metiers bien disctinct qui nécessite des aptitudes bien disctinct.
Qu'ils aient mis un chef de projet à corriger des bugs là je me dis qu'il y a problème. Je me dis que soit cette boite ne savait pas vraiment quel genre de profil qu'elle recherchait ou soit elle fait parti des boites qui recherchent des superman pour pas un rond. Et dans ce cas elle n'a eu que ce qu'elle méritait. Il faut savoir ce que l'on veut soit on cherche un bon développeur ou soit cherche un bon chef de projet.
Enfin, un mec qui a un super CV, ca se vérifie facilement, tu contactes directement les boites pour lesquelles il a bossé, si il a été mauvais ca ce sait rapidement.
Au final je pense que la boite en question a été mauvais dans son recrutement, non pas parce qu'il n'ont demandé au mec de faire du code mais parce que :
- il cherchait probablement à la fois un super développeur et un super chef de projet
- leur backreferencing a été particulièrement mauvais.
- lorsqu'on discute avec un développeur ca se sent pas la peine de lui demander de faire du code
- lorsqu'on discute avec un chef de projet ca se sent aussi
c'est mon avis
Coder lors d'un entretien pourquoi pas. Le test de Traroth2 me semble à la porté de n'importe quel vrai développeur sans faire perdre de temps (ça doit prendre 10 lignes et 2 minutes grand max). Ça permet d'éliminer les "menteurs".
Pour ma part mon pire entretien : le recruteur, après avoir discuté un peu, m'a fait répondre à un dizaine de questions sur le langage Java :
-Java est un langage :
-> Bon évidemment il est compilé en Bytecode mais ensuite c'est moins clair (JIT, tout ça). Et puis généralement quand on parle de compilation c'est en langage machine. Donc que répondre quand c'est un QCM ? J'ai mit les 2 me disant que je pourrai expliquer ma démarche lors de la correction, il attendait compilé et m'a sortie "ba oui javac c'est pour compilateur Java donc c'est compilé et puis c'est tout"1) compilé 2) interprété ?
-Comment transformer un int a en String ?
-> WTF ??? J'ai répondu, en écrivant à coté "" + a et String.valueOf(a). Le recruteur attendait a.toString(), comme quoi Java était un langage objet, donc tout était objet et comme Object avait une méthode toString(), il fallait s'en servir et surtout ne pas ajouter de réponse à un QCM.1) a.toString() 2) a.asString() 3) a.string() 4) new String(a)
Le recruteur (surement un développeur C# qui s'était que Java était pareil) n'avait jamais entendu parler de type primitif...
Tout ça pour dire que la technique dans un entretien (code ou autre), je ne suis pas contre mais à condition que le recruteur maitrise réellement son sujet. Sinon on se retrouve avec des questions aberrantes et une "correction" encore pire
EDIT : @lequebecois79 : Je viens de faire le test en version beta (pas besoin de s'enregistrer). J'espère juste que le vrai test est meilleur. La plupart des questions sont très ambiguëes (on ne sait pas toujours ce qui est demandé). Bon c'est peut-être pas pour rien que ce test est en version beta
Mais j'ai surtout l'impression que le test est plus là pour piéger les candidats que pour tester ses réelles connaissances/compétences. Du genre utiliser un print alors que 95% du temps on utilise println. Bon j'ai passé 24minutes sur les 42 autorisées mais je suis tombé dans pas mal de piège de ce genre... Résultat 15/28 dont 7, 8 questions où soit je suis tombé dans un piège, soit je ne toujours pas convaincu par la réponse
pour java il y a http://www.blackbeltfactory.com
j'avais fait passé le test débutant et un test maison
tous les candidats avait de 2 à 4 ans d'expériences ont échoué, ça fait peur
Indispensable...
Je fais passer des entretiens depuis plus de 5 ans et je trouve les questions techniques avec du code... indispensables. Il y a trop de CVs bidonnés.
On voit aussi certains candidats très stressés pour les questions "généralistes" et se décontracter totalement avec les questions techniques.
J'ai des questionnaires un peu pour tous les profils dont nous avons besoin: Java, PHP, Unix, C, etc...
Je teste mes questionnaires sur mes collègues avant, et je n'attends pas du 100% de "bonnes réponses" des candidats (c'est arrivé 2 fois sur 30-40 entretiens) car les questions sont assez variées.
Pour Java par exemple, une partie du questionnaire consiste à expliquer des bouts de codes et les commenter du point de vue respect des standards, des conventions, lignes inutiles, efficacité, etc...
Certains diront que c'est assez subjectif, oui, mais le code à commenter est volontairement (très) mauvais sur tous les aspects et un code doit pouvoir être relu par quelqu'un d'autre! Alors celui qui me répond qu'il le trouve parfait et l'aurait lui même écrit ainsi, c'est une exclusion d'office...
En plus de 5 ans, on en a vu de toutes les couleurs...
Quelques exemples extrêmes:
- une personne qui ne savait répondre à rien: "Oui, ça fait un moment que je n'ai plus programmé en Java, mais laissez moi un mois et ça me reviendra"
- un candidat envoyé par une société de consulting comme expert C/C++: "Oui, j'en ai fait 2 mois à l'Université"
Alors, les questions avec du code à écrire, lire ou expliquer durant un entretien... indispensable...
Faire passer des tests c'est bien, mais discuter des résultats de ces tests avec le candidat et comprendre la façon dont il raisonne c'est mieux.
Ça permet ainsi de voir le potentiel et surtout la bonne compréhension de la personne...
Copier c'est copier; voler c'est vendre un CD une vingtaine d'euros!
Code C : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
Bonjour,
Moi je suis fondamentalement contre les tests techniques! Je postule régulièrement pour décrocher des missions de dev sénior/archi/CP (en moyenne, une dizaine par an). Il m'est arrivé deux fois de passer des tests techniques et la première fois je me suis dit que c'était également un moyen de mesurer mes compétences autrement qu'en situation de mission. Or je me suis retrouvé à devoir détecter des "static" manquants jusqu'à la question fatidique : donner un algorithme de tri d'un tableau de n-entiers... et là je me suis dit que je n'en rajouterais pas, au bout de 15 ans de carrière à invoquer la méthode "sort", je ne me rappelle plus de l'algo du tri à bulles vu en 2è année de DEUG!
Je n'ai jamais décroché de mission suite à ces deux entretiens car j'ai été mauvais et en sortant, c'est mon estime de moi qui en a pris un coup alors que j'ai toujours été apprécié pour mes compétences techniques dans toutes mes missions (ou alors on m'a menti!).
Depuis je refuse systématiquement les tests techniques, par contre, je négocie un entretien technique dans lequel je peux m'exprimer face aux pointures de la boîte susceptible de m'accueillir, je ne sais pas forcément répondre à tout mais cela permet d'exposer ma démarche.
Je suis intervenu dans une société qui faisait passer des questionnaires aux candidats et cela ne permet pas forcément de filtrer correctement: au cours de ma mission d'encadrement, j'ai tellement rencontré de recrues (~2 ans d'expé) avec un niveau ultra faible que j'ai été obligé de sensibiliser la direction sur le problème de fiabilité de leur process de recrutement.
J'ai participé également à des phases de recrutement et j'ai été amené à mener des entrevues techniques et là je trouve que la plupart du temps les candidats on du mal à valoriser leur profil car la marchandise la plus difficile à vendre c'est soi-même et la mésaventure exposée me semble loin d'être le cas général, bien au contraire.
C'est mon expérience et mon avis...
Ma femme a du coder 2 mini appli avec des point précis dans le fonctionnement pour faire l'entretient d'embauche.
C'est pas finalement une mauvaise idée.
Dur dur en tout cas d'écrire les test ...
On voulait un "simple" dev, je demande un exo super simple de gestion d'un retour d'un formulaire en php. J'ai sorti tous ceux qui avait menti sur le CV en mettant php alors qu'ils n'avaient suivi qu'un cours d’initiation, mais qui auraient pu l'apprendre en 2 secondes, et j'ai gardé LE gars qui savait faire ça ... mais qui n'a jamais rien pu apprendre de plus.
Sans allez jusqu’à l’exercice sur feuille, une première étape peut être de l'interroger sur des questions plus général du style :
"Quelle différence entre C++ et Java (s'il a mis ces 2 langages sur son CV par exemple)" voire plus "pointu":
''Qu'est ce que le polymorphisme?".
Bien sur ce n'est possible que si le recruteur à les compétences pour analyser les réponses.
Je le pratique pour recruter des stagiaires et c'est déjà un bon élément d'écremage si je puis dire.
Linux > *
Dans ma boîte, aucun des chefs de projet ne sait réellement coder.
Il y a ceux qui ont su, en fortran dans les années 80 quand ils sortaient des études. Ceux qui n'ont jamais été vraiment disposé à cette tâche et qui ont vite trouvé la porte de sortie pour devenir CP. Et ceux qui n'ont jamais su, et qui ont été catapulté là et se retrouvent à gérer des développeurs tout aussi bien que des cueilleurs de fruits rouges.
Chez nous, un CP c'est quelqu'un qui maîtrise excel, et qui partage son temps entre le téléphone et les réunions. Le CP te demande si tu es en retard, produit un fichier excel calculant ton retard, organise des réunions ou il montre des jolis diagrammes qui montrent clairement les différents retards qu'a prit le projet, et qui contribuent en grande partie à ce retard et donc à sa légitimité, et ainsi à son salaire bien plus élevé que le développeur lambda.
En cours, on m'avait expliqué qu'un CP en France, était très souvent issu du technique, à contrario des pays anglo-saxons.
Du coup, en vue de mon expérience ( en vue des précédents commentaires, tout le monde ne semble pas avoir ma "malchance" ) j'ai un peu de mal à comprendre l'étonnement de Richard Banks.
Pour ce qui est des tests, je suis pour si ceux-ci sont cohérents.
Je me suis vu répondre à un questionnaire C pour une mission estampillé C++.
Me planter littéralement sur un autre questionnaire C++ bourré de MFC, dont je n'ai aucune connaissance (sans aucun regret).
J'ai aussi effectué un C++ de deux heures plutôt corsé, et lutter avec les conteneurs STL vu que je sortais de 6 mois de full Qt (les différences sont faibles, mais difficiles à justifier ). Ce dernier m'a d'ailleurs un peu dégouté, avec un simple accès internet je me serrais bien débrouillé.
Un test technique est indispensable
Chez SoftFluent, nous avons rapidement introduit un test technique, car cela s'avère indispensable pour vérifier un minimum la réalité de ce qui est écrit dans les CVs.
Sans forcément demander de coder "en séance", la réponse à des questions de typologie et de niveau variés permettent au final d'avoir un assez bon aperçu du profil du candidat, que nous recoupons avec le questionnement de type "entretien" et le CV.
En ce sens, les incohérences sautent vite aux yeux et une zone d'ombre marquée signifie la fin du processus pour le candidat.
Mon conseil est d'éviter d'essayer de tricher, cela se paie au final. Pour nous, en tant que recruteur, il vaut mieux une incompétence connue qu'on peut travailler qu'une compétence usurpée ou surévaluée par le candidat.
A bon entendeur,
Daniel
Dans ma boite on demande aux candidats de développer des programmes complets lors des entretiens d'embauche.
On leur demande d'utiliser le langage de leur choix, les langages n'ont généralement pas d'importance quand on utilise des frameworks faits maison, et un bon programmeur est de toutes façons capable d'apprendre n'importe quel langage sur son temps de formation s'il est motivé.
Ils doivent faire premièrement une calculatrice polonaise inversée (pour tester la logique) puis une application graphique de gestion de contact (en partant du principe qu'un programmeur qui ne maitrise pas au moins UNE api graphique ne doit pas savoir grand chose).
Ils y passent souvent la matinée, mais on s'en fout
J'ai déjà vu mon faire cdp poser des questions en entretien sur certains compilateurs (genre celui de .net, son nom, ou on le trouve, ce qu'il est possible de faire avec), pour mesurer les connaissances du candidat. Mesurer les connaissances de l'éco système me semble une bonne pratique.
Tester les compétences, tout dépend la cible. Il y a des développeurs qui ne font jamais une interface graphique et restent dans des couches basses... Montrer des exemples de code et demander ce qui peut clocher, ou déterminer d'où vient un bug ainsi que le pourquoi peut aussi être intéressant.
Je suis categoriquement CONTRE les tests techniques en entretien d'embauche.
A fortiori pour un chef de projet.
Faire passer un test technique du genre "ecrire un programme complet" aui soit plus complexe qu'un Hello World, c'est juste... montrer vraiment peu de respect pour le candidat. C'est la solution de facilite. Idem pour les QCM...
Mais je suis absolument d'accord avec ce point : il faut évaluer les connaissances.
Mon point de vue (mais je ne suis pas recruteur hélas), est de, uniquement a l'oral, voir papier + crayon si le candidat veux dessiner quelque chose, demander :
"Comment feriez-vous pour ...".
Imaginer un quelqu'un qui ne connais que du C# postuler pour du Java. Oui d'accord, il va peut etre galerer la premiere semaine parceque en Java il y a une majuscule a une fonction, et pas C#.
Mais au dela de ca, si sa logique de programmation est bonne, si il connais suffisement la programmation objet independement d'un langage en particulier, ou est le probleme ? Il apprendra sur le tas comme énormement de tres bon employés.
The magic of Opera, La magie de l'Opera
The mysteries of Space Opera, Les mystères de l'Opera Spatial
Mr. Know-it-all, M. Je-Sais-Tout
Prelude in C sharp minor, the most beautiful piano song and the best C sharp prelude ever, Prélude en do dièse mineur, le plus beau morceau de piano et le meilleur prélude au C#
The Mesmerizing Saphir Division for Nerds, L'Hypnotisante Division Saphire pour les Nerds (HDSN)
Le but d'un entretien est d'en savoir un maximum sur les aptitudes d'un candidat. Partant de là, je ne vois pas pourquoi il faudrait proscrire les tests techniques.
Sur les chefs de projet : certes coder n'est pas leur mission numéro 1 mais c'est dérangeant qu'ils n'aient aucune compétence sur le projet qu'ils mènent. Prenons l'exemple des pilotes d'avion. Certes, il ne savent pas construire l'avion mais ils ont les connaissances pour bien savoir le piloter. C'est pareil pour les CP. Son but premier n'est pas de développer le logiciel mais d'avoir les compétences suffisantes pour savoir piloter sa conception, n'est-ce pas ? Pour eux, les tests seraient plus sur de la culture générale sur les domaines techniques que le projet abordera (en plus de tests pour Excel et MS Project).
T'aurais préféré quoi ? Un IDE avec l'autocomplétion qui va bien ? La compétence demandée porte sur un langage, pas un outil. Par exemple, savoir utiliser Adobe Dreamweaver ne fait pas d'un développeur un pro de l'HTML et/ou du CSS. Quant aux éditeurs classiques, cela revient, dans les conditions de l'entretien, à écrire à la main. Et puis écrire à la main plutôt qu'avec un clavier n'a jamais fait de mal à personne, surtout à l'orthographe.
+1. D'où quelques questions de logique pure qui viennent parfois se glisser dans ces tests. Mais il faut également garder à l'esprit que c'est quand même bien aussi si ton futur développeur sait coder son algo dans le langage qu'on lui demande.
+1. Tout le monde peut lire les langages les plus courants. Tout du moins raconter dans les grandes lignes ce qu'un programme écrit dans un langage avec une syntaxe plus ou moins orthodoxe (càd plus C, Pascal ou Python qu'Assembleur). Et pourtant, on n'a pas a priori autant de développeurs Pascal (même si c'est la saison) que de développeurs C.
"Ils ne savaient pas que c'était impossible alors ils l'ont fait." Mark Twain
Mon client Twitter Qt cross-platform Windows et Linux. (en cours de développement).
j ai un chtit soucis en rapport avec ce sujet dans un certain sens :
je ne connais pratiquement rien en programmation web mais je suis oblige de trouver du personnel qui aurai ces competences ... comment faire pour trouver de bon programmeur web ? php html css java flash ajax etc
je viens de lancer des hebergements web , mais mes clients veulent que je leur fournisse les sites ... si je ne trouve pas de solution pour reussir mon recrutement , je pourrai fermer mes serveurs ...
Les gens qui gonflent leur CVs sont des idiots car cela ne sert à rien !
c'est reculé pour mieux sauter dans le trou.
en revanche, quand on voit certaines offres où il est demandé à un développeur de connaître 10 base de données, 20 langages de programmation etc....
on se rend compte que les recruteurs sont vraiment de gros incompétents !!!
pour revenir au sujet, si j'étais patron de boîte et que je cherche un développeur je passerais forcément par un test de code si je cherche une personne connaissant un langage.
Autrement si je suis prêt à payer une formation je me pencherais sur d'autre critères.
Mais c'est mieux de demander à un développeur des questions qui n'ont aucun rapport avec le poste et le travail qu'il serait amener à faire !
du genre quelle est la couleur de vos sous vêtement vous voyez ce genre de question idiote poser par les recruteurs !!!
La Théorie c'est quand on comprends tout mais que rien ne fonctionne.
La Pratique c'est quand tout fonctionne mais qu'on ne sait pas pourquoi !
Si vous aimez ma réponse, cliquez sur la main verte Merci
Bien sur qu'on ne va pas demander à un chef de projet de connaitre les subtilités des langages récents. L'idéal pour un chef de projet est d'avoir une vision plutôt globale.
L'idée générale n'est pas de passer un examen, le test n'est pas noté. Il s'agit juste d'un test pour s'assurer la cohérence entre le CV et la réalité. Le test devra bien sur être nuancé par le CV et de ce que l'on attend du poste.
Il est vrai que l'exemple du sujet semble limite. Pour un chef de projet qui va diriger une équipe, le débogage n'est pas une priorité.
Si le recruteur a besoin d'un programmeur Java immédiatement opérationnel, c'est utile.
S'il peut se permettre de former le candidat, il doit tout simplement en tenir compte quand il lira le test (et en avertir le candidat pour éviter qu'il panique) et éventuellement l'autoriser à faire du C# dans son test.
La encore le test ne doit pas être un examen rigide et noté, mais juste un outil de décision qui doit être regardé a la lumière de la situation du candidat et du poste a pourvoir.
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