Doit-on soumettre les vétérans à des tests de programmation avant embauche ?

Ne devrait-on pas créer des tests spéciaux pour les vétérans comme Ted Neward ?
Que ce soit pour les novices ou les vétérants : OUI, je dis ça par expérience.
Malheureusement, depuis que je travaille j'ai rencontré pas mal de profil avec qui j'ai du travailler, et ce que j'en ai retenu c'est de ne pas se fier au CV ;)
Le cv donne une idée du profil, mais il ne faut surtout pas hesiter à le verifier, et pour cela, un bon test est le bienvenue, apres un test comme dans la news:non trop complexe

Quelle serait la meilleure manière pour évaluer les compétences d’un programmeur ?
Le test qui suit concerne un programmeur web:
On indiquer au candidat qu'il va avoir 45 minutes dans une salle avec un pc non connecté à internet, avec juste la documentation du language (php/java...)
Un serveur web, une base de donnée.
Et qu'il doit réaliser un CRUD avec ceci
Ce qu'il faut analyser avant l'épreuve

1. Estime-t-il avoir le temps de le faire
2. Si non, quelle partie pense-t-il avoir le temps de faire ?
3. Quels questions pose t il avant de se mettre à l'ouvrage

Les éléments à analyser après l'épreuve

1. A t il terminer les parties qu'il pensait faire ?
2. Si non, ou en est-il ? (loin pas loin de la fin) il est bon de voir où il estime en etre et voir ensuite la situation réelle (trop optimiste, plutot juste...)
3. Si non, pourquoi ? pas assez de temps ? à perdu du temps sur un bug (simple/complexe...)
4. Ensuite annalyser le code produit (avec/sans commentaire, organisé en plusieurs fichiers ou tout dans le meme code, noms des variables...)
5. L'application fonctionne-t-elle ?
6. Que ferait-il si il avait plus de temps (interessant de voir son sens critique et ses idées d'évolution, sa vision sur la sécurité...)

Après selon le niveau on sera plus ou moins regardant sur la dernière partie (on en demandera plus à un vétéran qu'à un novice ;)

Avec un simple tableau d'occurrences si je comprends bien la question...
Voir ici : http://jsfiddle.net/3fcCs/

"Ne devrait-on pas créer des tests spéciaux pour les vétérans comme Ted Neward ?"

Soit on considère qu'on peut faire confiance à la compétence d'un vétéran, soit on considère qu'il faut la tester. Mais des "tests spéciaux", je ne comprends pas trop ce que ça veut dire...

"Quelle serait la meilleure manière pour évaluer les compétences d’un programmeur ?"

Une méthode que j'avais imaginé, c'est de fournir un problème complexe, dans le genre de celui de l'article, la veille au candidat, par mail. Et non pas de simplement recevoir une solution, mais d'avoir une discussion libre sur la manière de résoudre le problème. De cette façon, si le type ne comprend rien au sujet, ça va vite se voir. Ca a l'avantage de ne pas prendre le candidat au dépourvu. Ca ne m'intéresse pas de voir comment un candidat peut résoudre un problème de ce type en 5 minutes, parce que s'il est embauché, il aura plus de temps que ça pour résoudre les sujets qu'il aura à traiter. Je ne le vois donc pas à son avantage, et finalement, ça revient à rejeter des candidatures parfaitement valables.

"Pouvez-vous donner une solution au problème d’ensembles disjoints du vétéran ?"

Ca n'a pas l'air difficile à résoudre. Par contre, ça doit être franchement difficile à résoudre de façon optimale. Il y a dans ce problème un vrai sujet combinatoire. Tant qu'on traite 3 ensembles de 3 éléments, tout va bien, mais si on se retrouve avec 432542445 ensembles de 567787697 éléments, ça va moins bien se passer.

En gros, il faut chercher les intersections d'ensembles : les 3 ensembles simultanément puis chaque paire de 2 ensembles. Pas la peine de détailler, si ? On doit même pouvoir faire un truc pas trop mal récursivement, si on a envie.
Par ailleurs, il faut trouver les éléments qui ne sont dans aucune intersection : on part d'une liste dédoublonnée des tous les éléments de tous les ensembles, et on retire ceux qui sont dans une intersection

Pour un algo plus générale : pour N ensemble de k éléments, on cherche l'ensemble intersection des N ensembles, puis de toutes les combinaisons de N-1 ensembles, puis N-2 ensembles, etc. Et à chaque fois, on retire des ensembles les éléments de chaque intersection.

Cela dit, l'exemple fourni de 3 ensembles à 3 éléments ne permet pas de comprendre toutes les règles de gestion : si j'ajoute un 3eme ensemble {2, 3, 6}, il se passe quoi ? Selon ce qu'on cherche à faire, pour 1 et 2, on peut attendre dans les ensembles résultat soit {1, 2} et {2} ; soit {1, 2}, {1}, {2} ; soit {1} et {2}. Tous les ensembles ont-ils forcément le même nombre d'éléments ? Etc. Non, en fait, des ensembles disjoints, c'est clair. Ca veut dire que leur intersection est l'ensemble vide. Donc on peut le faire pour des ensembles de n'importe quelle taille. Chaque élément ne peut se retrouver que dans un ensemble résultat. Dans mon exemple, pour 1 et 2, ça donnerait {1} et {2}. Cela dit, l'exemple de l'employeur pourrait être plus parlant.

Cela dit, dans l'exemple de l'article, on pourrait aussi donner comme réponse { 1 } , { 2 } , { 3 } , { 4 } et { 5 }. Ce sont aussi des ensembles disjoints. Il manque donc bien une règle. J'imagine que ça doit être un truc comme "obtenir aussi peu d'ensembles finaux que possible" ou un truc dans le genre.

Au niveau de la complexité, ça doit être O(n!), en fonction du nombre d'ensembles.

Citation:

---

Envoyé par FrontLine

Je trouve que les tests sont nécessaires, faut-il encore que les tests soit proche du besoin de l'entreprise et pas des tests fouareux pour faire du test comme c'est souvent le cas.

J'ai eu droit une fois à 30 min pour :
- répondre à une dizaine de questions techniques (html, jquery, css3, mysql et php)

- analyser une table d'environ 40 tables et autant de champs dans quelques une (sérieux!) et faire des big jointures avec sous-requêtes.

- faire une page avec un slide show.

J'ai failli partir avant de commencer en voyant ce tests démoralisant. Finalement j'ai pas finis (aucun candidat n'a pue d'ailleurs), j'ai eu le poste mais bon le test reflétait la mentalité et la façon de travailler attendu (objectif irréalisable et que des projets mal conçu à reprendre (mini 30 tables sur chaque projet comportant un espace membre et 3 / 4 conneries classiques) ...



Non, si le tests répond à une réelle attente. Le vétéran correspond ou pas au poste.


Faire faire exactement le style de dev que le développeur devra réaliser avec un temps imparti réaliste à ce qui sera son quotidien si il est pris.

---

J'ai souvent remarqué que ce qu'on voyait dans une entreprise au moment de l'entretien d'embauche était très révélateur de l'ambiance dans la boite une fois embauché...

De toutes façons, si la boite atteint une certaine taille, ton premier "mur" à passer est soit le chasseur de têtes, soit la boite de recrutement, soit les RH. Et dans tous ces cas, l'interlocuteur est généralement incompétent dans le domaine sur lequel tu postules. Il réfléchit à partir de mots-clés et de phrases-type.
Conclusion de premier niveau : savoir embobiner le premier interlocuteur, afin d'atteindre le vrai décideur et de "parler franc".

J'ai eu mieux : un recruteur sachant décoder un cv en 2s (super le gars), étant d'accord avec mon approche (est-on capable de s'adapter ou pas), mais coincé par ce que le client (une Grosse boite) veut recruter au moins 5 ans d'xp sur un domaine qui n'existe en Europe que depuis 5 mois...

Je ne suis vraiment pas convaincu par les arguments en faveur des tests techniques. Je reste persuadé que ça permet au recruteur technique de se faire mousser un peu.
Pour moi, on peut discuter technique avec le candidat sur son CV, on arrive déjà bien à voir si la personne maîtrise son sujet. Pour en revenir à l'exemple sur le sort de cryptographie, c'est pas bien compliqué en quelques questions de savoir si le mec comprend ou pas ce qu'il raconte.
Après pour moi le plus important, on embauche un être humain pas une machine. Le feeling c'est le plus important, car on va bosser avec la personne tous les jours.

Citation:

---

Envoyé par fr1man

Je ne suis vraiment pas convaincu par les arguments en faveur des tests techniques. Je reste persuadé que ça permet au recruteur technique de se faire mousser un peu.

---

Malheureusement, aujourd'hui c'est nécessaire, j'ai déjà eu deux très mauvaises surprises, dont le pire fut le dernier en date:
Sur le papier, un vétérant (temps par l'age que par les années d'expériences...), l'entretient c'est bien passé, et c'est en commençant à travailler avec lui:
On a l'habitude dans ma boite de donner les specs, les lignes directrice puis de faire confiance au développeurs pour travailler son code, puis au bout d'un certain temps (plus ou moins long selon les projets) on présente ce que l'on a déjà développé (afin de recadrer si besoin et bien vérifier qu'on se comprend entre la MOA et les devs
Régulièrement on lui demandait si ça allait, qu'il hesite pas si il avait des questions... il posait des questions de temps en temps... ou avait des bugs assez simple à résoudre, mais bon un autre oeil est souvent bénéfique ;)
On lui a fait confiance, sur le cv il etait bon, et avait beaucoup d'années d'expérience
Et puis à un moment j'ai voulu avoir une vision réelle du travail effectué, et j'ai demandé à mon +1 d'organiser une démo car le nouveau m'inquiétai
Et lors de la démo ce fut la catastrophe: non seulement on avait des erreurs bloquante php, mais lorsque l'on eu fini de regardé la premiere page, et là on clique là et ?? (ah bah non il avait pas fait ça encore, juste le html :(

donc les tests techniques oui ;)

Citation:

---

Envoyé par fr1man

Après pour moi le plus important, on embauche un être humain pas une machine. Le feeling c'est le plus important, car on va bosser avec la personne tous les jours.

---

Le feeling c'est importante et ça se voit en entretien, mais c'est pas un pote qu'on embauche mais un collègue qui doit avant tout être compétent pour le poste.
Le feeling c'est après les compétences :) (et oui c'est toujours plus sympa de travailler avec des collègues avec qui on s'entend bien ;)

Déjà que je ne suis pas fan des tests, même s'il est vrai qu'ils offrent de sacrées surprises de temps en temps, je déteste encore plus ça lorsque ça concerne un vieux. Je trouve que c'est un manque de respect et que c'est carrément insultant.

Quelques articles de mon blog sur des sujets similaires :

Représentation d’une liste en String
http://blog.developpez.com/todaystip...iste-en-string

Stop aux QCM techniques en entretien
http://blog.developpez.com/todaystip...s-en-entretien

Kata Digital Romain
http://blog.developpez.com/todaystip...digital-romain

Certaines sociétés proposent des tests bien plus complets à leurs candidats, à préparer à la maison. C'est notamment le cas de l'exercice des tondeuse dont je vous propose une version modifiée :
http://www.icauda.com/files/genielog...u_du_lapin.pdf

@imikado
Quand je dis feeling, je ne pense pas seulement, est-ce que la personne est sympa. Je pense à son caractère, à ce qu'elle aime faire, sur les idées qu'on peut partager, enfin plein de choses... Ça peut en dire beaucoup sur sa manière de travailler, parce que j'ai du mal à croire que l'on puisse être deux personnes très différentes au boulot et dans sa vie perso.
Et ça c'est beaucoup plus important que de savoir si elle a pu répondre à un test foireux que j'ai pris le temps de concocter tranquillement dans mon coin.
Après encore une fois je ne suis pas pour les tests écrits, ni ceux derrière une machine, et encore moins ceux faits a la maison, mais plutôt pour un échange oral. C'est quand même pas très dur de coincer un mec qui a mis des mots dans son CV qu'il ne comprend pas.

@fr1man oui pour le feeling, il faut egalement verifier que le candidat n'est pas psychorigide...
Mais pour l'exemple des compétences, le cas dont je parle, la personne avait une quarantaine d'année (et l'experience qui va avec) et il connaissait techniquement php, javascript sql ...
Mais c'est en travaillant avec qu'on a pu se rendre compte
1. qu'il buttait sur des problèmes simple qui lui faisait perdre des heures avant qu'il me demande à moi ou un autre collègue de le débloquer en quelques secondes (je parle vraiment de bugs simple de "debutant"
2. qu'il avait une mauvaise estimation ou ne savait pas du tout estimer une charge et s'y tenir :(
3. que lorsque tu lui demandais, "tout allait bien" et pourtant au bout du compte on était obligé de reprendre des parties qu'il devait developper (faisant perdre du tps sur le planning) :(

Avec mon test du CRUD en 45 minutes évoqué plus haut, on l'aurait vu tout de suite ;)

Ne devrait-on pas créer des tests spéciaux pour les vétérans comme Ted Neward ?

Non. Je suis comme lui, je déteste les tests de programmation sur papier. Surtout qu'ils n'ont rien à voir avec la réalité du terrain. A quoi va-t-il me servir de connaître par coeur la syntaxe d'un langage ?

Quelle serait la meilleure manière pour évaluer les compétences d’un programmeur ?

Le faire travailler pendant 1 jour ou 2 sur un petit projet, en conditions réelles. Pas 30 minutes ou 1 heures. Un jour. Cela permet de voir comment le développeur voit la conception et la réalisation d'un projet répondant à une problématique précise. Le développeur a sa façon de s'organiser et a surtout pris l'habitude d'utiliser intelligemment les outils à sa disposition. Ca ne l'empêche pas d'avoir des compétences et des connaissances (notamment syntaxes de base, algorithmie, concepts, design patterns) et de creuser par documentation. Ca ne l'empêche pas non plus d'ailleurs de finir dans les temps.
Au travail c'est le résultat qui compte. Ce qu'on te demande en 30 minutes à l'entretien, en général on le facture une matinée en condition réelle, si ce n'est plus.

Pouvez-vous donner une solution au problème d’ensembles disjoints du vétéran ?

Voici 3 méthodes, imaginée du haut de mes (à peine) 2 ans d'expérience :

- Imaginons que je sois en .NET. Alors je fais une requête LINQ en intersect sur les 3 collections, en ressortant un dictionnaire avec les indexes et leurs valeurs associées. Et je refais une requête LINQ dessus pour récupérer tous les indexes qui se suivent, même si il y en a qu'un.

- Sinon, on peut faire la même chose dans un fichier XML ou une base de données et requêter en XPATH ou SQL.

- Le plus compliqué consiste à parcourir la première liste et la tester sur les deuxièmes et troisièmes listes aux mêmes indices. Si on trouve les 3 pareils, dans un tableau associatif avec les composants des listes, on indique TRUE, sinon FALSE (pour les 3).
A la fin on parcourt notre tableau et dès qu'on trouve un TRUE, on en fait un ensemble tant qu'il y a des TRUE. Dès qu'on trouve un FALSE, l'ensemble est terminé et on continue pour trouver le suivant.

Citation:

---

Envoyé par LSMetag

Ne devrait-on pas créer des tests spéciaux pour les vétérans comme Ted Neward ?

Non. Je suis comme lui, je déteste les tests de programmation sur papier. Surtout qu'ils n'ont rien à voir avec la réalité du terrain. A quoi va-t-il me servir de connaître par coeur la syntaxe d'un langage ?

---

D'où l'idée de donner au candidat un ordinateur et une documentation ;) (mais pas internet)
Je suis d'accord que demander de coder sur papier n'est pas pertinent: on peut faire des fautes : il est plus difficile de se corriger sur papier que numériquement ;)
Essayez d'ajouter une ligne entre deux sur papier :aie:

Citation:

---

Envoyé par LSMetag

Quelle serait la meilleure manière pour évaluer les compétences d’un programmeur ?
Le faire travailler pendant 1 jour ou 2 sur un petit projet, en conditions réelles. Pas 30 minutes ou 1 heures. Un jour.

---

Je ne sais pas si vous avez déjà eu à recruter, mais personnellement j'ai vu défiler beaucoup de profils différents, car on travaille régulièrement avec des SSII pour avoir des développeurs en renfort.
Régulièrement (dans l'année) on doit recevoir plusieurs profils et arriver à estimer assez rapidement si il correspond ou non (au moins à son CV), on ne peut pas se permettre de tester chacun d'entre eux 2 jours :(
Ce test c'est juste pour filtrer, après, il va être briefer sur la société, participer aux réunions, lire les spécifications... tout cela dure quelques jours avant qu'il puisse réellememnt commencer à coder ;)

Citation:

---

Envoyé par imikado

D'où l'idée de donner au candidat un ordinateur et une documentation ;) (mais pas internet)
Je suis d'accord que demander de coder sur papier n'est pas pertinent: on peut faire des fautes : il est plus difficile de se corriger sur papier que numériquement ;)
Essayez d'ajouter une ligne entre deux sur papier :aie:


Je ne sais pas si vous avez déjà eu à recruter, mais personnellement j'ai vu défiler beaucoup de profils différents, car on travaille régulièrement avec des SSII pour avoir des développeurs en renfort.
Régulièrement (dans l'année) on doit recevoir plusieurs profils et arriver à estimer assez rapidement si il correspond ou non (au moins à son CV), on ne peut pas se permettre de tester chacun d'entre eux 2 jours :(
Ce test c'est juste pour filtrer, après, il va être briefer sur la société, participer aux réunions, lire les spécifications... tout cela dure quelques jours avant qu'il puisse réellememnt commencer à coder ;)

---

Je ne suis pas d'accord. Si vous voyez 10 candidats dans la journée, faites un entretien RH puis un entretien technique. Et si vous avez encore un doute, donnez lui un défis à renvoyer par mail soit pour la fin de la journée (si on est le matin, soit le lendemain midi si on est le soir). Lisez son code en diagonale et vérifiez que ça marche. Ok il peut avoir fait faire le test par quelqu'un d'autre. Mais au contraire, il suffit qu'un très bon dev ne gère pas très bien le stress du temps limité (ou ait une connaissance macro et utilise les docs pour le micro) pour qu'il se plante. Le pire c'est que ce n'est pas représentatif de ce qu'on lui demandera et qu'il serait capable de le faire dans des conditions "normales".

Pour moi, rien ne vaut le débat technique avec un expert pour voir si le développeur est "bon". A mes yeux, connaître une syntaxe ce n'est pas être bon. Connaître des concepts, savoir les utiliser à bon escient, savoir s'adapter rapidement à de nouvelles syntaxes, pouvoir défendre un point de vue de façon valable, voila ce qui montre qu'on est bon.

Citation:

---

Envoyé par LSMetag

Je ne suis pas d'accord. Si vous voyez 10 candidats dans la journée, faites un entretien RH puis un entretien technique. Et si vous avez encore un doute, donnez lui un défis à renvoyer par mail soit pour la fin de la journée (si on est le matin, soit le lendemain midi si on est le soir). Lisez son code en diagonale et vérifiez que ça marche. Ok il peut avoir fait faire le test par quelqu'un d'autre. Mais au contraire, il suffit qu'un très bon dev ne gère pas très bien le stress du temps limité (ou ait une connaissance macro et utilise les docs pour le micro) pour qu'il se plante. Le pire c'est que ce n'est pas représentatif de ce qu'on lui demandera et qu'il serait capable de le faire dans des conditions "normales".

Pour moi, rien ne vaut le débat technique avec un expert pour voir si le développeur est "bon". A mes yeux, connaître une syntaxe ce n'est pas être bon. Connaître des concepts, savoir les utiliser à bon escient, savoir s'adapter rapidement à de nouvelles syntaxes, pouvoir défendre un point de vue de façon valable, voila ce qui montre qu'on est bon.

---

Je suis d'accord, mais le minimum qu'on lui demande c'est de savoir estimer a peu pres une charge de travail, communiquer dessus et surtout essayer un minimum de s'y tenir.
Dans mon exercice on demande un CRUD car ce n'est pas compliqué en soit, ce qui est important c'est les points que j'avais indiqué avant de commencer coder, après avoir fini, ce qu'il a réussi à pondre, et enfin ce qu'il ameliorerait (débat ouvert)
Le coup de demandé à pondre un exercice et le renvoyer par email est identique à lui laisser un accès internet pendant l'exercice :(
L'exercice est suffisament simple pour ne pas avoir besoin d'aide autre que la documentation ;)

Quand vous dites de faire un test seulement si on a un doute, c'est la le problème: les entretients des personnes que l'on a prise se sont toujours bien passé, c'est lorsqu'on est rentré dans le vif du sujet, qu'ils ont du commencer à coder que l'on (moi ou d'autres collègues) se sont apercu du problème :( (trop tard: plus le temps de refaire passer des entretiens)
Car malheureusement on ne fait pas passer 10 entretiens par jour, on travaille, on doit dégager du temps pour ses entretients, donc c'est plutôt 1 voir 2 par semaines :(

Citation:

---

Envoyé par erwanlb

Gné ?

---

Ca veut juste dire que j'équilibre les caractères et talents dans mon équipe.

J'évalue un peu tout, mais échouer a une question ne vous met aps dehors, loin de là.

Le test me sert au final a plusieurs choses :
- évaluer si le niveau correspond a celui attendu en lisant le CV. (le nombre d'année d'expérience n’étant pas du tout un bon révélateur... 3 ans dans des petites boites sont souvent bien plus formatrice que 10 dans une banque...)
- Évaluer les connaissances théorique de base, ce qui me permet d'équilibre l'équipe. Avoir 3 gars qui savent normaliser une base, c'est un plus... mais en avoir 1, c'est indispensable. Autrement ca donne des bdd de normalisée parce qu'on atteignait 1 Millions de lignes dans la base et que c'est trop... (comme les gars sont nul, ils trouve un trucs pour se dédouaner alors qu'un simple regard sur la base montre l'étendue des dégâts)... De la même façon, si personne n'a de réflexe de programmation objet dans une équipe... on est pas dans la merde pour partir sur un projet dans un langage basé sur ce concept...
- Voir si le candidat s'auto évalue bien... je leur donne en effet une feuille avec un tableau de compétences. Sur chacune d'elles, ils doivent me mettre une croix sur le niveau qu'ils pensent avoir(non connu, connait le mot, novice, a utilisé la techno, a utilisé la techno dans un projet from scratch, expert). Là, on a une base sympa pour discuter...

Citation:

---

Envoyé par LSMetag

Quelle serait la meilleure manière pour évaluer les compétences d’un programmeur ?

Le faire travailler pendant 1 jour ou 2 sur un petit projet, en conditions réelles. Pas 30 minutes ou 1 heures. Un jour.

---

Donc, une entreprise cherche un developpeur experimente. Mettons un veteran. Donc elle publie une annonce, recoit des CVs, fait le tri, et en retient 5.
Donc elle convoque les 5, mais pas en meme temps car il faut passer du temps avec la personne, et que recevoir les 5 en meme temps, c'est vraiment nul.
Donc tu as un developpeur qui ne fait rien d'autre pendant une semaine, plus le temps de preparation...

Et ensuite, il se trouve que ces 5 developpeurs ne vont pas se deplacer pour rien, surtout s'ils sont en poste. La moindre des choses est de leur dedomager la journee de congee qu'ils posent. A 4 000 euro par mois, ca fait 225 euro par jour, et c'est pas cher paye -- sachant que je ne sais meme pas comment tu peux justifier ce paiement legalement, puisque tu n'es pas cense travailler pour un autre employeur lors de tes conges.

Ca commence a faire cher la session de recrutement, tu ne trouves pas ?

Citation:

---

Envoyé par Cedric Chevalier

Récemment, le vétéran a été soumis à un test ou il devait créer un algorithme pour trouver les ensembles disjoints d'une collection d'ensembles et calculer le Big O notation de sa solution en termes de temps et de mémoire consommée. Les ensembles du problème étaient { 1, 2, 3 }, { 1, 2, 4 }, { 1, 2, 5 }, et les résultats devaient être les ensembles { 1, 2 } , { 3 } , { 4 } et { 5 } .

---

Je conseillerais d'utiliser les possibilités du langage.

J'ai eu à traiter des comparaisons d'ensemble en Java.
Ici, on pourrait
- fusionner les 3 ensembles de base dans un set (valeurs uniques) -> {1, 2, 3, 4, 5} (E1)
- pour chaque ensemble E de départ, copier E1 et faire un removeAll(E) -> chaque ensemble {3}, {4}, {5}
- reprendre E1 et soustraire les ensembles {3}, {4}, {5} -> {1, 2}

Algorithme linéaire, donc complexité O(n).

En SQL, encore plus simple : ce langage est ensembliste (UNION, INTERSECT, MINUS...).


En développement, on n'est pas censé recréer des algos à chaque fois, mais utiliser nos outils.

Citation:

---

Envoyé par gangsoleil

Pour la plupart de ces metiers, il est demande aux postulants des lettres de recommandation des anciens employeurs, avec les coordonnees pour les joindre. Tu preferes ca ?

---

Personnellement, oui je préférais ça, de très très très loin.. :)

Pourquoi dans l'informatique cela n'est pas la norme, alors qu'ialleurs ça l'est ??


Ou, alternative, que les recruteurs téléphonent aux références mentionnées sur le CV..


L'une des 2 solutions éliminerait totalement le problème des CVs trafiqués, et quand on suit les statistiques que plus de 40% des gens aujourdhui en France mentent sur leur CV, ça ferait pas de mal.. (et j'ai eu l'occasion de voir des SSII trafiquer mon propre CV).


Je n'ai jamais eu rien à cacher, je me suis toujours comporté correctement, je ne vois pas en quoi avoir une lettre de référence ou un coup de tel à mon ancien employeur serait dégradant, dangereux, ou quoi que ce soit d'autre..

C'est simplement parfaitement naturel...

Citation:

---

Envoyé par imikado

Malheureusement, aujourd'hui c'est nécessaire, j'ai déjà eu deux très mauvaises surprises, dont le pire fut le dernier en date:
Sur le papier, un vétérant (temps par l'age que par les années d'expériences...), l'entretient c'est bien passé, et c'est en commençant à travailler avec lui:
On a l'habitude dans ma boite de donner les specs, les lignes directrice puis de faire confiance au développeurs pour travailler son code, puis au bout d'un certain temps (plus ou moins long selon les projets) on présente ce que l'on a déjà développé (afin de recadrer si besoin et bien vérifier qu'on se comprend entre la MOA et les devs
Régulièrement on lui demandait si ça allait, qu'il hesite pas si il avait des questions... il posait des questions de temps en temps... ou avait des bugs assez simple à résoudre, mais bon un autre oeil est souvent bénéfique ;)
On lui a fait confiance, sur le cv il etait bon, et avait beaucoup d'années d'expérience
Et puis à un moment j'ai voulu avoir une vision réelle du travail effectué, et j'ai demandé à mon +1 d'organiser une démo car le nouveau m'inquiétai
Et lors de la démo ce fut la catastrophe: non seulement on avait des erreurs bloquante php, mais lorsque l'on eu fini de regardé la premiere page, et là on clique là et ?? (ah bah non il avait pas fait ça encore, juste le html :(

donc les tests techniques oui ;)


Le feeling c'est importante et ça se voit en entretien, mais c'est pas un pote qu'on embauche mais un collègue qui doit avant tout être compétent pour le poste.
Le feeling c'est après les compétences :) (et oui c'est toujours plus sympa de travailler avec des collègues avec qui on s'entend bien ;)

---

Des tests techniques sur un mec très compétent qui n'en glande pas une aurait donné le même résultat...passe les tests et n'arrive pas à te sortir la 2ème page :mrgreen:

Et j'y vois surtout un problème au niveau des responsables de ce mec...qui finalement ne sont pas vraiment responsables...mais je doute que la remise en question se soit faite à ce niveau ? :mouarf:

Citation:

---

Envoyé par imikado

Avec mon test du CRUD en 45 minutes évoqué plus haut, on l'aurait vu tout de suite ;)

---

Ou pas.....

Je trouve que c'est une sacré faiblesse pour un recruteur de croire qu'avec des tests il va détecter un glandeur, un mec lent (ce qui ne veut pas dire incompétent), un mec qui traverse une période de merde, etc...

Il y a des tests pour recruter des recruteurs ???? On passe au travers il me semble !!!!! :aie: