Quels signes permettent de déceler un candidat talentueux ?

[ManusDei]

Je reréagit sur un bout de post.

Envoyé par cirtey

Lorsqu'on est obligé de les recruter (les passionnés sont une minorité), je remarque qu'ils ont tendance [...] à compter leur heures.

Les non-passionnés font attention à faire autant d'heures que sur le contrat, là où les passionnés vont en faire moins ? Je vois pas le problème que ça pose vis-à-vis des non-passionnés.

[cirtey]

Envoyé par Bluedeep

Ridicule. J'adore cuisiner mais je ne serais pas au point pour ouvrir un restau capable de chopper 3* au Michelin.



Presque aussi ridicule que l'affirmation supra : j'ai rencontré des tas de mauvais codeurs qui aimait néanmoins faire cela. Je t'accorde juste que j'ai rarement rencontré des gens qui n'aimait pas faire cela qui le faisait bien.



Là on rentre dans le pur n'importe quoi (il est vrai que c'était bien engagé).

Dire que les codeurs qui aiment coder n'ont pas, toute chose égale par ailleurs plus de chance d'être de bon codeurs est si ce n'est pas de la mauvaise foi de la débilité la plus profonde.

[cirtey]

Envoyé par ManusDei

Je reréagit sur un bout de post.



Les non-passionnés font attention à faire autant d'heures que sur le contrat, là où les passionnés vont en faire moins ? Je vois pas le problème que ça pose vis-à-vis des non-passionnés.

Les non passionnés n'aiment pas coder, ils font le travail pour des raisons alimentaires, il n'ont pas de plaisir à résouudre les problèmes et donnent le moins possible.

[cirtey]

Envoyé par ManusDei

J'en vois deux sur les trois qui sont surtout très bons en communication et business (et le troisième je le connais pas).

Zuckerberg a déjà créé des logiciels de reconnaissance des goûts musicaux et l'a publié en open source alors qu'il n'avait pas 16 ans. Anders est un génie que tu pourra googler, Bill Gates est plus orienté marketing en effet, mais il était déjà programmeur à son adolescence.

[cirtey]

Donc pour filtrer les bons des mauvais:
1- Selectionner les CV les plus pertinents aux poste: se focaliser sur l'expérience plutôt que les diplômes. J'ai déjà vu des développeurs avec une licence bien meilleurs que des bac+5.
2- Faire passer des tests techniques et garder les meilleurs: se focaliser sur l'algorithmie plutôt que que des connaissances spécifiques liées au framework. Ce qui compte le plus c'est la capacité de raisonnement. Grâce à Internet, l'accès à l'information est facile. Par ailleurs les connaissances se périment assez rapidement car les frameworks et outils changent rapidement.
3- Sur les meilleurs faire passer des tests de motivation, si le candidat indique qu'il souhaite devenir AMOA ou 'manager' le plus rapidement possible, lui préférer le gars qui veut rester dans la technique, qui se montre curieux sur le contenu technique de la mission. Ce second profil est plus rare, la majorité d'ingénieurs sont convaincus qu'ils doivent devenir 'chef' de projet, que le code c'est pour les petites mains.

[cirtey]

Envoyé par Robin56

Euh en même temps, quand on est CP, il faut bien avoir des ressources à gérer. Donc logiquement il y a besoin de plus de programmeurs que de CP.

Bien sûr qu'on a toujours besoin de plus de développeurs que de CP, je ne vois pas où tu veux en venir?

[ManusDei]

Envoyé par cirtey

Les non passionnés n'aiment pas coder, ils font le travail pour des raisons alimentaires, il n'ont pas de plaisir à résouudre les problèmes et donnent le moins possible.

Je ne sais pas où tu vas me ranger alors. L'informatique est pour moi un outil utile pour un but, et non une passion. Je travaille pour des raisons purement alimentaires, j'aime avoir du temps pour moi (j'ai pas essayé d'être trader ou avocat c'est trop de boulot), j'aime résoudre les problèmes, j'ai une passion très modérée pour le code, et je donne à hauteur de mon contrat (ni plus, ni moins, un peu comme ma SSII en fait).

Bizarrement, je suis toujours loué pour la clareté de mon code (et ce depuis la fac), et souvent pour sa robustesse, ainsi que pour les commentaires explicatifs à côté du code. Un code robuste est un code auquel on retouche rarement, idée que j'aime beaucoup (ben oui, j'ai pas envie de passer du temps plongé dans le code à corriger des bugs).
Un code clair est facile à retoucher par les autres, ce qui me permet de ne pas perdre de temps à remettre les mains dans ce que j'ai oublié depuis (et fait gagner du temps aux collègues).

