Discussion :

[imikado]

à moins d'avoir un projet opensource connu (comme symfony pour Fabien Potencier), des travaux intéressants sur github, ou des publications, votre nom n'est pas connu du recruteur et celui-ci ne peut pas faire une confiance aveugle à votre CV

Ceux qui sont contre les tests n'ont jamais eu à recruter des profils qui se sont avérés être loin de la réalité. Il faut que ça vous arrive au moins une fois avec les conséquences (reprise de son travail, horaires à rallonge à cause de lui...) pour que vous voyez l'intérêt de ce test

Moi, ce qui m'inquiète le plus, c'est que l'exemple que j'ai donné: dans notre entrepris il a été grillé (jusqu'à la MOA) mais derrière, il a été refilé à un autre client qui ne se doutait pas de qui l'attendait
Tout ça parce que son CV présente bien, qu'il a de l'expérience...
Il est assez kamikaze pour avoir accepté une mission d'aide express sur un projet en retard, sur un framework qu'il ne connaissait pas
Il faudrait presque un réseau social ou on indiquerait les profils à éviter

[fr1man]

Je participe aux entretiens techniques de ma boite, jusqu'à maintenant, je n'ai pas eu beaucoup de difficultés à démasquer le candidat qui en rajoute dans son CV.
Sans poser des questions bien compliquées, c'est rapide de voir si le mec sait de quoi il parle.
Après évidemment, quand on doit recruter sans rien y connaitre ce n'est pas simple.

[imikado]

Attention: il faut distinguer quelqu'un qui ment sur son CV (qui dit connaitre un langage / framework) qu'il ne connait pas
D'une personne qui connait effectivement ces éléments, mais une fois devant son clavier a du mal à se mettre à l'oeuvre, bute sur des erreurs php simples...
Et ça c'est très difficile à voir en entretien technique, après il faut peut etre préciser ce que vous entendez par là

Par exemple: ce candidat connaissait svn, mais lors d'une réunion lorsque j'ai commencé à dire que svn ne gérait pas les tags, il s'est offusqué, qu'il connaissait svn depuis longtemps et que bien sur que si svn gérait les tags...

Après avoir argumenté et expliquer par des exemples simples que ce n'était pas le cas, il a du avouer qu'il connaissait/utilisait svn QUE via turtoise SVN

[SoBaKa]

Hello tous le monde,

Honnêtement je pense que tous le monde se pose la mauvaise question. Autant les recruteurs que ceux qui vont passer un entretien.

Actuellement, j'ai un peu + de 5 ans d'expérience en tant que développeur .net et pendant plus de 2 ans, j'ai donné diverses formations que ce soit sur les bases du développement ou sur les nouvelles technos (développement wpf/windows 8) et j'ai réellement compris certaines choses quand je donnais les formations, choses qui peuvent paraître simple... Bon pour ma défense, je suis complètement autodidacte et je n'ai pas eu la chance de suivre des études orientées développement. Et j'en suis totalement content.

Les tests techniques je ne suis pas totalement pour... Pour la plupart de ceux que j'ai passé. Ils sont soit trop simple, soit trop complexe et ne correspondent jamais au travail à effectuer au sein de l'entreprise. Personnellement, pour un test technique, je préfère largement des questions 'basiques' liées au langage qui sera utilisé, mais où les réponses attendues ne seront pas les même pour un débutant que pour un vétéran. Ceci juste histoire de faire un premier tri.

Exemple: "Comment se connecter à une base de données en C# avec ADO.Net?"
- un débutant, on aurait tendance à attendre une explication basique sans forcément l'utilisation des "bons noms d'objet".
- un vétéran devrait donner un exemple de code en respectant les noms des objets.

Après le test technique, viendrait pour moi l'entretien technique. Et la c'est la grosse erreur que j'ai rencontré tous le temps... sauf une fois!

Les recruteurs ont tendance à toujours vouloir mettre l'accent sur les connaissances acquises du développeur. Certes, c'est important mais est-ce que qu'il est apte à évoluer ou apprendre de nouvelles choses? C'est pour moi la question qui devrait être la plus importante. Comment évaluer cela? Simplement en posant des questions sur l'actualité dans le domaine pour lequel le postulant est là...

Pour ma part j'ai eu un entretien de ce genre, et pendant près de 2h on a discuté du .Net (Nuget, dernière version d'Entity Framework, comparaison avec d'ancien système,...). Je n'ai pas vu le temps passer, j'ai appris certaines choses et la personne en face de moi également. C'était un réel échange de développeur à développeur et je pense que quelqu'un n'ayant pas de compétence et aucun intérêt poru le développement ne peut pas réussir correctement cet entretien.

[lysandro]

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

A priori, l'évaluation devrait tenir compte de l'expérience demandée par l'employeur ou proposée par le candidat.

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

La meilleure ? aucune idée. Subjectivement, un entretien technique pur assez court pour s'assurer du niveau de compétences, et une partie plus générale sur l'approche du développement et de ses contraintes : humaines, environementale (ressources réseaux, processeur, disques, etc), interoperabilité, mode dégradé, ...

« collaboration, recherche sur Google ou encore les forums comme Stack Overflow »

va plutot dans le bon sens.

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

En fait je ne comprends pas bien l'enoncé ... J'ai lu la réponse de laerne mais ça n'a pas éclairé ma lanterne plutot éteinte même ! Je n'ai pas trop le niveau en math. Mais bref

C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule

alors je me lance.

L'idée est de répertorier les intersections par élément, puis de reconstruire les ensembles disjoints en fonction des intersections. Tous les éléments appartenant à une même intersection sont dans un même ensemble. Mais je suis bien incapable de dire si cela répond ou non à l'énoncé. Le résultat est celui attendu toutefois.

Un bout de javascript qui implémente ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
function resolve ( sets ) {
	var intersections = {};
	
	for( var i = 0; i < sets.length; ++i ) {
		for( var j = 0, set = sets[i]; j < set.length; ++j ) {
			var element = set[j];
			
			if ( !(element in intersections) )
				intersections[element] = ""+i;
			else
				intersections[element] += ","+i;
		}
	}

	var disjoint_sets = [];
	var intersections_sets = {};
	
	for( var element in intersections ) {
		var intersection = intersections[element];
		
		if ( !(intersection in intersections_sets) ) {
			intersections_sets[intersection] = disjoint_sets.length;
			disjoint_sets[intersections_sets[intersection]] = [];
		}
		disjoint_sets[intersections_sets[intersection]].push(element);
	}

	return disjoint_sets;
}

PS : Je n'avais pas tout lu ... C'est une réponse similaire à celle qu'avait déjà faite alphamax666. Sauf qu'en ce qui me concerne ça m'a pris plusieurs heures ... :-))

[Gouyon]

Ceux qui sont contre les tests n'ont jamais eu à recruter des profils qui se sont avérés être loin de la réalité. Il faut que ça vous arrive au moins une fois avec les conséquences (reprise de son travail, horaires à rallonge à cause de lui...) pour que vous voyez l'intérêt de ce test

Je pense que nous ne seront jamais d'accord là dessus mais je crains qu'un test ne soit pas la panacée pour détecter si le candidat est celui qu'il vous faut. Un contre exemple. Un collègue m'a demandé un jour si je connaissais JAVA car il avait des modifications à faire sur un logiciel qui avait été fait par une boite extérieure. Je lui ai répondu que oui j'en avais fait un peu et j'ai pris le boulot malgré ma faible expérience en JAVA. Finalement je me suis plongé dans le code et j'ai fait ce qu'il me demandais plus rapidement qu'il ne le pensais. S'il m'avait fait passé un test je pense que je l'aurais raté vu mes faibles connaissance c'est mon expérience qui a fait la différence car j'ai déjà traité ce type de problèmes dans d'autres langages et j'ai même fait des suggestions et améliorations a tel point que j'ai rempilé pour 3 ans.

Moi, ce qui m'inquiète le plus, c'est que l'exemple que j'ai donné: dans notre entrepris il a été grillé (jusqu'à la MOA) mais derrière, il a été refilé à un autre client qui ne se doutait pas de qui l'attendait
Tout ça parce que son CV présente bien, qu'il a de l'expérience...
Il est assez kamikaze pour avoir accepté une mission d'aide express sur un projet en retard, sur un framework qu'il ne connaissait pas
Il faudrait presque un réseau social ou on indiquerait les profils à éviter

Attention avant de griller quelqu'un là aussi même si je vous accorde qu'il y a des incompétents notoire. Il y a des situations qui font que la personne ne donne pas le meilleur d'elle même. Ainsi un jour mon chef a embauché une personne à la réputation sulfureuse. J'avais beaucoup de craintes mais je faisais erreur car il s'est révélé très volontaire et efficace avec une volonté de progresser.

[imikado]

Je pense que nous ne seront jamais d'accord là dessus mais je crains qu'un test ne soit pas la panacée pour détecter si le candidat est celui qu'il vous faut. Un contre exemple. Un collègue m'a demandé un jour si je connaissais JAVA car il avait des modifications à faire sur un logiciel qui avait été fait par une boite extérieure. Je lui ai répondu que oui j'en avais fait un peu et j'ai pris le boulot malgré ma faible expérience en JAVA. Finalement je me suis plongé dans le code et j'ai fait ce qu'il me demandais plus rapidement qu'il ne le pensais. S'il m'avait fait passé un test je pense que je l'aurais raté vu mes faibles connaissance c'est mon expérience qui a fait la différence car j'ai déjà traité ce type de problèmes dans d'autres langages et j'ai même fait des suggestions et améliorations a tel point que j'ai rempilé pour 3 ans.

On parle d'un test technique et non d'un questionnaire, vous auriez pu le réussir: j'en discutais encore cette semaine avec un collègue qui doit recruter en ce moment, et l'idée du CRUD lui semblait pertinente

Attention avant de griller quelqu'un là aussi même si je vous accorde qu'il y a des incompétents notoire. Il y a des situations qui font que la personne ne donne pas le meilleur d'elle même. Ainsi un jour mon chef a embauché une personne à la réputation sulfureuse. J'avais beaucoup de craintes mais je faisais erreur car il s'est révélé très volontaire et efficace avec une volonté de progresser.

Je n'ai pas personnellement grillé la personne: elle s'est grillée toute seule auprès des managers jusqu'à la MOA, et pour que la MOA remarque l'incompétence de quelqu'un il faut y aller

[Gouyon]

On parle d'un test technique et non d'un questionnaire, vous auriez pu le réussir: j'en discutais encore cette semaine avec un collègue qui doit recruter en ce moment, et l'idée du CRUD lui semblait pertinente

Non je ne pense pas. D'ailleurs je ne sais même pas ce que c'est un CRUD
(enfin maintenant si car je viens de me renseigner )

Je n'ai pas personnellement grillé la personne: elle s'est grillée toute seule auprès des managers jusqu'à la MOA, et pour que la MOA remarque l'incompétence de quelqu'un il faut y aller

Je ne connais pas le dossier mais si c'est comme chez moi effectivement ça doit être un cas (j'en ai eu un aussi chez nous)

Ce qui me gène surtout dans cette histoire de test c'est qu'ils ne sont appliqué qu'aux candidats d'un certain age.

[imikado]

Non je ne pense pas. D'ailleurs je ne sais même pas ce que c'est un CRUD
(enfin maintenant si car je viens de me renseigner )

CRUD C'est Create Read Update Delete
Créer
- une page pour afficher les entrées en base (R)
- une page pour afficher l'entrée en détail (R)
- une page avec un formulaire pour ajouter une entrée (C)
- une page avec un formulaire pour modifier une entrée (U)
- une derniere page avec formulaire ou non pour supprimer une entrée (D)

Je ne connais pas le dossier mais si c'est comme chez moi effectivement ça doit être un cas (j'en ai eu un aussi chez nous)

