Discussion :

[_skip]

La méthode agile me laisse perplexe. Sur le plan théorique elle devrait aider à mieux aborder un projet. Par contre au niveau pratique, de ce que j'en ai vue, elle sert surtout à camoufler un bordel sans nom. Ce bordel n'est pas nécessairement le fait de l'équipe du projet.

(...)
Elles peuvent les utiliser en complément ou pas de l'approche Agile, les 2 ne sont pas exclusif l'un par rapport à l'autre. Pour avoir travaillé dans plusieurs compagnies, de mon point de vue, il n'y a pas de méthodologies miracles pouvant s'appliquer sans distinction à tous le monde. Chaque entreprise doit choisir celle avec laquelle elle se sent le plus confortable. Aujourd'hui la méthodologie à la mode est Agile, demain une autre la supplantera de mon coté je m'adapterai à celle que l'entreprise aura choisie.

Hum, ouais attention, il y a plusieurs méthodologies dites "agile", xp, scrum, evo etc... Il y a un aspect commercial à cela en le sens où l'on te vend des brochures et du coaching et certainement un petit effet de mode comme tu le soulignes.
Cependant elles ont généralement en commun le fonctionnement par itération et la validation régulière du travail avec le client final impliqué dans le processus. C'est peut être bien la seule chose vraiment importante à retenir, même si tu n'implémentes pas toutes les recommandations d'une méthode de travail ce qui est d'ailleurs bien souvent difficile, sinon impossible.

Quand on a à faire à un client ou une direction qui savent pas trop où ils vont difficile d'avoir quelque chose de cohérent derrière, peut importe la méthode utilisé.
(...)

Les gens ont tendance parfois à penser que du XP c'est foncer tête baissée et on verra ce qui sort, si ça va pas on recommence. Aucune méthode ne peut pallier à une mauvaise analyse des besoins, l'approche par itération permet de corriger légèrement le tir en cours de route mais si on part totalement de biais on a aucune chance de finir droit.

D'autant plus que nombre de clients vont certes trouver chouette d'être impliqué dans le cycle et de pouvoir tester les fonctionnalités au fur et à mesure, mais on échappe rarement à la question "Combien ça coûte". Et il est peu probable que le client accepte un "on fait ce que vous demandez" puis on continue tant que vous payez d'une itération à l'autre sans une offre cadrée au départ. En clair, sans analyse un tant soit peu fine, sans feuille de route à peu près claire et sans considération des risques, on a les mêmes chances de se vautrer qu'avec les autres méthodologies.

Donc voilà, il faut prendre ce qui est bon dans une méthodologie, savoir où l'on va mais surtout ne pas compter sur une application à la lettre pour écarter tous les risques. Tu as raison de souligner que c'est pas parce qu'on utilise telle ou telle méthodologie à la mode qu'on assure un projet, cependant certains concepts valent la peine d'être considérés. Même s'il est vrai que lorsqu'on vante les mérites de l'agile par rapport à du plus "traditionnel", on a tendance à caricaturer à mort ce dernier, équipe où la communication n'existe pas, où personne sait ce qu'il fout où on génère des m3 de paperasses dans le vide... Alors que bien des gens qui n'appliquent pas de méthodologies strictes font déjà certains choses de façon "agile" sans le savoir. De la même manière qu'un développeur utilise des patterns sans connaître leur nom dans le GOF, ou repèrent des code smells sans connaître le nom inventé par les auteurs de bouquins.

[Logan Mauzaize]

Je plussoie Nathael et _skip. Il ne faut pas confondre "se faire appeler" agile et "être" agile.
C'est un peu le problème quand il n'y a pas de certification ou d'audit sur un sujet. C'est comme les applications dîtes J2EE alors que c'est à peine plus que du standard. Ou pour reprendre la cuisine, ce n'est parce que je fais une pâte à choux et une crème chocolat que je fais un éclair au chocolat.


