Discussion :

[c4ever]

Que des balivernes à mon avis
Ils sont dans l'erreur et la mal façon dès le début.
Quoi? ils veulent des analystes qui savent coder???
On code pour répondre à un besoin précis, défini et analysé. Ainsi au lieu de demander aux candidats de coder ils n'ont qu'à leur demander de décripter le besoin à partir du code, ensuite leur faire faire du code ou de l'optimisation ou le déboguage d'une pièce de code et ainsi joindre l'efficience à l'éfficacité.
Ils prennent les gens pour des cons apparemment, des gens qui se jettent à l'eau immédiatement sans réfléchir Ils n'en veulent plus de cela, par ce que les grandes boites qui recrutenet en sont pleins à craquer, des codeurs pour qui on réfléchit et on leur donne le projet bien taillé pour qu'ils le codent. hahaha
Balivernes, balivernes

[Zirak]

Complètement d'accord avec le 1er message de Saverok.

Pour moi il est beaucoup plus important de voir la capacité d'analyse d'un dev (quitte à lui demander de pondre un algo en pseudo code pour voir comment il ferait dans les grandes lignes), que sa capacité à pisser du code dans un langage particuliers.

Comme il a déjà été dit, le langage et l'environnement de travail peuvent changer d'une entreprise à l'autre et l'on ne peut pas tous les connaitre, sauf qu'un bon dev, saura s'adapter (en plus ou moins de temps suivant les personnes) à un nouveau langage ou un nouvel EDI, voir s'il maitrise son langage c'est bien mais c'est secondaire.

Le principal c'est de savoir analyser la logique métier et pouvoir l'implémenter. Tout le reste, la plupart du temps, c'est du déjà fait, et on ne réinvente pas la roue à chaque fois, si j'ai besoin d'envoyer un mail, je reprendrais le code du projet précédent si je l'ai déjà fait, ou j'irais chercher sur le net car je me douterais bien que quelqu'un l'a déjà fait, et ensuite je l'adapterais (encore une fois, c'est le principal atout du dev, savoir s'adapter), je ne vais pas recoder une fonction d'envoi de mail à chaque projet.

Oui je connais les fonctions basiques de mon langage, mais je ne suis pas un "super-expert-de-la-mort" qui connait tout le langage de A à Z dans ses moindres recoins, cela ne m'empêche pas de travailler, de trouver la fonction dont j'ai besoin le cas échéant, ou de changer de langage quand le besoin s'en fait sentir...

[serenodo]

Merci Saverok, pour ton message si franc.
Les diplômes je les aient, mais j'ai 52 ans reconnu travailleur handicapé et diplômé depuis 2011, en France les DRH n'aiment pas ceux qui savent rebondir suite à un accident de travaille rendant invalide à 40 %.
Et je ne parle pas de mes collègues programmeurs qui sont en fauteuil roulant.
Quel gâchis en puissance , trop de perte de compétences.
Dans mon travaille actuel, je suis mis de côté par les programmeurs ou développeurs, depuis qu'ils connaissent mes compétences.
En France si un employé est plus compétent que son chef , c'est la guerre.
En France si un employé est plus performant que le DRH qui le reçoit, c'est perdu d'avance pour lui.
Chez 99% des programmeurs ou développeurs c'est une passion, 80% sont autodidactes.
Bonne route à vous tous quelque soit le langage de prédilection.

[Traroth2]

Que des balivernes à mon avis
Ils sont dans l'erreur et la mal façon dès le début.
Quoi? ils veulent des analystes qui savent coder???
On code pour répondre à un besoin précis, défini et analysé. Ainsi au lieu de demander aux candidats de coder ils n'ont qu'à leur demander de décripter le besoin à partir du code, ensuite leur faire faire du code ou de l'optimisation ou le déboguage d'une pièce de code et ainsi joindre l'efficience à l'éfficacité.
Ils prennent les gens pour des cons apparemment, des gens qui se jettent à l'eau immédiatement sans réfléchir Ils n'en veulent plus de cela, par ce que les grandes boites qui recrutenet en sont pleins à craquer, des codeurs pour qui on réfléchit et on leur donne le projet bien taillé pour qu'ils le codent. hahaha
Balivernes, balivernes