Ce qui me gène surtout dans cette histoire de test c'est qu'ils ne sont appliqué qu'aux candidats d'un certain age.

Non, le test c'est pour tous, à moins que le candidat se présente comme un débutant: on en a recruté en connaissance de cause, ces profils ont ainsi appris sur le tas (pas sur de l'orthographe)

[fredoche]

Je me demande si tu ne fais pas une montagne d'une exception imikado.

Comme évoqué précédemment, on ne demande pas à un maçon de monter un mur lors de son entretien, ou de lisser une dalle.

Un beau-frère commence aujourd'hui un boulot de technico-commercial dans les portes automatiques après plus de 10 années de travail de menuiserie d'agencement. Penses-tu qu'on lui demande de démontrer lors de son entretien d'embauche de vendre une de ces portes ?

La période d'essai sert à ça, à évaluer la personne pour l'emploi qu'elle occupe.

Et puis il ne faudrait pas perdre de vue que le risque est partagé dans une embauche, tant pour le salarié que pour l'entreprise. A te lire, on dirait que le risque n'existe que pour l'employeur...

Tu ne prends que le point de vue de l'employeur il me semble, te défendant vaguement sur le fait que c'est aux collègues de compenser le boulot mal fait... Or c'est à l'employeur qu'incombe l'organisation du travail, cette responsabilité et les conséquences éventuelles.