Commercialement, je pense que l'agile (le vrai) c'est très dur à vendre. Déjà ca demande une implication que le client ne souhaite pas trop. Par expérience, le client croit souvent qu'il suffit d'émettre 3-4 besoins et une fois le produit entre les mains les choses changent, ils rajoutent des tonnes de besoin. Avoir des produits montrables tôt (itération, démonstration, beta, peu importe le nom), permet souvent un client de prendre rapidement conscience de la direction qu'il souhaite donner à son produit.

Ensuite il y a le budget et la comptabilité. En gros, le client veut un prix packagé sans marge possible car le budget de l'équipe est établi sur cette estimation, que le budget du service se base sur le budget de l'équipe, et on remonte comme ça de sphère en sphère jusqu'au sommet de la direction. Un fonctionnement acceptable serait de donner une direction et de faire des avenants après chaque "revue de livraison".

Bref comme disait Souviron sur un autre fil (celui des méthodes agiles ou un autre, je me souviens plus), il faut que le client s'implique humainement et financièrement dans le produit afin de pouvoir "être" agile.

[popo]

Les jeunes ingenieurs n'ont pas tous, heureusement, des formations hyper vagues ; certains sont specialises, voir tres specialises, et dans ce cas il peut tout a fait etre comprehensible de ne pas connaitre la syntaxe de SQL. Par contre, un ingenieur digne de ce nom, meme s'il n'est pas competent en SQL a la base, doit etre capable d'etre forme rapidement dans ce langage (si ce n'est pas trop loin de ce qu'il fait) s'il est amene a travailler avec. (*)

Tu remarqueras que je n'ai pas cité SQL dans mon post. C'était volontaire. Il n'y a pas que la base données comme source de données. Il serait dommage de l'ignorer. En plus, comme la mode semble se tourner vers le .net aujourd'hui, il ne faut plus connaître SQL, il faut connaître Linq. Et demain ?

Oui ça tient aussi au principe de l'effet de mode : une nouvelle techno/méthode sort, et tout le monde fonce dedans tête baissée, soit par amour de la découverte (qu'on nomme aussi Geek dans les milieux autorisés ), soit parce que "les autres vont le faire, donc faut rester à la page".

La POO c'est loin d'être une nouvelle techno ! Je n'étais pas né lorsque le concept à été créé dans les années 60. Après c'est vrai que ça n'a vraiment commencé à être utilisé plus massivement dans les années 80 mais même là, ça fait un baille alors comme "nouvelle techno" j'ai vu un peu plus nouveau !

Non, non, non et non les gars! Je suis désolé, ce que vous avez vu de l'agilité c'est des branquignoles qui ne savaient pas faire. C'est comme si vous disiez que le premier pingouin qui sait mettre trois contrôles sur une fenêtre Winform est un pro du .net. La méthodologie Agile requiert d'être super carré et organisé. C'est pas un fourre tout sans nom. Vous avez connus que des tanches la dedans, tant pis pour vous mais n'allez pas dire que c'est nul car personne ne vous l'a montré correctement.

+1 même si le sujet à encore dérivé.
J'avais une très mauvaise opinion des méthodes agiles, jusqu'à ce qu'on applique réellement let surtout strictement la méthode.

[_skip]

Tu remarqueras que je n'ai pas cité SQL dans mon post. C'était volontaire. Il n'y a pas que la base données comme source de données. Il serait dommage de l'ignorer.

Il n'y a pas *que*, mais il y a *surtout* et dans *une proportion écrasante* dès qu'il est question de stockage structuré de données pour une application et ça ne semble vraiment pas sur le point de changer.

En plus, comme la mode semble se tourner vers le .net aujourd'hui, il ne faut plus connaître SQL, il faut connaître Linq. Et demain ?

Absolument pas d'accord dans le sens où Linq n'est guère un remplaçant pour SQL. La connaissance du SQL est un must-have pour quiconque veut utiliser une base de donnéées et ce peu importe la surcouche ORM (hibernate, JPA, active record, llblgen, linq) utilisée.