Retrouver la fonction à partir du code ? C'est terriblement difficile sans connaitre le contexte de l'entreprise sur le bout des doigts, et en une heure, c'est juste impossible.

[Saverok]

@serenodo
Indirectement, je comprends un peu ta situation.
Je me prends très régulièrement le choux avec ma DRH car lorsque je rédige une fiche de poste, je ne renseigne que des savoir-faire et des savoir être.
Puis, l’annonce qui est émise est retravaillée par le service RH en gonflant l’expérience demandée ainsi qu’en imposant des niveaux d’études…
Du coup, je ne reçois que des candidats aux profils et parcours très standardisés alors que la richesse d’une équipe vient de la diversité…

En France, et cela touche tous les domaines et n’a rien de spécifique à l’informatique, les RH n’aiment pas les individus aux parcours atypiques.
Cela est particulièrement regrettable car c’est une source de richesse incroyable d’avoir des expériences variées qui offrent une ouverture d’esprit et des angles de vues différents sur une même problématique.

[serenodo]

@Saverok,
Merci cela fait chaud au coeur de lire ton message.
Il est vrai que c'est pour toutes les profession, quand j'étais chef de cuisine je n'ai pas connu cela car le métier demandait de la passion du courage et l'envie d'apprendre tous les jours.
Maintenant il faut un bac + 2 pour travailler chez les plus grands.
Alors comme je suis têtu , j’apprends Python en autodidacte, car dans les annonces les diplômes sont moins élevés que pour mon diplôme de C#
Je travaille pour une grosse entreprise Française de l'état, et si tu savais le nombre d'appel que j'ai parce-que leurs plateformes ne fonctionnent pas sous IE 9 11 , Firefox, Chrome. il en existe une qui gère les paiements mais ne fonctionne que Sur IE8. Même un script vba est difficile pour eux.
Tu sais combien gagne un développeur dans cette société!!!!!
Bonne route à toi et garde le sourire

[Luckyluke34]

Comme tout ce qui est fait par des recruteurs c'est du grand n'importe quoi !!!!

Ce n'est pas un recruteur mais Eric Lippert, programmeur qui a fait partie de l'équipe à l'origine du langage C# et lead developer sur le compilateur C# pendant longtemps.

On va faire quoi dans un entretien d'une heure sur un tableau blanc ?

Des exercices du genre implémenter une table de hachage, un programme qui mélange les éléments d'un tableau, etc. comme indiqué dans le blog.

Comme il le dit également, l'idée n'est pas de vérifier la syntaxe ou de faire que ça "compile" sur le tableau blanc mais de voir le raisonnement du candidat dans les grandes lignes et si c'est globalement propre et bien réfléchi.

Ca ne me parait pas totalement déconnant comme approche.

[Jitou]

Evaluer un candidat à un poste technique en informatique comme on ferait un casting pour un concours de chant ne répondra certainement pas au besoin de l'entreprise sur la durée. On recherche bien autre chose sur les projets que des compétences techniques bruts comme mentionné dans l'article. D'ailleurs très peu de RH on une idée précise de ce qui se passe dans un projet au quotidien et de la manière les différents protagonistes interagissent.

La capacité d'une personne à collaborer dans une équipe et être force de proposition mais aussi être porteur d'une certaine capacité de composer avec différents tempéraments sont des atouts majeurs pour bien avancer sur les projets. Les compétences purement techniques sont vraiment secondaires, on sait très bien que l'on peut être au top sur une techno sur un projet et devenir une bouse sur une autre techno sur le projet suivant et pourtant il faut faire avec et ça tous les décideurs opérationnels des SSII le savent très bien. Donc c'est là que le fonctionnement en équipe et pas en tant que compétiteur est crucial pour qu'une équipe projet fonctionne.