Vous avez eu une mauvaise expérience contre combien de positives dans vos différentes embauches ? précédant ou suivant cette mauvaise expérience ? les positives précédant la mauvaise avaient elles fait appel à des tests de CRUD ? Oui, non, pourquoi ? Les nouvelles procédures de tests CRUD excluent elles le risque expérimenté précédemment ? Oui, non, pourquoi ?
Quels sont les autres risques ? Comment sont ils traités, pris en compte, anticipés?

Quels sont les enjeux ?

J'ai pas envie d'être trop méchant mais êtes vous surs - si les enjeux liés à une embauche sont si importants - d'avoir tiré les bonnes leçons de votre mauvaise expérience ?
Pour ma part, je ne crois pas, je crois plutôt déceler une certaine forme d'entêtement dans ton raisonnement, et la mise en place de solutions qui ne répondent pas aux problèmes, mais vous donnent l'impression d'avoir pris les bonnes décisions.

Quand au CRUD en 1 heure, mets le en perspective avec vos attentes en terme de profil, de talent, d'autonomie, de motivation, avec votre potentiel de séduction ou d'attrait envers des candidats attendus...

[-]

Perso je suis très largement pour, mais à condition d'être revu par un technique avec le candidat. Déjà c'est un gage de sérieux de la part de l'entreprise et des boîtes comme Alten ou Assystem ne le font pas nécessairement, et ensuite j'ai déjà vu des tocards avec 15 ans d'XP...