Sans connaissance SQL, tu pourras pas te rendre compte de ce que la couche d'abstraction génère comme ordre pour ta DB et des implications de ceux-ci et tu as l'assurance de finir avec une solution inefficace.

La seule chose qui pourrait selon moi justifier que l'on accepte la non connaissance des bases en SQL est la suivante :

• L'entreprise a des experts en la matière qui s'occupent de tout ça dans leur coin (et encore).
• La mission ou le domaine n'implique pas de BDD (par exemple domaine recherche ou informatique embarquée)

[Guilp]

Je souhaitais répondre par rapport à l'article de départ :

Moi aussi, je me répète sans cesse depuis que travail : "Je suis un ingénieur, pas un compilateur!".

Mais pour moi, le problème ne se situe pas aux questionnaires de recrutement. S'ils le font, c'est qu'ils sont obligés, ils n'ont plus le choix : ils ont BESOINS d'un compilateur humain! (ou du moins, ils en sont convaincus, et donc leur démarche de recrutement est légitime)

Pourquoi? Et bien parce que le problème est ailleurs...

Je me base sur ma propre expérience : Plusieurs missions dans une SSII que j'ai quittée pour aller chez un éditeur. TOUS les projets sur lesquels j'ai travaillé avaient ces caractéristiques :
- le code a été fait par des dev débutant qui codent en mode brouillon, architecture spaghetti
- les développeurs connaissant le projet, "ceux qui savaient", ont déjà quitté le projet
- différentes fonctionnalités ajoutées à l’arrache par un autre dev qui est encore plus perdu que les devs du début
- il n'y a aucune documentation, ni dans le code, ni ailleurs (et si il y en a, elle est obsolète)
- les décisions techniques sont prises par des chefs de projets métiers qui ont pour leitmotiv "ça a toujours marché comme ça, il n'y a pas de raison que ça change" (sauf dans ma boite actuelle, et c'est pour ça que j'y suis bien!)

Pour ceux qui ont lu le bouquin "coder proprement" (clean code, celui maintes fois recommandés dans le topic dédié de developpez.com)... sur ces projets, il est appliqué systématiquement l'inverse de chaque paragraphe de ce bouquin! ( par ex : noms de variables non significatives, méthodes de centaines de lignes, classes qui ont 1000 rôles, ...).

La seule manière de reprendre de tels projets, c'est d'être un compilateur humain! D'avoir une mémoire sur-humaine! Une concentration de mort vivant! De connaitre le langage sur le bout des doigts parce que découvrir la logique métier du projet à travers un code obscure, si en plus on ne connait pas bien le langage, c'est mission suicide!

On a donc ces milliers d'entreprises qui sont dans le même cas et pour qui cette situation est une routine. Elles vivent comme ça et continueront à vivre comme ça... Tout est trop avancé pour repartir de zéro, peur du risque, etc... Et c'est pour ça qu'on se retrouve avec toutes ces offres d'emploi où on demande à la recrue d'être un compilateur...

Ajoutez à ça le fait qu'en France, la confiance absolue au diplôme est telle que les chefs préfèrent demander sur leur annonce un bac+5 ou ingénieur "pour être sûr" (croyant que plus beau est le diplôme, plus on est sûr d'avoir ce monstre inhumain qui saura "compiler" leur projet), on se retrouve avec des gars comme dans l'article initial, qui veulent un boulot d'ingé et à qui on demande d'être un compilateur. Triste monde...

[arkhamon]

Je souhaitais répondre par rapport à l'article de départ :

Moi aussi, je me répète sans cesse depuis que travail : "Je suis un ingénieur, pas un compilateur!".