J'ai vu trop souvent des soit disant cracks recrutés uniquement pour l'étalage de leurs compétences techniques sur leur CV et qui étaient sur le terrain des projets incapables d'échanger avec d'autres qu'ils considèrent incompétents, souvent arrogants dans leur attitude et parfois suffisamment perfides pour verrouiller des composants du projet afin de démontrer leur toute puissance.

[bmoraut]

Bonjour,

Je ne sais pas chez qui vous avez postulé, mais les tests techniques j'en ai rarement fait.
Et pour cause:
La plus part des recruteurs que j'ai rencontré, ne connaissent rien en informatique.
En quand il y en a un qui un des connaissances, bien qu'elles peuvent être très pointues, elle sont très partielles et partiales, il est sur une technologie très très spécifique, qu'il croient connaitre, ou sur une technologie dépassée.

La plus part des cabinets de recrutement son incompétents, et son seulement intéressé par des programmeur capable de sortir du code rapidement, au prix de justement la clarté, maintenabilité etc...

Voir au contraire, il n'en veulent pas, pour revendre des prestations.

Leur seul intérêt est que le client voit apparaitre des écrans.

Ensuite, si ils peuvent revendre un deuxième intervenant pour corriger ce qu'à fait le premier, c'est tout bénef.

Cordialement

[ChristianRoberge]

Personnellement, j'aime poser des questions techniques hyper difficiles en entrevue. Habituellement, les candidats sont incapable d'y répondre techniquement sur le vif. En fait, ce n'est pas tant ses compétences techniques qui sont jugés mais ses capacités à résoudre des problèmes et surtout son attitude envers ce type de problème. J'ai déjà rencontré un candidat qui, après avoir répondu à aucune question, s'est choqué directement envers moi! Le bon candidat, s'intéresse au problème et se montre curieux. S'il me retourne la question en me disant quel que chose du genre: "Problème intéressant, quelles solutions pouvons-nous y apporter?", il vient de réussir son entrevue car il me démontre que:
1- Il n'est capable d'affronter, sans paniquer, des problèmes difficiles;
2- Qu'il a une bonne capacité de travaille en équipe car il pose des questions
3- Qu'il est curieux et qu'il a le souci de s'améliorer.

Des questions sur le BABA du codage ne m'intéresse pas car il va de soi que les candidats connaissent les réponses. On ne mesure alors que le sang-froid et la nervosité du candidat. S'il n'a pas les connaissances de base, ce qui arrive hélas quelque fois, il me donnera une réponse fausse et non argumenté à mes questions difficiles car il ne soupçonne pas ou peu la difficulté de ces dernières. Donc, il ne faut jamais passer des entrevues avec des questions techniques faciles...

[nnovic]

Personnellement, j'aime poser des questions techniques hyper difficiles en entrevue. Habituellement, les candidats sont incapable d'y répondre techniquement sur le vif. En fait, ce n'est pas tant ses compétences techniques qui sont jugés mais ses capacités à résoudre des problèmes et surtout son attitude envers ce type de problème. J'ai déjà rencontré un candidat qui, après avoir répondu à aucune question, s'est choqué directement envers moi! Le bon candidat, s'intéresse au problème et se montre curieux. S'il me retourne la question en me disant quel que chose du genre: "Problème intéressant, quelles solutions pouvons-nous y apporter?", il vient de réussir son entrevue car il me démontre que:
1- Il n'est capable d'affronter, sans paniquer, des problèmes difficiles;
2- Qu'il a une bonne capacité de travaille en équipe car il pose des questions
3- Qu'il est curieux et qu'il a le souci de s'améliorer.

Des questions sur le BABA du codage ne m'intéresse pas car il va de soi que les candidats connaissent les réponses. On ne mesure alors que le sang-froid et la nervosité du candidat. S'il n'a pas les connaissances de base, ce qui arrive hélas quelque fois, il me donnera une réponse fausse et non argumenté à mes questions difficiles car il ne soupçonne pas ou peu la difficulté de ces dernières. Donc, il ne faut jamais passer des entrevues avec des questions techniques faciles...