[imikado]

Je me demande si tu ne fais pas une montagne d'une exception imikado.

C'est un exemple récent, mais mes collègues, depuis 2009 ont eu des 3 cas dans le même genre, en ajoutant les 2 profils que j'ai connu, ça fait 5

La période d'essai sert à ça, à évaluer la personne pour l'emploi qu'elle occupe.

J'ai déjà (et ne suis pas le seul) répondu à cette solution: on va pas mettre 3 profils potentiels en periode d'essai, et on va pas attendre 3 mois pour savoir si la personne n'est pas compétente: c'est trop long

Et puis il ne faudrait pas perdre de vue que le risque est partagé dans une embauche, tant pour le salarié que pour l'entreprise. A te lire, on dirait que le risque n'existe que pour l'employeur...

Justement: si le test se passe bien, l'employeur ET l'employé savent que ça devrait bien se passer (le candidat sait qu'il sera à la hauteur de la tache)

Tu ne prends que le point de vue de l'employeur il me semble, te défendant vaguement sur le fait que c'est aux collègues de compenser le boulot mal fait... Or c'est à l'employeur qu'incombe l'organisation du travail, cette responsabilité et les conséquences éventuelles.

Les premiers touchés par une mauvaise embauche sur un projet ce sont les developpeurs actuels, l'employeur ne peut que proposer de stopper la mission et de recommencer une phase de recrutement, mais c'est trop tard, on n'a plus le temps de rechercher une personne, la former sur le projet et attendre en croisant les doigts pour que le profil convienne.

Vous avez eu une mauvaise expérience contre combien de positives dans vos différentes embauches ? précédant ou suivant cette mauvaise expérience ? les positives précédant la mauvaise avaient elles fait appel à des tests de CRUD ? Oui, non, pourquoi ? Les nouvelles procédures de tests CRUD excluent elles le risque expérimenté précédemment ? Oui, non, pourquoi ?
Quels sont les autres risques ? Comment sont ils traités, pris en compte, anticipés?

Heureusement, entre temps avant/après on a eu des profils corrects qui ont été débauchés depuis.
Pour rappel, on embauche deux types de profils:
- des débutants qui seront formés en interne et evolueront à leur rythme
- des expérimentés : sur un projet en particulier o$ les plannings font qu'il nous faudra une ressource supplémentaire pour finir dans les délais (appels d'offres...)
C'est dans le deuxième cas, qu'il nous faut se backer (pas de traduction en tête)

