Quel image donnes-tu des finistériens, hein?! (et j'aime beaucoup la première proposition du correcteur de firefox pour ce mot: "ministérielle", si ça c'est pas un signe...)
Le fait est que la tchatche ne fonctionne pas à tous les coups. Tu peux toujours tomber sur un bleu dans une grande ville. Mais il ne faut pas oublier que l'univers des RH / commerciaux n'est pas très grand. Et les noms circulent.
Si tu es fiché dans une ville moyenne comme un beau parleur qui fait un boulot catastrophique et qui s'est fait envoyer balader parce qu'il a frappé le chef de projet avec une chaise, tu n'as plus qu'à déménager.
THIS!IS!NOT!MY!COW!
CECI!N'EST!PAS!MA!VACHE!
(mais je persiste à dire que c'est moins classe en français )
Oui, enfin je ne parle pas de moi, je parle bien mais je bosse bien aussi
Après, je parle plutôt de métier où on peut facilement baratiné, moins technique que notre métier, ou là je reconnais qu'il est plus difficile de passer des entretiens un minimum sérieux sans avoir quelques questions pointues et donc ou on ne peut pas tricher. Mais j'ai vu dans d'autre métier des personnes étant plus à l'aise à l'orale passer devant des personnes moins à l'aise mais plus qualifier et plus compétant au travail. Je trouve cela dommage. Il fraudait quand même s'intéresser au compétence réelle de la personne plutôt que de passé 10 minutes à parler de la pluie et du beau temps et de faire ça à la tête du client.
Savoir parler est aussi une qualité non négligeable pour travailler correctement dans une entreprise de plus d'une personne .
dam's
Je pense personnellement que le mieux, c'est de parler d'un cas de projet hypothétique.
Par exemple, « Si vous deviez refaire dailymotion/youtube/google, comment feriez vous ? ». Ça marche avec n'importe quel gros projet.
Les problèmes techniques auxquels on n'a pas pensé de prime abord sont nombreux sur un tel projet, et cela permet de tester le candidat. Comment organiser le taff pour bosser en équipe sur le projet ? Comment gérer la scalabilité ? Qu'est ce que vous feriez comme DAL (data access layer) ? Ce genre de question.
Et puis, discuter avec le candidat des points problématiques, de là où ça risque de coincer. Ça devrait donner une bonne idée de s'il sait où il va, s'il a de l'expérience pour voir les problèmes arriver, etc . . .
Peut importe qu'il n'ait pas la solution de suite, ce n'est pas un magicien, mais s'il sait bien identifier le problème, qu'il est capable de donner les idées générales pour de résoudre, il faudrait creuser par la suite, on sait que l'on a à faire à quelqu'un de compétant.
deadalnix, oui, c'est pas une mauvaise idée, ça sonde le candidat de façon assez générale, je trouve ça plutôt bien.
dams78, oui c'est sûr, je suis d'accord, mais ça se travail aussi.
C'est une bonne idée, mais uniquement si c'est dans un domaine à peu près similaire et que tu lui as laissé un peu de temps avant. Parce que quelqu'un qui est capable de te répondre du tac au tac sur ce genre de question, c'est sûrement un baratineur.
Le problème, c'est que ça fait un peu trop oral de français, et ça peut faire fuir certains (dont moi probablement).
(wooh! J'ai appris un mot: "Scalabilité" (sans la faute))
THIS!IS!NOT!MY!COW!
CECI!N'EST!PAS!MA!VACHE!
(mais je persiste à dire que c'est moins classe en français )
Presque d'accord. Moi qui fait de la gestion bancaire grand système, je suis infoutu de comprendre les tenants et aboutissants de ce genre d'applis. Par contre, si on me demande de refaire complètement l'informatique d'une grande banque, là j'ai des solutions dans ma besace(à affiner, évidemment).
Mais "du tac au tac", on peut aussi tomber sur quelqu'un qui a déjà réfléchi au sujet, et qui pond en 5 minutes une solution complète. Ca m'est arrivé(enfin, sur un sujet bien plus restreint), et ça n'était pas du baratin, juste de la préparation.
En même temps, savoir communiquer c'est important, surtout quand on est amené à concevoir des choses.
Les 4 règles d'airain du développement informatique sont, d'après Michael C. Kasten :
1)on ne peut pas établir un chiffrage tant qu'on a pas finalisé la conception
2)on ne peut pas finaliser la conception tant qu'on a pas complètement compris toutes les exigences
3)le temps de comprendre toutes les exigences, le projet est terminé
4)le temps de terminer le projet, les exigences ont changé
Et le serment de non-allégiance :
Je promets de n’exclure aucune idée sur la base de sa source mais de donner toute la considération nécessaire aux idées de toutes les écoles ou lignes de pensées afin de trouver celle qui est la mieux adaptée à une situation donnée.
Mais je me pose la question suivante :
N'est-il pas mieux de lui soumettre un cas - Votre client est une société lambda spécialisé dans le truc, qui cherche à faire du web...; qui exprime quelques contraintes du client; certaines normales, d'autres où tu attends qu'il réagisse et les infirmes, et lui demander de préparer une réponse de 2/3 pages sur comment il s'y prendrait et de la faire relire par un expert ?
Non ?
J'ai finalement vu 3 candidats en entrevue aujourd'hui et voici les conclusions.
Sur les 3, il y avait 2 universitaires supposément doués avec les principaux langages et bases de données mais finalement ils n'avaient aucune expériences concrètes, ne connaissaient pas la définition d'un CMS et n'ont jamais travailler avec cela.. Même si ils avaient répondu oui à la pré-entrevue.
Ces 2 mêmes candidats avaient supposément une formation en référencement et n'ont pas su répondre aux critères de bases d'un bon positionnement de site web dans Google. (exemple: des backlinks)..
En ce qui concerne le questionnaire. Je leur ai expliqué d'avance que c'était pour me faire une idée générale de leurs connaissances afin de les ciblés dans nos domaines d'activités. Ils ont bien pris cela.
L'autre candidat n'était pas francophone d'origine et le test semble l'avoir plutôt énervé. Je voyais son impatience et son attitude qui disait " pourquoi tu me fais perdre mon temps à me faire remplir ce foutu questionnaire ".
Je l'ai tout de même laisser soupirer à quelques reprises et comme j'avais eu le temps d'analyser sa bonne posture et son agilité sur le clavier, je lui ai proposé de discuter des points restant à l'oral et je lui ai expliqué clairement le but qu'il y avait derrière chacune des questions. Il a changé d'attitude à ce moment et à finalement bien prit cela. Les réponses qu'il a donné dans le questionnaire sont également toutes excellentes.
Le seul point qui m'embête est au niveau de la communication car l'anglais serait notre langue de communication mais ce n'est pas notre langue maternelle à aucun de nous deux.
Je vais donc continuer de rencontrer d'autres candidats et si, au final, son test demeure le plus pertinent, je le prendrai à l'essai quelques jours.
Comme je peux constater, le test est donc utile pour faire ressortir les compétences majeures et les principaux aspect du profil du candidat mais il n'en demeure pas moins une manière de s'aiguiller..
Il reste plusieurs facteurs à voir sur le terrain face à différents projets et complications.
Je vous remercie tout de même pour toutes les idées que j'ai pu tiré de cette discussion.
A+
Juste pour vous dire que j'ai finalement décidé de mettre à l'essai le candidat en question et qu'à la suite de 2 semaines, celui-ci répond parfaitement à mes attentes.
Chose qui ne se serait sans doute pas produite si je m'aurais basé uniquement que sur une évaluation de la programmation.
Il faut se rappeler que ce n'est pas parce qu'un gars est bon en programmation qu'il est débrouillard, autonome et polyvalent dans son environnement.
Il est donc, à mon avis, important d'élaborer un petit questionnaire afin de pouvoir avoir une idée de la personnalité du candidat.
Bonne chances dans vos embauches!
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.
Partager