Un peu tordu comme raisonnement. Si j'étais un candidat dans cette situation, j'aurais tendance à penser que, vu les questions posées durant l'entretien, je n'ai pas les compétences pour le poste et que le recruteur est un charlot pour m'avoir fait déplacer pour rien. Il ne faut pas non plus oublier que l'entretien est aussi l'opportunité pour le candidat d'évaluer son futur employeur. Donc si je trouve que l'entretien est farfelu: je fuis !

[BufferBob]

Personnellement, j'aime poser des questions techniques hyper difficiles en entrevue. Habituellement, les candidats sont incapable d'y répondre techniquement sur le vif. En fait, ce n'est pas tant ses compétences techniques qui sont jugés mais ses capacités à résoudre des problèmes et surtout son attitude envers ce type de problème. J'ai déjà rencontré un candidat qui, après avoir répondu à aucune question, s'est choqué directement envers moi! Le bon candidat, s'intéresse au problème et se montre curieux. S'il me retourne la question en me disant quel que chose du genre: "Problème intéressant, quelles solutions pouvons-nous y apporter?", il vient de réussir son entrevue car il me démontre que:
1- Il n'est capable d'affronter, sans paniquer, des problèmes difficiles;
2- Qu'il a une bonne capacité de travaille en équipe car il pose des questions
3- Qu'il est curieux et qu'il a le souci de s'améliorer.

Des questions sur le BABA du codage ne m'intéresse pas car il va de soi que les candidats connaissent les réponses. On ne mesure alors que le sang-froid et la nervosité du candidat. S'il n'a pas les connaissances de base, ce qui arrive hélas quelque fois, il me donnera une réponse fausse et non argumenté à mes questions difficiles car il ne soupçonne pas ou peu la difficulté de ces dernières. Donc, il ne faut jamais passer des entrevues avec des questions techniques faciles...

ben pour ma part je suis 100% d'accord, j'imagine que passé un certain age ça relève simplement du bon sens, la vie en entreprise est rarement faite de cas d'école et nécessite des capacités d'adaptation minimum, chercher à évaluer le raisonnement logique, la démarche scientifique ou simplement l'attitude du candidat prend tout son sens, particulièrement dans les petites structures où la même personne devra évaluer à la fois les compétences techniques et relationnelles du candidat

@nnovic, ce que tu dis -pour reprendre tes mots- c'est qu'en te rendant compte que tu ne sais pas répondre tu penserais que c'est le recruteur qui est un charlot, c'est bien ça ?

[nnovic]

@nnovic, ce que tu dis -pour reprendre tes mots- c'est qu'en te rendant compte que tu ne sais pas répondre tu penserais que c'est le recruteur qui est un charlot, c'est bien ça ?

C'est bien ça. Si je ne suis pas capable de répondre à ses questions, c'est qu'il a mal ciblé son recrutement. Il aurait du s'apercevoir dès la lecture de mon CV que je n'avais pas le profil correspondant aux questions qu'il pose.

Et je le répète, l'entretien d'embauche ça marche dans les deux sens. Le recruteur évalue le candidat autant que le candidat évalue le recruteur. En posant des questions tordues, le recruteur prend le risque de passer pour un tordu et de faire fuir un candidat qui aurait pu correspondre au poste.

[Zirak]

S'il me retourne la question en me disant quel que chose du genre: "Problème intéressant, quelles solutions pouvons-nous y apporter?", il vient de réussir son entrevue car il me démontre que:
1- Il n'est capable d'affronter, sans paniquer, des problèmes difficiles;
2- Qu'il a une bonne capacité de travaille en équipe car il pose des questions
3- Qu'il est curieux et qu'il a le souci de s'améliorer.

Ou qu'il brode le temps de réfléchir à un début d'explication

Je ne vois pas comment à partir de ce bout de réponse (qui est seulement le fait de répéter tes mots, technique de communication relativement répandue), tu arrives à déduire tout ça de la personne mais bon pourquoi pas.


Et puis bon, j'imagine mal un candidat à un entretien répondre "ce genre de problème n'arrivera pas / est trop simple, passons à la question suivante.", bien sûr qu'il va te dire que c'est une bonne question, et essayer de broder un truc, qu'il sache répondre ou non.