Quand au CRUD en 1 heure, mets le en perspective avec vos attentes en terme de profil, de talent, d'autonomie, de motivation, avec votre potentiel de séduction ou d'attrait envers des candidats attendus...

Pour le/les profils (non pertinent) que nous avons rencontré (5 au total), il aurait pu nous faire gagner du temps, en effet

[fredoche]

C'est un exemple récent, mais mes collègues, depuis 2009 ont eu des 3 cas dans le même genre, en ajoutant les 2 profils que j'ai connu, ça fait 5

5 sur ?
Vu ce que je lis de la suite, ta boite est une SSII, est ce bien ça ?

J'ai déjà (et ne suis pas le seul) répondu à cette solution: on va pas mettre 3 profils potentiels en periode d'essai, et on va pas attendre 3 mois pour savoir si la personne n'est pas compétente: c'est trop long

1 heure c'est trop court
1 journée aussi
Donc vous assumez ce risque ? enfin surtout les employés... ou les clients, si je comprends bien

Parce que tu nous as décrit une tanche, mais tu nous a aussi expliqué que cette tanche était toujours dans la boite, passée vers un autre service ou un autre client.

Et qu'en gros les 3 mois d'essai n'ont servi à rien.

Il est plus commode de juger sur une heure que sur 3 mois chez vous, c'est donc un risque assumé.

