L'Agilitateur - Comment être vraiment sûr de recruter un mauvais ingénieur informatique - Commentaires

Comment être vraiment sûr de recruter un mauvais ingénieur informatique - oaz

oaz — Sat, 06 Jan 2007 12:23:00 +0100

Mon billet ne portait pas spécifiquement sur une comparaison ingénieur informatique / ingénieur métier mais puisque le sujet est abordé, j'en profite pour donner succintement mon avis.
Cette dichotomie est un faux problème. Il est tout aussi illusoire de croire qu'une équipe composée uniquement d'"ingénieurs informaticiens" va être capable de développer un truc correspondant aux besoins du métier sans véritables connaisseurs du métier faisant partie intégrante à temps plein de l'équipe de développement que d'imaginer qu'une personne connaissant bien le métier mais sans véritable connaissance approfondie de techniques de développement (qui ne s'apprennent pas en quelques semaines) puisse écrire du code bien testé, maintenable et efficace.

Comment être vraiment sûr de recruter un mauvais ingénieur informatique - Abdelkader BAAZIZ

Abdelkader BAAZIZ — Sat, 06 Jan 2007 10:37:13 +0100

Vous voulez recruter un mauvais ingénieur informatique (développement métier) ... eh bien recrutez un ingénieur informaticien !!!
Pour ma part, je prefère recruter un ingénieur métier maitrisant le developpement qu'un ingénieur informaticien essayant de comprendre le métier (bonjour les dégats)!!!
Un ingénieur informaticien quant à son rôle réel c'est le développement des outils de developpement, la disponibilité et la sécurité des SI et des infrastructures.

Comment être vraiment sûr de recruter un mauvais ingénieur informatique - Oaz

Oaz — Tue, 27 Jun 2006 00:31:28 +0200

Je connais bien ce problème là... Le top, c'est le candidat qui justifie son inaptitude à réfléchir à un problème sur le papier en disant que "devant le PC il aurait résolu le problème très rapidement". Et j'en ai vu plus d'un dans cette catégorie...

Comment être vraiment sûr de recruter un mauvais ingénieur informatique - Avangel

Avangel — Mon, 26 Jun 2006 09:37:19 +0200

J'aimerais réagir sur le dernier point. Je suis encore en filière universitaire, et il nous a été souvent demandé de produire du code sur papier pour un examen. Cela paraît ridicule étant donnés les outils de développements d'aujourd'hui. Néanmoins, cela oblige à maîtriser mieux le code, c'est-à-dire que chaque ligne qu'on écrit est réfléchie un minimum et ne contient pas 10 erreurs qui nécessiteront 10 compilations pour les détecter (bon j'exagère mais l'idée y est).

J'ai passé la plupart des TPs avec le même camarade, issu d'un IUT, donc très bon au niveau programmation. Nous avions deux approches différentes : lui consacrait 40% du temps à coder très vite et 60% à débugger, et moi je consacrais 70% du temps à coder (en soignant la conception), et 30% à débugger. Au bout du compte nous terminions presque en même temps à chaque fois. Par contre, après discussion, l'architecture que j'avais conçue permettait souvent plus de flexibilité et de stabilité.

En résumé, prendre un peu de temps pour concevoir une architecture propre, et produire ainsi un code déjà débuggé en majorité, ça marche aussi bien que de coder comme un fou et passer un temps fou à débugger avec le compilateur...