Et à l'inverse, celui que ta question va faire encore plus stresser tellement elle est difficile, alors qu'il n'est déjà pas forcément en position confortable, et qui du coup va un peu perdre ses moyens et passer à côté du truc, va rentrer chez lui en pensant qu'il est nul et en se dévalorisant car il n'aura répondu à rien, et aura encore plus de mal à son prochain entretien...

Qu'un développeur sache faire face au stress ou à une problématique complexe oui c'est normal et cela fait partie de son boulot, la dessus je suis d'accord avec toi.

Maintenant, le stress (voir même plutôt l'adrénaline) résultant du fait de devoir faire face à une nouvelle problématique et de réussir à la résoudre n'est pas comparable au fait de mettre le candidat dans une position de panique lors d'un entretien professionnel qui définira peut-être une grosse partie de sa vie.

Face à un problème de développement, même avec un planning serré, on a plus de temps, on peut chercher des solutions à plusieurs, ou sur le net, on peut essayer d'y réfléchir à tête reposée, etc etc et surtout tu ne risques pas forcément ton avenir professionnel. Alors que ton problème insurmontable sur lequel il faut répondre en 5mn, et qui va conditionner le fait que la personne va avoir un boulot, ou peut-être rester à galérer au chômage voir sans revenus, cela n'a rien à voir.


Perso, si le poste ne demande pas une expertise technique immense, et qu'arrivé en entretien, je vois que tu me poses des questions dignes d'un expert avec 20 ans de bagages, je vais me dire que tu es encore le genre de personne qui ne maitrise pas complètement son sujet, qui veut un demi-dieu (voir un dieu complet) payé comme un débutant, et je ne m'attarderais pas plus que ça.

Pour moi, les questions doivent être en adéquation avec le niveau du poste et servent à vérifier l'expérience que prétend avoir le candidat. Après tu peux monter en difficulté au fil des questions pour essayer de cerner le niveau de la personne, mais attaquer direct par et ne poser que des questions dont tu sais qu'il ne pourra pas y répondre, cela me fait juste penser à un sadique qui aime torturer les gens

[el_slapper]

(.../...)Et je le répète, l'entretien d'embauche ça marche dans les deux sens. Le recruteur évalue le candidat autant que le candidat évalue le recruteur. En posant des questions tordues, le recruteur prend le risque de passer pour un tordu et de faire fuir un candidat qui aurait pu correspondre au poste.

C'est un risque réel. J'ai passé assez peu d'entretiens techniques, j'ai beaucoup aimé ça, mais je connait pas mal de vétérans qui pensent qu'ils ont déjà fait leur preuve, et que ce genre de "conneries"(je cite) fait fuir. Et beaucoup étaient des éléments de valeur. J'ai aussi eu une chef qui se plantait systématiquement à tous les tests, mais qui comme dev faisait quand même l'affaire. Elle avait un blocage psychologique, je crois : pour elle, test = échec.

Un commercial de SSII qui m'avait formé aux entretiens me disait "un entretien, c'est comme deux chiens qui se reniflent le derrière - chacun doit plaire à l'autre. Tu dois absolument plaire, par tous les moyens". Mais il n'avait même pas réalisé que moi aussi je pouvais être rebuté par le client. Enfin, je n'ai jamais dit "non" à une mission, mais j'ai envoyé chier un grand cabinet de consulting US qui ne m'aurait pas payé plus que les SSII lambda, mais qui exigeait en plus "au minimum une heure de veille technologique chaque soir". Hors horaires de travail ou rémunération, bien sur. Ma femme était enceinte. J'ai poliment décliné "je ne pense pas pouvoir faire face à votre niveau d'exigence". A une époque ou mon profil s'arrachait.

[Saverok]

ben pour ma part je suis 100% d'accord, j'imagine que passé un certain age ça relève simplement du bon sens, la vie en entreprise est rarement faite de cas d'école et nécessite des capacités d'adaptation minimum, chercher à évaluer le raisonnement logique, la démarche scientifique ou simplement l'attitude du candidat prend tout son sens, particulièrement dans les petites structures où la même personne devra évaluer à la fois les compétences techniques et relationnelles du candidat

@nnovic, ce que tu dis -pour reprendre tes mots- c'est qu'en te rendant compte que tu ne sais pas répondre tu penserais que c'est le recruteur qui est un charlot, c'est bien ça ?

Personnellement, je suis comme ChristianRoberge, j’aime pousser les candidats dans leurs retranchements car à un moment donné, on n’évalue plus les compétences techniques mais le savoir être du candidat.
J’aime quand un candidat me dit « je ne sais pas » mais plus encore « pour répondre à cela, je pense qu’il faudrait aller voir telle source ou tel service métier, etc ».
On a parfaitement droit de ne pas savoir et surtout, c’est une grande qualité d’avoir l’humilité de le reconnaître.
Ce qui compte surtout, c’est comment on se comporte face à ce genre de situation : est-ce se braque ? est-ce qu’on abandonne ? est-ce qu’on tente de découper le problème ? où on va chercher l’info ? etc.

Lors de mon dernier entretien technique en tant que candidat, il a duré 2h et j’ai passé plus de temps à répondre « je ne sais pas mais … » qu’autre chose.
Je suis sorti de là dépité et persuadé de m’être totalement planté.
Et pourtant, j’ai eu le poste et lorsque je suis arrivé dans la société et que j’ai revu l’architecte qui m’a fait passer l’entretien technique et que j’ai débriefé avec lui, il a répondu : « ce qui compte, ce n’est pas de répondre à une question, c’est de chercher une solution ».

Alors oui, tu as parfaitement raison : dans un entretien, l’entreprise et le candidat s’évaluent mutuellement.
Personnellement, quand j’ai rencontré des sociétés où l’entretien technique se faisait par un RH, j’ai dit basta.
Par contre, si un candidat se vexe et prend la mouche parce que je l’ai poussé dans ses retranchements lors de l’entretien technique, je donne mon veto au RH sur cette candidature. Non pas à cause du savoir-faire (car il peut avoir les compétences techniques) mais à cause du savoir être qui n’y est pas.
Comme dit par d’autres dans des postes précédents, le savoir-faire est assez secondaire car s’acquière alors que le savoir être, c’est tout autre chose…

[Luckyluke34]

Comme dit par d’autres dans des postes précédents, le savoir-faire est assez secondaire car s’acquière alors que le savoir être, c’est tout autre chose…

J'ajouterais aussi le savoir-apprendre qui est crucial quand on veut faire évoluer son savoir-faire

Et je pense qu'il y a quand même un bagage technique plancher au-dessous duquel on ne peut pas recruter, à moins de pouvoir se permettre 6 mois / 1 an de non-productivité pour mettre à niveau la personne.

[benicourt]

Le candidat idéal doit être « une personne bien organisée avec de bonnes compétences en résolution de problèmes »: oui tout à fait d'accord avec ça...
Le coup du tableau blanc, c'est vrai que c'est pas cool non plus - un bon dev a aussi besoin de ses outils pour bosser.

[Zirak]

On a parfaitement droit de ne pas savoir et surtout, c’est une grande qualité d’avoir l’humilité de le reconnaître.

Oui, mais pour 1 recruteur comme toi qui va considérer cela comme une qualité, combien de recruteur vont juste se dire "il ne sait pas répondre, il n'a pas les compétences pour le poste" ?

Ce que je veux dire ce qu'il ne faut pas mettre dans la tête des gens que c'est rien du tout si on ne connait pas les réponses lors des entretiens techniques. En théorie oui, ce n'est pas grave, du moment que l'on sait s'adapter au problème, mais comme pour beaucoup de chose qui se passe en théorie, ce n'est pas forcément ce qui domine dans la réalité. En général, les recruteurs / la direction, n'aiment pas trop les aveux d'incapacité à faire quelque chose ou à résoudre une problématique.

Il ne faut pas oublier que souvent pour la direction, problème = coûts, donc si ils te demandent et que tu réponds "je ne sais pas faire", "je ne sais pas quand cela sera fonctionnel", etc etc , ça passe moyen quand même.


Ne pas savoir, n'est pas une honte, mais il faut savoir le mettre en forme dans sa façon de le dire et éviter tout ce qui est à connotation négative.

Typiquement pour reprendre ton exemple, plutôt que de répondre "«je ne sais pas, pour répondre à cela, je pense qu’il faudrait aller voir telle source ou tel service métier", il faut partir sur un truc plus "positif" et qui laisse plus transpirer la confiance en soi.

"Si un point bloquant de ce type survient, j'irais consulter mes collègues afin de savoir s'ils ont déjà connu ce type de problématique et comment ils l'ont résolu, sauf si ce point bloquant concerne essentiellement un aspect métier, auquel cas je me dirigerais plutôt vers l'interlocuteur du service concerné."

=> pas de négation, pas de conditionnel / d'hésitation, etc etc

A mon avis, cela passe mieux, on avoue à demi-mot ne pas être capable de résoudre le problème seul mais sans vraiment le dire, et on montre directement qu'on ne se laisse pas abattre et que l'on sait rebondir.

[GeoffreyOnRails]

C'est un risque réel. J'ai passé assez peu d'entretiens techniques, j'ai beaucoup aimé ça, mais je connait pas mal de vétérans qui pensent qu'ils ont déjà fait leur preuve, et que ce genre de "conneries"(je cite) fait fuir. Et beaucoup étaient des éléments de valeur. J'ai aussi eu une chef qui se plantait systématiquement à tous les tests, mais qui comme dev faisait quand même l'affaire. Elle avait un blocage psychologique, je crois : pour elle, test = échec.

Dans les différentes boîtes dans lesquelles je suis allé, on a toujours considéré que c'était un risque à prendre. Je ne parle pas nécessairement d'entretiens de 4heures sur tableau blanc, mais au moins de discussions techniques sur divers problèmes.
De mon point de vue, ne pas recruter un bon élèment n'est pas dramatique. Il y en a d'autres, certes ça obligera à faire passer plus d'entretiens, ça mettra peut-être plus de temps, mais rien d'insurmontable. En revanche, recruter un mauvais élèment, ça peut plomber une équipe pendant très longtemps. Le but n'est pas de détecter tous les "bons" ou même le meilleur qui passe devant soi, le but est d'en trouver un suffisament brillant et motivé parmi les dizaines (centaines?) de candidats pour bien faire le travail.

Pire que ça, dans l'une des sociétés par lesquelles je suis passé (petite PME), la phihlosophie de la boîte était (entre autre) de s'entre-aider à progresser, et accepter de se faire challenger (en entretien ou au quotidien), y compris par plus jeune que soi, était considéré comme un prérequis indispensable au progrès. Nous considérions qu'il y avait toujours des domaines dans lesquels apprendre des autres. Peu importe les années d'expériences, seules les compétences comptaient. Du coup, ça n'était pas vraiment un risque de ne pas obtenir ces "vétérans", sans doute talentueux par ailleurs, mais qui étaient "trop vieux pour ces conneries", c'était complètement voulu. Et on en a vu passer plusieurs des comme ça, sans jamais le moindre regret.

Au final, je pense qu'il n'y a pas UN bon recrutement, cela dépend de la philosophie de l'entreprise (et du poste)

Enfin, je n'ai jamais dit "non" à une mission, mais j'ai envoyé chier un grand cabinet de consulting US qui ne m'aurait pas payé plus que les SSII lambda, mais qui exigeait en plus "au minimum une heure de veille technologique chaque soir". Hors horaires de travail ou rémunération, bien sur. Ma femme était enceinte. J'ai poliment décliné "je ne pense pas pouvoir faire face à votre niveau d'exigence". A une époque ou mon profil s'arrachait.

Pour moi, ce que tu dis là, c'est le signe d'un entretien réussi, vous n'étiez pas fait pour bosser ensemble, et à l'issue de l'entretien vous le saviez. Si il ne te l'avait pas dit, cela aurait pu aboutir à un gros fiasco, car ce qu'ils attendaient était supérieur à ce que tu aurais accepté de donner.