Justement: si le test se passe bien, l'employeur ET l'employé savent que ça devrait bien se passer (le candidat sait qu'il sera à la hauteur de la tache)

Cool
la tache : des CRUD ! cool

Vous le dites au candidat qu'il va devoir se cogner des CRUD à longueur d'année, puisque ce sera visiblement sa tâche la plus élevée ?
Et puis pour cette haute tâche, vous avez cogité au framework qui fait ça automatiquement ?
Et puis vu ce que c'est, c'est pas plus simple de prendre un mec de bonne volonté et de le former à votre main à faire des CRUD à la chaine ?
Si il faut une heure pour pondre un CRUD complet et professionnel, doit aps falloir bien longtemps à former un mec à faire ce truc. Vosu gagnerez du pognon comme ça : un smicard chômeur vierge du cerveau et tu le formes à ta patte.

Non l'employeur n'en sait rien sur ce qui se passera ensuite, surtout pas avec un test de CRUD

Et l'employé à la base il est là pour gagner un salaire, pour pouvoir bouffer dormir et travailler tiens... Il est peut être pas tellement là pour garantir que les élucubrations de 2-3 commerciaux se transforment en réalité tangible parce que sinon le boss est mal face au client
L'employé il sait juste qu'il va devoir se cogner du CRUD, s'il y est arrivé une fois, l'embauche est garantie, cool...

Les premiers touchés par une mauvaise embauche sur un projet ce sont les developpeurs actuels, l'employeur ne peut que proposer de stopper la mission et de recommencer une phase de recrutement, mais c'est trop tard, on n'a plus le temps de rechercher une personne, la former sur le projet et attendre en croisant les doigts pour que le profil convienne.

Saine attitude croiser les doigts
tu peux aussi serrer des fesses, ou brûler des cierges...

L'employeur ne peut que ... le pauvre

tandis que l'employé lui il peut, faire des heures supp, compenser l'incurie de son management.
Forcément les 1ers touchés, c'est normal.
Rarement les 1ers à se gaver, c'est bizarre

Moi je vais te dire ton employeur s'engage sur une date de livraison par exemple, c'est à lui d'en porter l'entière responsabilité, et s'il ne peut que, et que ce qu'il peut ne suffit pas, il assume.

Heureusement, entre temps avant/après on a eu des profils corrects qui ont été débauchés depuis.
Pour rappel, on embauche deux types de profils:
- des débutants qui seront formés en interne et evolueront à leur rythme
- des expérimentés : sur un projet en particulier o$ les plannings font qu'il nous faudra une ressource supplémentaire pour finir dans les délais (appels d'offres...)
C'est dans le deuxième cas, qu'il nous faut se backer (pas de traduction en tête)

assoir, assurer

Pour le/les profils (non pertinent) que nous avons rencontré (5 au total), il aurait pu nous faire gagner du temps, en effet

ah t'en es pas sur ?

[imikado]

5 sur ?
Vu ce que je lis de la suite, ta boite est une SSII, est ce bien ça ?

Non: on travaille avec des SSII mais on est pas une SSI, je travaille dans la finance.

Parce que tu nous as décrit une tanche, mais tu nous a aussi expliqué que cette tanche était toujours dans la boite, passée vers un autre service ou un autre client.

Oui, je souhaites bien du courage aux prochains: d'ailleurs, j'étais resté en contact avec lui, sa mission d'après ne se passait pas très bien et il s'est permis de dire que le developpeur (dans sa mission d'après) avait tout mal fait qu'il avait refait une partie de son travail.
C'est un profil qui écrasait votre code meme avec svn et se permettait d'accuser svn
Avec le temps on a trouvé le problème: il faisait des svn update, mais ouvrait des vieilles version (de son cache) donc écrasait mes modifications

Et qu'en gros les 3 mois d'essai n'ont servi à rien.

Au bout d'un mois on s'est rendu compte, mais il était trop tard et on a du trancher entre deux choix:
- qu'on le remercie et que je finisse tout tout seul
- qu'on le garde mais qu'on l'encadre comme un débutant (un point tous les matins pour savoir ce qu'il avait fait la veille et ce qu'il avait à faire aujourd'hui...)

On a opté pour le seconde solution: je ne me sentais pas de dire que je finissais tout tout seul et prendre le risque de ne pas finir dans les délais, et puis avec la seconde solution, il avancait, meme si il nous faisait perdre du temps, il avancait en parallèle de moi

J'ai juste du reprendre une partie des modules qu'ils devaient faire en plus de ce qu'il me restait à faire.