Mais pour moi, le problème ne se situe pas aux questionnaires de recrutement. S'ils le font, c'est qu'ils sont obligés, ils n'ont plus le choix : ils ont BESOINS d'un compilateur humain! (ou du moins, ils en sont convaincus, et donc leur démarche de recrutement est légitime)

Pourquoi? Et bien parce que le problème est ailleurs...

Je me base sur ma propre expérience : Plusieurs missions dans une SSII que j'ai quittée pour aller chez un éditeur. TOUS les projets sur lesquels j'ai travaillé avaient ces caractéristiques :
- le code a été fait par des dev débutant qui codent en mode brouillon, architecture spaghetti
- les développeurs connaissant le projet, "ceux qui savaient", ont déjà quitté le projet
- différentes fonctionnalités ajoutées à l’arrache par un autre dev qui est encore plus perdu que les devs du début
- il n'y a aucune documentation, ni dans le code, ni ailleurs (et si il y en a, elle est obsolète)
- les décisions techniques sont prises par des chefs de projets métiers qui ont pour leitmotiv "ça a toujours marché comme ça, il n'y a pas de raison que ça change" (sauf dans ma boite actuelle, et c'est pour ça que j'y suis bien!)

Pour ceux qui ont lu le bouquin "coder proprement" (clean code, celui maintes fois recommandés dans le topic dédié de developpez.com)... sur ces projets, il est appliqué systématiquement l'inverse de chaque paragraphe de ce bouquin! ( par ex : noms de variables non significatives, méthodes de centaines de lignes, classes qui ont 1000 rôles, ...).

La seule manière de reprendre de tels projets, c'est d'être un compilateur humain! D'avoir une mémoire sur-humaine! Une concentration de mort vivant! De connaitre le langage sur le bout des doigts parce que découvrir la logique métier du projet à travers un code obscure, si en plus on ne connait pas bien le langage, c'est mission suicide!

On a donc ces milliers d'entreprises qui sont dans le même cas et pour qui cette situation est une routine. Elles vivent comme ça et continueront à vivre comme ça... Tout est trop avancé pour repartir de zéro, peur du risque, etc... Et c'est pour ça qu'on se retrouve avec toutes ces offres d'emploi où on demande à la recrue d'être un compilateur...

Ajoutez à ça le fait qu'en France, la confiance absolue au diplôme est telle que les chefs préfèrent demander sur leur annonce un bac+5 ou ingénieur "pour être sûr" (croyant que plus beau est le diplôme, plus on est sûr d'avoir ce monstre inhumain qui saura "compiler" leur projet), on se retrouve avec des gars comme dans l'article initial, qui veulent un boulot d'ingé et à qui on demande d'être un compilateur. Triste monde...

J'ai plussé car cette description correspnd EXACTEMENT à ce que je rencontre à mon boulot tous les jours ! LEs enreprises passent leur temps à recruter, alors qu'il faudrait fidéliser ! Ca réduirait considérablement les pertes de connaissances, qui sont vitales à l'entreprise...

[souviron34]

C'est marrant ça dérive sur l'Agiité alors qu'il y a plusieurs débats sur ce sujet ici-même et dans le forum Conception.. Bon, passons...

La méthode agile me laisse perplexe. Sur le plan théorique elle devrait aider à mieux aborder un projet. Par contre au niveau pratique, de ce que j'en ai vue, elle sert surtout à camoufler un bordel sans nom.

Sans doute.. Comme dit plus haut, c'est à la mode et ça fait partie des buzz-words des commerciaux, managers, et autres administratifs ou enseignants qui ne savent pas ce dont ils parlent..


Je crois que je vais finir par proposer des formations...

Ce bordel n'est pas nécessairement le fait de l'équipe du projet. Quand on a à faire à un client ou une direction qui savent pas trop où ils vont difficile d'avoir quelque chose de cohérent derrière, peut importe la méthode utilisé.

Eh non, justemment.. L'agilité sert (normalement) à en tenir compte..

Des entreprises vont vers des processus plus lourde comme CMMI