Bref, étant payé pour un travail, j'estime que je dois honorer mon contrat et faire le boulot correctement (pas moins, mais pas plus non plus). Je suis donc intelligent à hauteur de mon salaire et de la reconnaissance de mon travail.

Et mes collègues sont en grande partie dans le même cas.
Je te ferais remarquer qu'un passionné qui avale un boulot monstre "vole" le travail d'un chômeur, qui aimerait bien travailler (pour la majeure partie d'entre eux), et ce en étant rarement mieux payé.

[Robin56]

Envoyé par cirtey

Bien sûr qu'on a toujours besoin de plus de développeurs que de CP, je ne vois pas où tu veux en venir?

Je ne veux en venir nul part, j'analysais simplement ta phrase qui laissait sous entendre que dans d'autres pays que la France ce n'est pas le cas. Voici ta citation :

Le problème pour ce genre de profil est qu'en France on offre peu de postes en AMOA et CP (surout pour des juniors) par rapport au nombre d'offres de programmeurs. Du coup on se retrouve avec des personnes qui font du code par dépit.

[cirtey]

Envoyé par ManusDei

Je ne sais pas où tu vas me ranger alors. L'informatique est pour moi un outil utile pour un but, et non une passion. Je travaille pour des raisons purement alimentaires, j'aime avoir du temps pour moi (j'ai pas essayé d'être trader ou avocat c'est trop de boulot), j'aime résoudre les problèmes, j'ai une passion très modérée pour le code, et je donne à hauteur de mon contrat (ni plus, ni moins, un peu comme ma SSII en fait).

Bizarrement, je suis toujours loué pour la clareté de mon code (et ce depuis la fac), et souvent pour sa robustesse, ainsi que pour les commentaires explicatifs à côté du code. Un code robuste est un code auquel on retouche rarement, idée que j'aime beaucoup (ben oui, j'ai pas envie de passer du temps plongé dans le code à corriger des bugs).
Un code clair est facile à retoucher par les autres, ce qui me permet de ne pas perdre de temps à remettre les mains dans ce que j'ai oublié depuis (et fait gagner du temps aux collègues).

Bref, étant payé pour un travail, j'estime que je dois honorer mon contrat et faire le boulot correctement. Je suis donc intelligent à hauteur de mon salaire et de la reconnaissance de mon travail.

Et mes collègues sont en grande partie dans le même cas.

Je ne dis pas que ceux qui ne sont pas passionnés sont mauvais. Je dis que TOUTE CHOSE EGALE PAR AILLEURS on a plus de chance de trouver un bon développeur qui est passionné par le code que le contraire. Et j'ai déjà écrit que c'est NORMAL que la plupart des développeurs donnent le stricte minimum car ils ne sont pas suffisemment considérés et payés.

[topdawg]

Envoyé par AlbertSY

La meilleure doc c'est le code lui-même. Enfin, quand c'est bien codé.

Envoyé par ricardo_bresil

Documenter son code signifie qu'il n'est pas assez clair, un bon code doit s'expliquer de lui même.

Pour penser ça, il faut n'avoir jamais lu du code super bien écrit, genre boost, ou ce qu'a pissé John Carmack sur Quake III ([EDIT] sacrilège, j'avais oublié, ou du code FreeBSD).
"Bien codé" comme tu dis, mais imbitable sans les trois lignes d'explication avant, que même ces supercodeurs mettent, et sans les commentaires qu'ils foutent ensuite dans le code.

Je vois mal comment certains pensent encore que le code n'a pas besoin d'autre doc que le code lui-même. Moi, un gars qui pense ça, je ne l'embaucherai jamais. J'ai vu trop de code sans commentaire ni semblant de doc, et sur plusieurs pages d'écran et non indenté!, que j'ai dû maintenir pour ne pas avoir la gerbe juste à une telle perspective.

Envoyé par souviron34

Moi.. Et cash qui plus est

Et vous serez une exception. Ah oui, j'oubliais, vous disiez "quand j'étais jeune, dans les années 80". Aujourd'hui, quelqu'un qui a commencé a bosser après 2002 ou 2003, je serais surpris qu'il ait, sur son seul salaire et dans 20 ans, les moyens de payer un logement cash. Et je ne parle même pas d'une maison. ([EDIT] J'ai brièvement évoqué le fait dans un article sur AgoraVox).

[pmithrandir]

Envoyé par topdawg

Pour penser ça, il faut n'avoir jamais lu du code super bien écrit, genre boost, ou ce qu'a pissé John Carmack sur Quake III.
"Bien codé" comme tu dis, mais imbitable sans les trois lignes d'explication avant, que même ces super-codeurs mettent, et sans les commentaires qu'ils foutent ensuite dans le code.

Je vois mal comment certains pensent encore que le code n'a pas besoin d'autre doc que le code lui-même. Moi, un gars qui pense ça, je ne l'embaucherai jamais. J'ai vu trop de code sans commentaire ni semblant de doc, et sur plusieurs pages d'écran et non indenté!, que j'ai dû maintenir pour ne pas avoir la gerbe juste à cause de l'idée.

Il y a peu de cas ou l'on a besoin d'optimisation comme celle de John Carmack... en général, le temps gagné est perdu en dev, donc on préfère des gens qui feront un code moyen niveau perf, mais très lisible et clair. Pour ce genre de code, pas besoin de doc.
En général, l'algrythme, c'est loin d'etre la raison pour laquelle un programme rame.

Envoyé par topdawg

Et vous serez une exception. Ah oui, j'oubliais, vous disiez "quand j'étais jeune, dans les années 80". Aujourd'hui, quelqu'un qui a commencé a bosser après 2002 ou 2003, je serais surpris qu'il ait, sur son seul salaire et dans 20 ans, les moyens de payer un logement cash. Et je ne parle même pas d'une maison.

J'en connais un qui l'a acheté avec 2 années de salaire.
A son compte a 650€ la journée, ca a été vite...

[topdawg]

J'ai mis mon post à jour avant de voir cette réponse.

Envoyé par pmithrandir

Il y a peu de cas ou l'on a besoin d'optimisation comme celle de John Carmack... en général, le temps gagné est perdu en dev, donc on préfère des gens qui feront un code moyen niveau perf, mais très lisible et clair. Pour ce genre de code, pas besoin de doc.
En général, l'algrythme, c'est loin d'etre la raison pour laquelle un programme rame.

Qu'on me permette d'avoir un avis différent. D'abord, il n'était pas question d'optimisation jusque là, mais seulement de oui ou non est-ce que "un code bien écrit et lisible et clair a besoin d'une doc". Je dis que oui et les personnes que je citais dans mon post précédent disent qu'un tel code remplit en soi l'office d'une doc. Elles disent "non" là où je dis "oui".

Voici l'objet du délit:

Envoyé par Me, Myself & I

Je vois mal comment certains pensent encore que le code n'a pas besoin d'autre doc que le code lui-même.

[GROS HORS SUJET]
Ensuite, pour rebondir sur ta réponse, si c'était le cas, des gens ne bosseraient pas toujours sur des algorithmes et Timsort n'aurait pas vu le jour. Avec un tel raisonnement, voire une telle certitude, pas étonnant qu'un OpenOffice mette des plombes à se lancer, qu'un Firefox soit un tel ogre en termes de mémoire, et que certaines librairies XML Java soient une telle plaisanterie. Je m'aventurerais à dire que la puissance des machines actuelle n'a pas eu d'effet spectaculaire parce que beaucoup ont dit "pas la peine d'optimiser, ça marche déjà comme ça". Vive la résistance pro-optimisation.

Actuellement, je bosse sur une recherche de plus court chemin dans un programme qui porte sur des partitions de guitare. L'espace de recherche est exponentiel par nature et une exploration exhaustive est juste infaisable. Même en trouvant les meilleures heuristiques, ça ramera si l'algo est "moyen". Il suffira de charger un Koyunbaba ou la chaconne de Bach. OK, ce n'est pas le programme typique du développeur moyen placé chez un "grand compte" (hihi) par une SSII.

Je ne suis pas Carmack (et j'aurais dû éviter de mentionner son nom), je suis juste un quidam moyen qui aurait voulu être meilleur codeur.

Voici une partie de ce que j'ai pondu hier nuit, niveau sortie de four, même pas compilé.

Code :

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
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
	/**
	 * Finds the appropriate paths in a section of the score. Effectively determines several tablature versions of a single score.
	 * @param startFrame the first frame to be examined in the search for paths.
	 * @param endFrame the last frame of the section. Cannot come before the start frame.
	 */
	void Worker::findPaths(ListOfScoreFrames& allframes, PScoreFrame startFrame, PScoreFrame endFrame)
	{
		int startSeqNumber = startFrame->getSequenceNumber();
		int endSeqNumber = endFrame->getSequenceNumber();

		/* Number of frames between the start and end frames of the section being processed.
		 * The length is 1 if both frames are adjacent.
		 * Should the frames coincide, the length would be 0.
		 */
		int maxPathLength = endSeqNumber - startSeqNumber;
		//
		// Locate the start frame among all frames
		ListOfScoreFramesIterator iter = allframes.begin();
		for (; iter != allframes.end(); ++iter)
		{
			if ((*iter)->getSequenceNumber() == startSeqNumber)
			{
				break;
			}
		}
		// Normally, we should never reach the end of the list. So we should have found the start frame.
		if (iter == allframes.end() || ((*iter)->getSequenceNumber() != startSeqNumber))
		{
			throw 0; // FIXME: log sth instead of throwing an exception?
		}
		/* Number of assignments in the first frame of the section being searched */
		int contextWidth = ((*iter)->getPositions())->size();
		/* Number of top-shortest paths that are kept for each assignment of the first frame*/
		int contextNbPaths = 3;
		//
		// Initialization of the search: empty matrix and no paths
		//
		int step = 0; // top to bottom sequence number of the level being processed
		int activePaths = 0; // Upper-bounded by (nb of root nodes X nb of current nodes). For debugging, to be kicked out.
		PScoreFrame prevFrame = NULL; // parent level
		PScoreFrame curFrame = (*iter); // next-generation level
		PListOfLocationAssignments curPositions = curFrame->getPositions();
		// we set the context of each assignment in the current frame. Normally, we would use the parent level for that.
		ListOfLocationAssignmentsIterator iterPos = curPositions->begin();
		for (; iterPos != curPositions->end(); ++iterPos)
		{
			// each top-level node gets a me-myself-matrix as well as a path with only themselves in it.
			PNodeContext context = new NodeContext(startFrame);
			PLocationAssignment locAss = (*iterPos);
			locAss->setNodeContext(context);
		}
		//
		// Actual graph traversal, from top to bottom, level by level

Imagine que les commentaires n'y sont pas. Tu trouves/trouverais ça lisible ? Moi non. C'est pourquoi il y a tant de lignes de commentaires. Mon logiciel, mon algorithme, mon code. Et pourtant, j'ai besoin de ces béquilles que sont les commentaires (et d'autres choses). Car je parle français, anglais, mais pas "code".

OK, j'avoue que c'est le premier jet après le cahier de notes et qu'une fois le code débuggé et réécrit proprement, les commentaires disparaîtront en grande partie MAIS le fichier au format Word que je tiens à côté pour la doc sera mis à jour. Dix-neuf mois que je bosse dessus par intermittence. Dans deux ans et sans doc, je reviens là et je serai perdu après avoir écrit 100% de cette partie du code. J'ai une vie en dehors de ce code et, à mon grand regret (car je n'ai pas encore la pilule de Limitless), un seul cerveau. La doc me sert à pallier mes limitations en termes de mémoire et à éviter la frustration. Mais peut-être est-ce simplement moi qui suis intellectuellement limité au point d'avoir besoin de documenter mon propre code ?

(
Ça me fait repenser à celui qui disait "une fois la conception terminée". Bon courage pour "terminer la conception" d'une annotation de doigtés sur une partition avant de commencer à coder. Fais ça et je te vends mon studio de dev pour un euro symbolique. Ou alors, on sera concurrents mais je t'aiderai sans réserves.
)

D'ailleurs, comment un code peut-il être "lisible et clair" si la personne qui le lit ne sait pas de quoi on parle ? À quoi correspond par exemple ce que j'appelle "ScoreFrame" ? Si qqun ne sait pas ce qu'est une durée de note ou un temps en musique, le code, quelque lisible qu'il soit pour le lecteur, ne prendra pas pour autant tout son sens. Des noms parlants, des normes de nommage ou de codage, des fonctions courtes avec une seule fonctionnalité, etc., ça ne suffit pas à rendre un code compréhensible, pour mes capacités limitées en tout cas, car ça n'explique pas les concepts, lesquels sont pour moi à la base de la compréhension. J'ai connu le problème sur Code::Blocks et sur SilverStripe. Oui, on le résout, mais difficilement.

Est-ce que, pour savoir ce qu'est un "ScoreFrame", il vaut mieux que le nouveau développeur que j'accueille aille lire le code de la classe et le code de l'endroit où on construit un objet de type ScoreFrame ? Ou vaut-il mieux que je le renvoie vers la page de la doc qui montre un bout de partition sur lequel un "ScoreFrame" est entouré ? Moi je choisis la deuxième option, parce qu'elle me prend 3 minutes à constituer et 4 secondes à expliquer à chaque fois, là où les gens à qui je répondais suggéraient la première option. C'est juste ça en fait.

Pouah, j'ai plus de salive

J'en connais un qui l'a acheté avec 2 années de salaire.
A son compte a 650€ la journée, ca a été vite...

C'est exprès que j'avais utilisé "salaire" et non "revenu". À 650€ par jour, ce gars gagne plus que je ne touchais comme salaire en une semaine entière de boulot sur mon dernier poste de salarié. Quand l'écart entre le revenu et les besoins est tel, c'est pas étonnant. Mais ce n'est pas le cas du «développeur» dont il est question sur ce fil de discussion.

[souviron34]

Envoyé par topdawg

Je vois mal comment certains pensent encore que le code n'a pas besoin d'autre doc que le code lui-même. Moi, un gars qui pense ça, je ne l'embaucherai jamais. J'ai vu trop de code sans commentaire ni semblant de doc, et sur plusieurs pages d'écran et non indenté!, que j'ai dû maintenir pour ne pas avoir la gerbe juste à une telle perspective.

Entièrement d'accord.. Il y a d'ailleurs un débat ici-même (Géneral Développement -> Best Of) à ce sujet..

Envoyé par topdawg

Et vous serez une exception. Ah oui, j'oubliais, vous disiez "quand j'étais jeune, dans les années 80". Aujourd'hui, quelqu'un qui a commencé a bosser après 2002 ou 2003, je serais surpris qu'il ait, sur son seul salaire et dans 20 ans, les moyens de payer un logement cash. Et je ne parle même pas d'une maison. ([EDIT] J'ai brièvement évoqué le fait dans un article sur AgoraVox).

Non je ne serais pas une exception...

Enfin si, mais pas dans le sens où tu l'entends : je suis une exception car je ne cherche pas ni à vivre à crédit, ni à vivre au dessus de mes moyens...

J'ai donc d'une part attendu d'avoir 43 ans, et d'autre part acheté uniquement ce que mes économies et celles de ma copine nous permettaient, c'est à dire une maison de village avec pleins de travaux à faire, des termites, et sans jardin (enfin, 8m2)... pour 24 000 euros...



Donc si, n'importe qui, même aujourd'hui, avec 20 ans d'économies même sur un salaire d'informaticien courant, à 2, peut se le payer...

SAUF QUE..

je suis effectivement une exception car pour moi ma liberté et mon confort viennent de ma tanquillité d'esprit, et donc ne rien devoir à quicquonque... (donc en particulier à une banque).. Et me contenter de peu, ou en tous cas simplement de ce que je peux me payer..... Et du coup vivre sans avoir peur du lendemain, en m'achetant ce que je veux quand je peux.. Et donc sans superflu.. Mais avec tout ce qu'il me faut pour bien vivre...

[topdawg]

Envoyé par jouana

Je voulais juste dire que le problème c'est qu'à force de coder tout le temps, ça écoeure un peu.

Ça n'écœurera que ceux qui n'ont pas le talent ou l'envie pour ça, ou qui se sont rendus compte qu'ils sont irrémédiablement (au sens premier de "impossible à sauver") mauvais et qui se seront eux-mêmes dégoûtés et auront accusé "le code". Y a aussi, en référence au post de @el_slapper, ceux qui n'ont aucune envie de progresser.

Certains codeurs sont reconnus comme excellents, par ex., John Carmack, Steve McConnell ou Robert Morris. Je leur ai pas demandé mais je ne pense pas que ces gens-là soient écœurés, et moi, bien que coder ne soit plus une passion depuis bien longtemps, j'aspire à être aussi bon qu'eux. Et je code tous les jours. Et même si je le fais pour ma propre entreprise de logiciels, je trouve ça plus noble qu'avilissant de «coder». Bien sûr, je vois midi à ma porte et je fais abstraction de toute perception sociale du «codeur».

Quand j'ai passé des semaines à laisser mûrir une question, que j'ai couché avec beaucoup de doutes un algo sur papier, fait l'inventaire des structures de données, déroulé l'algo à la main, quand je l'implémente ensuite et qu'il tourne comme prévu après un temps de débogage ridicule au regard du temps total, putain, c'est plus seulement de la jouissance! C'est du multiorgasmique et je recommence en anticipant la prochaine expérience du genre… (Vous avez vu Hugh Jackman dans Opération Espadon quand il infiltre son ver qui sommeillait dans un vieil ordinateur ? Bon ben, moi c'est pareil, je fais une danse de la victoire, intérieurement le plus souvent. Il s'agit pas d'être ridicule non plus!)

S'il y a des gens qui codent sans la perspective de cette satisfaction, je les plains. En fait, non; je suis juste content de ne pas être eux.

Envoyé par jouana

Après je vois pas le coté stimulant de codé une fois que la conception est terminé

Get real!
On ne devient pas chef de projet avec un bac+5 comme vous le font croire vos profs qui vous prédisent une réussite exceptionnelle ou l'intégration directe du top 15% des postes de responsabilité en informatique.

Si tu penses ça, j'espère que tu ne codes pas ?

Non, la conception est souvent remise en cause, y compris à l'échelle d'algorithmes, notamment à cause des bugs. Car combien de bugs sont dus à des cas auxquels on n'avait pas pensé ? Dans le logiciel que j'écris actuellement, c'est presque 100%.

Envoyé par cirtey

Ceux qui veulent faire de l'AMOA ou de la gestion de projet, devraient faire cela sans passer par la case programmeur. Leur formation leur a déjà donné le vernis technique nécessaire et suffisant. Le problème pour ce genre de profil est qu'en France on offre peu de postes en AMOA et CP (surout pour des juniors) par rapport au nombre d'offres de programmeurs. Du coup on se retrouve avec des personnes qui font du code par dépit.

Si tu trouves quelqu'un dans ce cas (première mise en gras), je veux son nom (décodage: je te ris au nez (bien courtoisement, bien sûr)).

Le vrai problème (deuxième mise en gras), qui a déjà été [abondamment] abordé dans ce fil de discussion, c'est le fait que les exigences sur les offres d'emploi les rendent impossibles d'accès. Elles sont souvent telles que si les gens ne trafiquaient pas leur CV, ils n'auraient jamais accès à ces postes, c'est simple. Combien d'offres vous avez jamais vues qui n'exigeaient pas, pour être CP, déjà 3 ou 5 ans d'expérience en tant que chef de projet ? Moi, aucune. Pour avoir le boulot qui fournit l'expérience, il faut déjà avoir l'expérience. C'est le cercle infernal, la quadrature du cercle, la grande duperie même. Quand on ne veut pas jouer ce jeu de dupes, on crée sa société et on (je) se bombarde chef de projet et on gère les échéances, les risques, la petite équipe, les financements et les relations avec les parties prenantes. Autrement, point de salut. Sauf si qqch m'a échappé.

En passant, je reçois les offres de jobboom au Canada, et le problème est le même qu'ici en France. Illustration pour une annonce de "chargé(e) de projet intermédiaire" (quel qu'en soit le sens…) reçue cette semaine:

Exigences :
Importante : 2 mandats d’ordre stratégique en gestion de projet.
Importante : 2 mandats de + 500 jours en gestion de projet.
Atout : Connaître les principes du PMI.
Importante : Maîtriser les outils de la suite Office.
Essentielle : Maîtriser parfaitement la langue française.

Connaissances et aptitudes :
Essentiel : 6 ans d’expérience en technologie de l’information
Important : 3 ans en conseil stratégique en gestion de projet
Important : Avoir géré 2 projets de plus de 1000 j.-p
Important : 3 ans de charge de projet
Important : 3 ans en soutien à la gestion de projet

Monster.fr (et cie.) a des choses du même acabit.

Envoyé par pmithrandir

pour dénicher nos talents, voici notre procédure :
- Un tri des CV par les RH / une chasse aux profils sur linked in
- Un entretien individuel d'environ 1h, ou on présente notre poste, nos objectifs, et ou ensuite le candidat nous parle de lui. On pose aussi bien des question de RH, que l'on teste la pratique des langues, ou la capacité d'aller expliquer un concept au tableau.[…]

Je dois réagir à ça parce que je suis traducteur anglais-français. Si je m'estime plutôt bon, aussi bien pour rédiger en français qu'en anglais, pour le vocabulaire, pour la compréhension écrite ou pour la compréhension orale (j'assure un atelier dans ce dernier domaine), mon oral est nul. Je me plains, presque toutes les semaines aux gens qui vivent aux USA et avec qui je parle (en français), du manque de pratique qui m'amène à oublier les mots, comme ceux qui désignent "passoire" ou "crible" ou "creuset", ou des verbes comme "jubiler", "rationaliser", etc. ou des verbes plus du quotidien comme "marquer" ("ce qui m'a marqué, c'est…").

Quand le cerveau n'est pas entraîné, l'oral sera forcément minable et la France n'est pas un pays réputé pour son multilinguisme ambiant.

Même dans ce cas-là, pour un programmeur, un expert technique ou quelqu'un chargé de conception ou archi, je vois mal où est l'intérêt de la «pratique des langues» telle qu'on l'entend habituellement, c'est-à-dire à l'oral. À moins que l'entreprise ne soit internationale ?

Et même… En 2010, à Nantes, dans l'immeuble flambant neuf de CapGemini, je passe un entretien avec la DRH, à qui j'explique que je souhaite travailler sur des technos JEE parce que c'est ce qui me botte et que, par la même occasion, j'aimerais pouvoir pratiquer l'anglais à l'oral et quoi de mieux qu'une entreprise internationale comme Cap. L'impair à ne pas commettre. Elle m'a répondu, texto car je m'en souviens mot pour mot, "Vous ne pouvez pas entrer dans une entreprise franco-française comme Cap Gemini et dites ce que vous dites sur l'anglais. Vous vous mettez une épée (sic) dans le dos."

Et si la personne qui fait l'évaluation n'est pas un natif, oubliez le test de langue "juste pour faire un test de langue". Ça aussi, j'ai connu: des gens convaincus de parler un bon anglais et de pouvoir évaluer d'autres personnes alors qu'ils avaient un niveau risible. J'ai jamais entendu un français prononcer correctement "LinkedIn".

Y a un moment où il faut arrêter avec les tests. La vie est un pari permanent (combien de divorces, de tromperies, de "comme je suis déçu" ou de "je le/la croyais mon ami(e)" ?) et la période d'essai est là pour ça. Que les entreprises s'occupent déjà de faire, pendant la période d'essai, un suivi et une évaluation corrects des personnes embauchées.

[souviron34]

Envoyé par topdawg

Et si la personne qui fait l'évaluation n'est pas un natif, oubliez le test de langue "juste pour faire un test de langue". Ça aussi, j'ai connu: des gens convaincus de parler un bon anglais et de pouvoir évaluer d'autres personnes alors qu'ils avaient un niveau risible. J'ai jamais entendu un français prononcer correctement "LinkedIn".

Tout à fait...

C'en est risible si ce n'était pas aussi triste..

Et, à part quelques exceptions de gens ayant - longuement - travaillé en anglais dans un pays étranger - et anglophone -, c'est absurde...

Et c'est valable pour toutes les langues..

Je suis écroulé de rire quand j'entend les Français en général se f.utre du "parler petit négre" et qui ne se rendent pas compe qu'ils font exactement la même chose...

Même moi, qui parle pourtant couramment et ai vécu 17 ans et travaillé en milieu angloohone, et ai des amis et beaux-frères/belles-soeurs anglophones, et bien que je ne lise qu'en anglais, ne regarde les films ou les séries qu'en VO, suis les infos à la télé en anglais, etc etc, après 1 an en France je re-perd mes automatismes, et je ne suis plus tout à fait aussi 'courant" que d'habitude.. Il me faut une ré-immersion de 15 jours pour revenir.. Et pourtant je rêve en anglais...(c'est pour ça que je ne lis qu'en anglais)

Et ça n'est pas une question d'accent, tout le monde s'en fiche de l'accent.. C'est réellement et le vocabulaire et la construction des phrases..

Alors oui je peux distinguer celui qui annone péniblement 2 phrases, celui qui a appris relativement correcetment, et celui qui es vraiment courant..

Mais l'écrasante majorité de ceux que je vois ne le peuvent pas (même après "2 ans aux States"), et faire passer ce genre de tests est ridicule.. Et le niveau français est ridiculement bas.. (il l'est d'ailleurs tout autant en français ...)

[pmithrandir]

Hello,

Pour le test de langue, je travaille en Roumanie. La langue de travail est l'anglais, par decret. (même si les roumains echangent entre eux en roumain bien sur assez souvent).

Mais, on a quand même beosin de se comprendre un minimum. On est pret a founir des formations aux candidats talentueux, mais si vraiment on est pas capable de se comprendre, c'est dur d'imaginer aller plus loin. (je ne me recruterais pas avec mon niveau d'il y a 5 ans).

On attends aussi des salariés qu'ils sachent ecrire en anglais, sans que ca deviennent incompréhensible... après, on ne fait pas la chasse a toutes les fautes non plus... le but est réellement de se comprendre

Et je doute d'etre capbale de trouver la bonne facon de dire linkedin... parce que je doute qu'elle existe. Je comprend très bien les canadiens de Toronto, moins ceux de vancouver, pas du tout les texans, très bien les gens de san francisco, pas trop les anglais, mieux les ecossais et les irlandais(qui pour moi on un accent bien moins fort quer les londoniens...). Bref, on fait ce qu'on peut... et l'anglais est au moins aussi varié que le francais, sinon plus dans les accents. (entre un mec du midi, un sud africain, un congolais un marocain et un quebecois, ca promet de sacré partie de rigolade...)

[jouana]

Pour te répondre topdawg, je pense juste que c'est écoeurant de coder quand tu ne fais que ça plus de 10h par jours et 7 jours sur 7.

C'est sur que si tu participe à la conception, au test et tout autres processus du projet ce n'est pas écoeurant.

Personnellement je ne compte pas devenir chef de projet et pense me rabattre plus tard sur une PME afin de faire du dev, du réseau et avoir la main sur toute la vie du projet.

J'aime coder juste que j'aime faire autres choses de temps en temps.

[Mat.M]

bonjour,

Envoyé par topdawg

Imagine que les commentaires n'y sont pas. Tu trouves/trouverais ça lisible ? Moi non.

même sans les commentaires j'arrive à comprendre ton code et ce qu'il fait
Je sais que c'est la classe Worker avec une méthode findPaths
Comme le nom des variables est suffisamment explicite, j'en déduis que c'est un algorithme de recherche de chemin orienté graphe genre algo de Djikstra ou autre...

Quant tu maitrises un minimum le C++, tu peux arriver à lire du code C++, comprendre les classes et leurs méthodes etc...
je ne vais pas relancer un débat mais la P.O.O. , les classes d'objets, les méthodes, etc c'est ce qu'on a vraiment inventé de mieux dans le monde de la programmation.

Je suis en entreprise, je travaille avec un ERP, j'ai envie de pleurer tellement le langage de programmation est médiocre et tellement j'en bave; c'est pas un langage orienté objet, ça ressemble à du QBasic des années 80 avec des tas de variables globales

[topdawg]

@Mat.M:
Ça ne m'étonne pas que t'arrives à comprendre. D'abord, j'ai écrit

Actuellement, je bosse sur une recherche de plus court chemin dans un programme qui porte sur des partitions de guitare.

(plus court chemin, Dijkstra… c'est un peu immédiat. En l'occurrence, dans mon cas, c'est une version particulière de l'algorithme que j'applique).

Ensuite, tu auras fait quoi ? Lu le code que j'ai posté en sautant exprès les commentaires ? Et ensuite, tu penseras que tu l'as compris ?

Quant tu maitrises un minimum le C++, tu peux arriver à lire du code C++, comprendre les classes et leurs méthodes etc...

Et tout le monde est d'accord sur ce point-là: quiconque code dans un langage devrait arriver à lire du code dans ce langage. Mais dans la vraie vie, on ne parle plus de calcul de PGCD ou d'exercice d'insertion d'une valeur dans une liste chaînée. On parle de nombreux fichiers, fonctions, variables…

Mon problème, et je l'ai probablement dit plus tôt dans le fil de discussion, c'est que je ne comprends pas pourquoi il faut que je lise des myriades de lignes de code là où vingt secondes de lecture sur du texte écrit en simili-français aurait suffi. C'est comme dire qu'une table des matières ou un index n'est pas important parce qu'on sait tous lire depuis l'école primaire… J'ai pas envie de me taper tout un bouquin pour retrouver une section, pas plus que je n'ai envie de suivre le fil d'exécution d'un programme pour savoir que tel paramètre est 1-based alors que tel autre de telle autre fonction, pourtant du même périmètre que la première, est 0-based.

Mais non, je ne crois pas que le code se suffise à lui-même. Je suis juste heureux de ne plus côtoyer des gens qui, sous prétexte de masquer des lacunes en français, estimaient que la doc, c'est nul, ça sert à rien et ça se périme. Le diable est dans les détails, pas dans le général. Et ces détails, ces préconditions, ces alertes, ce sont les commentaires qui les donnent.

Qu'on puisse contester ou minimiser la nécessité ou l'utilité de la documentation, ça me dépasse. J'imagine qu'on est d'écoles différentes.

Quelqu'un a jamais mis le nez dans le code source d'un projet open source vraiment utile et utilisé ? Même le très sec Scintilla est documenté. Ou alors, il faudrait apprendre à lire et parler couramment les langages de prog. Ce n'est pas à la portée de nous autres, non-membres de la force Delta.

[Guilp]

Qu'on puisse contester ou minimiser la nécessité ou l'utilité de la documentation, ça me dépasse. J'imagine qu'on est d'écoles différentes.

C'est marrant, vous avez tous les deux raisons, mais ne vous mettez pas d'accord juste pour vous situer dans un contexte différent...

D'un côté, oui, le code parle de lui-même dans le cas où on découpe suffisamment son code en plein de petites fonctions et classes.

Donc, d'un autre côté, si on ne découpe pas son code, et qu'on laisse des méthodes de 300 lignes, alors il faut documenter un maximum le code pour, comme dis dans le post juste au dessus, ne pas avoir à lire le livre juste pour trouver un chapitre.

Le problème, dans tout ça, vient des gens qui ne font ni découpage des méthodes, ni documentation, et pondent donc un truc horrible à relire. Et le pire du pire, c'est quand ces gens, qui ne découpent pas leur code, omettent intentionnellement de documenter leur code sous prétexte que "un code est lisible de lui-même"