Il est plus commode de juger sur une heure que sur 3 mois chez vous, c'est donc un risque assumé.

Je n'ai pas compris, je préfèrerais à minima, via un test d'une heure (pour ne pas faire perdre trop de temps au candidat et à nous meme) sur plusieurs candidats pour savoir lequel on prend.
La période d'essai, vu que l'on travaille via SSII, c'est la première "instance" de mission (vu que c'est renouvellable par 3 mois)

Cool
la tache : des CRUD ! cool

Vous le dites au candidat qu'il va devoir se cogner des CRUD à longueur d'année, puisque ce sera visiblement sa tâche la plus élevée ?
Et puis pour cette haute tâche, vous avez cogité au framework qui fait ça automatiquement ?
Et puis vu ce que c'est, c'est pas plus simple de prendre un mec de bonne volonté et de le former à votre main à faire des CRUD à la chaine ?
Si il faut une heure pour pondre un CRUD complet et professionnel, doit aps falloir bien longtemps à former un mec à faire ce truc. Vosu gagnerez du pognon comme ça : un smicard chômeur vierge du cerveau et tu le formes à ta patte.

Le crud c'est un exercice comme un autre, on peut lui faire faire une application avec espace public / privé + module d'authentification, CRUD c'est un exemple
Et c'est une bonne base pour discuter sécurité, avec le CRUD on a pas mal de cas: XSS, XSRF et sql injection

[imikado]

assoir, assurer

Merci

ah t'en es pas sur ?

Je n'en suis pas sur, car c'est un test que je souhaiterais mettre en place, un de mes collègues devrait le tester (ils cherchent une personne en ce moment)
Je n'ai pas de retour encore dessus, c'est en le mettant en place que l'on verra ce qu'il en est.

Mais relisez le test en entier, ce n'est pas que le CRUD en lui-même, on voit également l'estimation avant projet, après projet, et c'est une base de discussion sur la sécurité

[fredoche]

On a opté pour le seconde solution: je ne me sentais pas de dire que je finissais tout tout seul et prendre le risque de ne pas finir dans les délais, et puis avec la seconde solution, il avancait, meme si il nous faisait perdre du temps, il avancait en parallèle de moi

J'ai juste du reprendre une partie des modules qu'ils devaient faire en plus de ce qu'il me restait à faire.

Et il est où ton management ? ton boss ?
c'est le choix entre la corde ou l'échafaud c'est ça ?

tu prends quel risque à ne pas finir dans les délais ?

Vous prenez un mec mauvais et vous assumez le risque de le garder mais à coté de ça c'est à toi de continuer à garantir qualité et délai ?

[imikado]

Et il est où ton management ? ton boss ?
c'est le choix entre la corde ou l'échafaud c'est ça ?

Vu avec mon boss en effet, il m'a demandé, je lui ai répondu

tu prends quel risque à ne pas finir dans les délais ?

Sans donner trop de détail (pour des raisons de confidentialité), la date était imposée, on commencait à tel date point (contrainte extérieure)

Vous prenez un mec mauvais et vous assumez le risque de le garder mais à coté de ça c'est à toi de continuer à garantir qualité et délai ?