Désolé de te contredire, mais CMMI est une norme de gestion de processus, pas une méthodologie de développement..

Tu peux avoir du CMMI en étant Agile ou en étant Waterfall...

ou encore s'appuient sur des templates, qu'il faut le reconnaitre sont très bien fait, fourni par IEEE (Std 1362-1998 Concept of Operations, Std 0830-1998 - SRS - Software Requirement Specifications, Std 1016-1998 - SDD - Software Design Descriptions).

C'est en ça que je disais plus haut que l'enseignement et les formations aux "nouvelles" méthodologies (dont les "agiles") est dénué de sens : ces normes, il est nécessaire de les connaître, qu'on soit ou non orienté vers du dev Agile..

Or la mode et les formations et les enseignants en général (il sufiit de lire les tutoriels ou bouquins présents ici) s'en fichent assez royalement, parce qu'ils sont juste titillés par le buzz-word et n'ont pas en général l'expérience de dev WaterFall classiques à grande échelle..

On ne peut faire un dev corect, quelle que soit la méthodologie, si on ne sait pas ce qu'on doit remplir et quels sont les input/outpur de chaque étape...

Ce serait comme vouloir couper un virage sur un chemin sans savoir lire les courbes de niveaux...

Après pour les docs, moi je suis un fervent amateur des Word et des classeurs bien organisés, mais c'est vrai que je préconise plutôt ça pour l'exploit et le support.

moi aussi

Alors là je ne peux qu'abonder ! Là où Agile me semble dangereux, c'est que justement cette excuse de la réactivité pousse à générer le bordel. Sans aller jusqu'à dire que ça le provoque, ça l'encourage silencieusement...

Non, ça n'est pas là où l'Agile peut être dangereux.. C'est là où la MODE de l'Agile peut le rendre dangereux...

Par non assimilation initiale, par les formateurs, enseignants, et/ou bouquins, de ce qu'est la réalité et non pas la théorie...

D'où un sentiment global que l'Agilité, c'est faire un peu ce qu'on veut dans un cadre non contraignant, et du coup faire un peu n'importe quoi...

(c'est couplé avec la notion que "tout le monde est bon", que on peut avoir un diplôme de CP (!!!!), eetc etc.. Toutes conneries de ces dernières années..)

Non, non, non et non les gars! Je suis désolé, ce que vous avez vu de l'agilité c'est des branquignoles qui ne savaient pas faire. La méthodologie Agile requiert d'être super carré et organisé. C'est pas un fourre tout sans nom. Vous avez connus que des tanches la dedans

+100

Absolument..

La POO c'est loin d'être une nouvelle techno ! Je n'étais pas né lorsque le concept à été créé dans les années 60. Après c'est vrai que ça n'a vraiment commencé à être utilisé plus massivement dans les années 80 mais même là, ça fait un baille alors comme "nouvelle techno" j'ai vu un peu plus nouveau !

Non, pas du tout.. Industriellement ça n'a commencé à être utilisé massivement que en 1996 à peu près, et à l'époque uniquement sur PC & Windows., avec VC++, et réellement depuis 2000-2002 un peu plus partout..

[arkhamon]

Non, pas du tout.. Industriellement ça n'a commencé à être utilisé massivement que en 1996 à peu près, et à l'époque uniquement sur PC & Windows., avec VC++, et réellement depuis 2000-2002 un peu plus partout..

Je constate qu'on oublie allègrement NeXT qui date du début des années 90... Bon d'accord, on peut pas dire que ça ait été "massivement" utilisé... Mais je me souviens qu'à l'époque du glorieux Sicob, on était tous allés baver devant le stand de NeXT Computers...

[souviron34]

Je constate qu'on oublie allègrement NeXT qui date du début des années 90... Bon d'accord, on peut pas dire que ça ait été "massivement" utilisé... Mais je me souviens qu'à l'époque du glorieux Sicob, on était tous allés baver devant le stand de NeXT Computers...

oui mais à l'époque on voulait juste se brancher sur la bibliothèque
(tu codais en quoi ? Moi en C, et X11)

Comme avec InterGraph...

Parce que sinon, les SGI de l'époque étaient quand même le top du top en traitement, sans avoir un ordi dédié ..

Bon, de toutes façons, en masse c'est quand même apparu au départ sur Windows, vers 96, qui n'était pas quand même le truc industriel, et au début des années 2000 sur Linux, principalement pour compatibilité avec Win.. Et ensuite, vers les années 2006, simplement parce que plus aucun jeune ne savait autre chose (un certain nombre de discussions ici-même sur la Grande Supériorité de l'Objet ont eu lieu., agrémentées de quelques mots choisis comme "dinosaures", "obsolètes", et autres... )

[arkhamon]

oui mais à l'époque on voulait juste se brancher sur la bibliothèque
(tu codais en quoi ? Moi en C, et X11)

Comme avec InterGraph...

Parce que sinon, les SGI de l'époque étaient quand même le top du top en traitement, sans avoir un ordi dédié ..

Bon, de toutes façons, en masse c'est quand même apparu au départ sur Windows, vers 96, qui n'était pas quand même le truc industriel, et au début des années 2000 sur Linux, principalement pour compatibilité avec Win.. Et ensuite, vers les années 2006, simplement parce que plus aucun jeune ne savait autre chose (un certain nombre de discussions ici-même sur la Grande Supériorité de l'Objet ont eu lieu., agrémentées de quelques mots choisis comme "dinosaures", "obsolètes", et autres... )

A l'époque, je codais en Turbo Pascal (maintenant Delphi) et de mémoire, un bouquin sur la POO est paru chez Borland en 1996.
Pour ma part, avec un pote, on avait sorti ça chez Micro Applications en 1992:

http://www.amazon.fr/Toolbox-turbo-p.../dp/2868996647
pour accompagner la sortie de Turbo Pascal 6.0 qui introduisait la POO...

[souviron34]

Chapeau bas




Moi j'étais sur des Sun, sur des VaxStations, des HP, ou des SGI... Unix et VMS... Strictement rien d'OO.. A part 1 an de Delphi (et donc Object-Pascal) et 1 an de VB..

[arkhamon]

Chapeau bas

Merci

En fait, il a suivi de très près celui là qu'on avait sorti un peu plus tôt :

http://books.google.fr/books/about/T...AJ&redir_esc=y

Celui là concernait juste la programmation structurée. Le suivant introduisait une touche de POO pour les débutants. Faut dire qu'à l'époque, c'était pas répandu...

[DevTroglodyte]

Non, pas du tout.. Industriellement ça n'a commencé à être utilisé massivement que en 1996 à peu près, et à l'époque uniquement sur PC & Windows., avec VC++, et réellement depuis 2000-2002 un peu plus partout..

Plus de 10 ans, ça fait pas trop mal pour une techno-buzz Mais j'approuve totalement le fait que les enseignants ont sauté dessus sans réellement savoir de quoi il s'agissait... J'ai pu en voir les ravages chez certains étudiants pour qui la notion même d'objet restait obscure, grâce aux super formateurs qui eux même n'avaient pas l'air de savoir ce que c'est... Perso j'ai eu du pot, j'ai eu des cours d'architecture et de C, ça aide énormément mine de rien

[top-dogg]

Quel crétin ce type.

« Il est plus important que je sois en mesure de vous dire quand et où je devrais utiliser l’héritage et quand et où je devrais utiliser le polymorphisme, que d’être en mesure de cracher une définition », écrit clements.

S'il sait quand et où utiliser l'héritage/polymorphisme, pourquoi n'est-il pas capable d'en cracher une définition?

Faudra pas qu'il se plaigne de ne pas trouver un emploi et qu'il pense à une reconversion professionnelle...

[souviron34]

Plus de 10 ans, ça fait pas trop mal pour une techno-buzz

le techno-buzz et la critique des formations/enseignants, c'était pour Agile

Mais on peut effectivement dire la même chose pour l'OO..

[Mat.M]

bonjour,

Je recrute pour ma boite (qui est une société de service), alors effectivement on aimerait bien poser des questions sur quel pattern pour faire ci, quel algo pour faire ca mais voila, plusieurs problemes se posent:
-Deja je ne sais pas forcément à qui j'ai affaire, ok j'ai le CV sous les yeux mais y en a qui pipotent ou enjolivent. Dur de s'y fier.
.

et les motivations réelles du candidat est-ce qu'on s'y intéresse également ?
-sur quelles technos il a envie de travailler si c'est sur Java ou C# ou !c++ ?
-pourquoi la programmation ça passionne le candidat ?
-qu'est ce qu'on peut avoir comme "carotte" lorsqu'on est embauché pour pouvoir par exemple devenir chef de projet ??
-qu''est ce que la société de service pour laquelle tu travailles peu m'apporter ( formation, perspective d'évolutions,apprentissage métier....)

Moi lorsque je vais à un entretien d'embauche c'est pour faire preuve de ma passion pour l'informatique pas pour répondre à des questions idiotes ou des tests débiles de personnalité.

Je m'excuse d'être direct parce que je n'ai jamais subi autant d'entretiens d'embauche totalement stupides menés par des gens qui semblent totalement idiots...

je viens de passer des tas d'entretiens la majorité c'était des interrogatoires de police fallait justifier son C.V. à la virgule près
.La plupart des recruteurs que j'ai vus en entretien c'est vraiment digne du sketch de Bigard : c'est pour 2 personnes pour manger ? non c'est pour faire un tennis...

résultat tu vas embaucher un candidat qui vont te sembler avoir le profil idéal pour éviter la fameuse erreur de casting mais qui va te larguer au bout de 2 ans parce qu'il s'ennuie au travail et parce que toi en tant que cadre tu ne sauras pas le stimuler dans ses projets.

Voilà mon coup de gueule...

[gwinyam]

Tout dépend du poste auquel il prétend. Si c'est du dev comme ça pour du dev et surtout plutôt junior ou moyen, effectivement, "on s'en fout".

Par contre, pour un expert, il est inadmissible qu'un candidat ne connaisse pas un minimum les structures de fond d'un langage. C'est par ces connaissances que tu iras chercher les optimisations, pas forcément en performances parce que les compilo commencent à être imbattables mais sur la qualité du code, de son architecture, des patterns, etc... ça jamais un compilateur ne saura rivaliser avec un homme.

Et sans la connaissance de fond, autant oublier toute idée de savoir faire ça.

[Bluedeep]

-pourquoi la programmation ça passionne le candidat ?

Depuis quand faudrait il être "passioné" pour faire un bon professionnel ? je trouve ça ridicule.

Moi lorsque je vais à un entretien d'embauche c'est pour faire preuve de ma passion pour l'informatique pas pour répondre à des questions idiotes ou des tests débiles de personnalité.

Il faut bien trouver un moyen d'éliminer les personnalités débiles; en l'occurence, j'aurais une méfiance instinctive vis à vis d'un "passionné". Je préfére un pro, tout simplement.

Je m'excuse d'être direct parce que je n'ai jamais subi autant d'entretiens d'embauche totalement stupides menés par des gens qui semblent totalement idiots...

Je traduis ton propos : ces idiots n'ont pas compris quel grand génie ils avaient en face d'eux; ça démontre donc qu'ils sont idiots.

[arkhamon]

bonjour,



et les motivations réelles du candidat est-ce qu'on s'y intéresse également ?
-sur quelles technos il a envie de travailler si c'est sur Java ou C# ou !c++ ?
-pourquoi la programmation ça passionne le candidat ?
-qu'est ce qu'on peut avoir comme "carotte" lorsqu'on est embauché pour pouvoir par exemple devenir chef de projet ??
-qu''est ce que la société de service pour laquelle tu travailles peu m'apporter ( formation, perspective d'évolutions,apprentissage métier....)

Moi lorsque je vais à un entretien d'embauche c'est pour faire preuve de ma passion pour l'informatique pas pour répondre à des questions idiotes ou des tests débiles de personnalité.

Je m'excuse d'être direct parce que je n'ai jamais subi autant d'entretiens d'embauche totalement stupides menés par des gens qui semblent totalement idiots...

je viens de passer des tas d'entretiens la majorité c'était des interrogatoires de police fallait justifier son C.V. à la virgule près
.La plupart des recruteurs que j'ai vus en entretien c'est vraiment digne du sketch de Bigard : c'est pour 2 personnes pour manger ? non c'est pour faire un tennis...

résultat tu vas embaucher un candidat qui vont te sembler avoir le profil idéal pour éviter la fameuse erreur de casting mais qui va te larguer au bout de 2 ans parce qu'il s'ennuie au travail et parce que toi en tant que cadre tu ne sauras pas le stimuler dans ses projets.

Voilà mon coup de gueule...

Je Plusse !
C'est un coup de gueule que je voulais passer, tu m'as coupé l'herbe sous le pied !
En effet, les recruteurs ne s'intéressent que à ce que le candidat va leur apporter, mais pas l'inverse, à savoir ce que la boîte va apporter au salarié ! Et ça c'est catastrophique car ça produit des générations complètes de personnes désabusées à 30 ans, qui ne se reconnaissent pas dans leur boîte, et qui du coup bossent pour bouffer. Et vous avez beau avoir le candidat parfait, 2 ans après il se casse parce qu'il en a marre d'être considéré comme un matricule.
Les entreprises feraient mieux de s'intéresser aux personnes ca ferait des gens motivés, et les gens motivés font du bon boulot, s'améliorent, cherchent des solutions propres et élégantes, découvrent... bref vivent !

Moi quand je faisias passer des entretiens d'embauche, la première chose que je regardais, c'était les loisirs. Le reste, en éxagérant, je m'en fous, j'aurai bien l'occasion de vérifier. Et s'il connait pas la différence entre l'injection polymorphique semi-ajustée et l'héritage multiple à implémentation dérivative, je m'en fous royalement : il aura bien l'occasion d'apprendre si c'est vraiment nécessaire. Etant entendu qu'il y a quand même des bases à savoir, ou du moins à comprendre...

D'ailleurs, qui connaît la différence entre l'injection polymorphique semi-ajustée et l'héritage multiple à implémentation dérivative ?
Cherchez pas, je viens d'inventer... Mais posez donc al question à un candidat juste histoire de regarder sa réaction face à un pipauteur...

[arkhamon]

Depuis quand faudrait il être "passioné" pour faire un bon professionnel ?

Depuis que quand on l'est pas, on se lève triste et forcé et on fait du bouot de merde parce que c'est alimentaire... Déjà qu'on préfèrerait être sur la plage plutôt que de bosser, si en plus c'est pour un boulot de merde...

je trouve ça ridicule.

Ben tiens...

Il faut bien trouver un moyen d'éliminer les personnalités débiles; en l'occurence, j'aurais une méfiance instinctive vis à vis d'un "passionné". Je préfére un pro, tout simplement.

Ah bon parce que les deux c'est pas possible ? Pour le coup, c'est ta remarque que je trouve ridicule !

Je traduis ton propos : ces idiots n'ont pas compris quel grand génie ils avaient en face d'eux; ça démontre donc qu'ils sont idiots.

non ça montrait qu'ils ne s'intéressaient pas au candidat en tant qu'être hmain, suelement une machine.

Dis donc BlueDeep, je t'ai connus un peu mieux inspiré. Pas bien dormi ?