Je ne peux pas trop expliquer le contexte, mais effectivement on avait une grosse contrainte de temps, on a fait appel à une SSII pour avoir un candidat experimenté et opérationnel tout de suite, on lui a fait confiance, à tort.
Et oui je m'implique beaucoup et ça me prend aux trippes de respecter les délais, vu qu'au final je devais un peu tout faire, le candidat était en soutient pour me laisser un peu de temps (gestion de la production, support pour d'autres collègues, veille techno....)

[centurio]

Je suis tombé sur une mauvaise expérience du genre. J'ai quelques années d’expérience derrière moi et cet entretien m'a mis un coup au moral.
L'entretien s'est déroulé au téléphone et le type m'a posé un problème qu'il a partagé sur un google doc (pratique mais stressant). Je retranscrit ici le problème qui m'a été exposé en anglais.
Je devais écrire un programme en java qui permet de déterminer l'équivalence d'une rotation d'une chaîne de caractères: par exemple est-ce que "ACB" est une rotation de "ABC". J'ai eu une 10 aines de minutes pour écrire le programme en expliquant ligne à ligne au téléphone.
Je crois que n'importe qui sortant des études aurait réussi. J'ai plus ou moins foiré car je n'avais pas prit en compte tous les cas possibles, le stress n'aidant pas; Je n'ai bien sûr pas été pris. Je ne crois pas pour autant que ça fait de moi un mauvais développeur.
Je ne crois plus trop à ce genre de tests, je crois que si on veux investir dans qq'un il faut le prendre à l'essai, l'encadrer et comprendre quelles sont ses faiblesses et l'aider à s'améliorer si quelque chose ne convient pas.
Ce n'est pas tant les compétences qui posent problèmes dans un projet mais plutôt la personnalité et l'engagement. je préfère largement qqun qui s'investit dans ce qu'il fait même s'il n'est pas "au niveau" plutôt que le type qui s'en fou en attendant le chèque à la fin du mois...

[imikado]

@centurio, je ne sais pas à qui s'adresse votre post, mais dans mon cas et dans celui d'autre avant moi: vous devez recruter une personne "opérationnelle", vous avez plusieurs profils à rencontrer, comment determinez vous lequel vous prenez ?

Personnellement, en lisant votre expérience, je comprends le malaise: ce n'es pas agréable de travailler avec un téléphone bloqué entre l'épaule et la joue, le tout en 10 minutes, sur un problème un peut particulier.

L'idée du CRUD c'est un exercice qui demande au candidat une partie de ce qu'il fera sur le terrain: dans un CRUD, on selectionne des données, on les affiche, on manipule des formulaires... choses que l'on fait tous les jours en web

[centurio]

@centurio, je ne sais pas à qui s'adresse votre post, mais dans mon cas et dans celui d'autre avant moi: vous devez recruter une personne "opérationnelle", vous avez plusieurs profils à rencontrer, comment determinez vous lequel vous prenez ?

Mon post ne s'adresse pas à vous directement je voulais faire partager mon expérience, par rapport au sujet. Merci en tout cas de m'avoir répondu

Pour répondre à la question Je détermine à l'avance quels sont les critères essentiels pour l'ensemble de mon équipe, je ne prends pas les décisions au regard de ce que je recherche moi seul.

Si le recrutement s'opère uniquement dans le cadre de la sélection vis à vis des compétences techniques, alors ... désolé mais c'est tout faux. C'est impossible...

Toutefois, vous demandez à quelqu'un de savoir écrire du CRUD et c'est une très bonne approche puisque ce sont des choses réelles que vous faites tous les jours dans votre équipe.
Mais si c'est votre seul critère être "opérationnel" dans le CRUD alors je crois pas que ça soit une si bonne idée.

Il y a toujours un candidat qui sort du lot, mais l'essentiel c'est de se rendre compte à quel point il est motivé, s'il comprends les enjeux de son embauche.

Si le besoin est urgent alors je prends un freelance qui aura le bon profil "nécessaire à mon besoin". Ils ont généralement une expériences beaucoup plus significative et sont capables d'intervenir ponctuellement et "désolé de le dire" auront un coût d'acquisition au final beaucoup moins élevé pour la société qu'un CDI par exemple.

Je comprends tout à fait ces questions. On est dans l'urgence et il faut absolument consolider l'équipe.
Je ne crois pas qu'on puisse embaucher quelqu'un et se dire qu'il sera tout de suite opérationnel. De mon constat personnel, si l'équipe est stable pendant plusieurs mois alors tout le monde prendra son rythme de croisière au bout du 2ème ou 3ème mois. Pour moi c'est la réalité.