Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Discussion :
Alors là je dis bravo ! Cette analyse est très pertinente, et sans pour autant être la généralité, elle s'applique malheureusement très (trop) souvent.Envoyé par zelegolas2
Quant à la dernière phrase (en fait l'avant dernière), elle est tellement vraie... que tout le monde l'oublie ! Mais certaines boites redécouvrent que le plaisir de travailler fait les entreprises performantes, car fiables... A méditer...
Un vrai diplôme d'ingénieur c'est des savoirs mais aussi une manière de raisonner qui elle ne sera pas dépassée...
Retrouvez moi sur :
Mon Espace Developpez.com-------------------------------
Mais surtout je dirai.
On fait pas une école d'ingénieur pour apprendre, mais pour apprendre à apprendre rapidement. Sinon on se passerai bien de la multitude de projets portant sur des technologies non vues en cours qu'on doit rendre en des temps très courts.
Ce sont ces expériences qui nous enseignent à raisonner, faire des choix concis, clairs et rapides pour le bon déroulement du projet et pouvoir fournir un résultat.
Et c'est pourquoi on appelle ces formations "généraliste". C'est amusant comme de base, beaucoup pense qu'un spécialiste c'est mieux qu'un généraliste au sens du diplôme. C'est oublié qu'un spécialiste aura bien souvent une vue tronqué et très partiel d'un problème...Mais surtout je dirai.
On fait pas une école d'ingénieur pour apprendre, mais pour apprendre à apprendre rapidement. Sinon on se passerai bien de la multitude de projets portant sur des technologies non vues en cours qu'on doit rendre en des temps très courts.
Ce sont ces expériences qui nous enseignent à raisonner, faire des choix concis, clairs et rapides pour le bon déroulement du projet et pouvoir fournir un résultat.
Je reviens ce matin et paf 15 réponses... Je me fends donc de la mienne...
J'ai lu plusieurs choses qui trouvent echo à mes oreilles : un ingénieur n'est pas un technicien, on lui demande effectivemetn de réfléchir au concept général. Ne faisons pas l'amalgame entre chef de projet (forcément plus généraliste) et analyste voire programmeur. Bien sur que le programmeur doit connaître els rouages précis du langage qu'il manipule. Masi ça n'est pas le boulot de l'ingénieur qui lui pense au schéma plus global. Encore une fois, j'ai l'impression qu'on fait un gentil amalgame entre les métiers de l'informatique et du développement en général. Dommage.
Autre chose, ne partons pas sur LE truc super hyper précis que personne ou presque n'utilise ! C'est beau de connaître la définition de la Mytochondrie, masi c'est plsu dur à replacer dans une conversation mondaine (remarquez j'ai réussi), pareil avec polymorphisme récurrent de métaclasses trans-typées (oops je pense aps que cette bête existe, c'est pour les besoins de la démonstration) : c'est probablement un concept magnifique mais ça sert combien de fois dans une carrière ? Il en va des grands concepts comme de la chasse au canon : c'est spéctaculaire, mais bon...
J'ai vu beaucoup de notions en POO qui sont magnifiques, mais honnêtement elles servent combien de fois ? Et qui plus est, les personnes qui viennent derrière et tentent de réutiliser les classes se heurtent au problème de comprendre ce que le concepteur a voulu faire. Du coup, ça finit en réécriture des classes...
Je ne vois pas en quoi la vue tronquée et partielle d'un problème serait liée au fait d'être généraliste ou spécialiste ???
Ce que je retiens de 10 ans dans l'industrie sur les ingénieurs c'est que pour trouver des solutions ça turbine, ça part dans tous les sens (à cause de leur non spécialisation justement), par contre pour appliquer c'est une autre paire de manches....
Comme me l'a dit un ingénieur, n°3 dans l'organigramme d'une très grosse boite....si tu veux trouver des solutions théoriques à un problème adresse toi à un ingénieur....si tu veux solutionner concrètement un problème, adresse toi à quelqu'un d'autre...
Je trouve qu'en France il y a un clivage trop gros entre chaque type de personnel (ingénieur, tech, non diplômé) alors qu'une complémentarité serait plus intéressante...
C'est aussi des notions de base pour pouvoir comprendre les technologies, des notions de maths, de physique, de mécanique, d'électronique, etc.
On ne retient pas tout, on ne se sert pas de tout, mais personnellement, j'en ai réutilisé pas mal à un moment ou un autre, que ce soit pour comprendre les terminologies de métiers variés, faire la différence entre des données foireuses ou cohérentes, lire des papiers de recherche sur de nouvelles technologies, résoudre mathématiquement plutôt qu'empiriquement, etc.
Et c'est un énorme avantage par rapport à ceux qui en reste au niveau du "cargo cult" comme disent les américains.
Faut pas confondre le tronc commun des écoles d'ingénieur avec le diplôme. Je suis en dernière année d'étude pour un diplôme d'ingénieur en informatique et je n'ai jamais eu aucun cours sur la mécanique. Pourquoi ? Parce que je n'ai jamais fait de Tronc commun ou de Prepa.
Faut pas l'oublier ça... Près de 50% des ingénieurs diplômés proviennent de DUT ou autre diplômes BAC+2/+3 et n'ont donc pas fait de Prépa.
La formation d'ingénieur va donner de bonne base c'est certain mais croire qu'en suite la manière de raisonner est acquis pour la vie c'est une erreur.
Une erreur que font malheureusement beaucoup d'ingénieurs une fois leur diplôme en poche. En informatique des concepts nouveaux apparaissent régulièrement. Les technologies et les outils évoluent. La manière de raisonner doit s'adapter afin de les prendre en compte et ainsi être capable d'utiliser au mieux ces nouvelles technologies.
Devoir se remettre en cause n'est pas un processus facile mais c'est nécessaire. L'informatique est un domaine difficile car il est en perpétuel mutation ce qui oblige un bon informaticien à se remettre en cause régulièrement.
Dans l'histoire le diplôme aide en début de carrière, ensuite c'est plus une question de personnalité. Certains ingénieurs vont très bien évoluer, d'autres continueront à vouloir appliquer quelque chose qui est dépassé.
Sur ce point tu as raison. PAr contre, il me semble intéressant de faire une distinction que je vous propose : séparer les "ingénieurs" des "ingénieurs en informatique". Je m'explique. Et j'ai pas forcément raison, c'est ma façon de voir les choses.
L'informatique est en fait constituée d'une ribambelle de spécialité qui ne partagent parfois que la définition d'un Bit. Aucune similitude en effet entre un ingénieur réseau, un ingénieur BDD et un ingénieru en traitement du signal. Si ils ont un autre point commun : cette capacité à réfléchir poru conceptualiser un problème et trouver une solution dans leurs domaines.
Dans l'aviation, il y a des ingénieurs en aérodynamique, en réacteurs, en électricité, en informatique embarquéee, en résistance des matériaux, en chimie... Et chacun fait son boulot sans aller empiéter sur le terrain des autres. Et ensuite, (pour reprendre mon cheval de bataille), y a des techniciens qui assemblent les réacteurs, et des "petites mains" qui fixent les fauteuils au plancher...
PAr contre en informatique, on exige de l'ingénieur qu'ils soit expert en réseau, en BDD, en stats, en technologie des matériels. Et faut aussi qu'il sache coder, et qu'il fasse ça bien surtout ! Effarant !
Je plaide pour un retour aux sources, je veux dire un retour au bon sens !
Non, pas effarant ; tu viens de délayer longuement pour constater quelque chose qui tient en une seule phrase :
"actuellement la fabrication de logiciel n'est pas encore industrialisée".
Cette façon de penser reste encore aujourd'hui un idéal. La réalité est bien différente... D'où l'idée d'imaginer de nouvelles méthodes de développement
De quel ingénieur parles-tu ? Ingénieur en informatique ça ne signifie pas grand chose pour moi.
Moi, je suis ingénieur en développement logiciel. J'ai donc appris à réaliser certaines tâches qui vont de l'analyse des besoins à la qualification d'un logiciel. Quand je suis sorti de l'école je n'avais aucune expertise en réseau, en bdd ou dans un quelconque langage. J'avais des connaissances, plus ou moins approfondies (cela dépend de l'école, moi c'était le logiciel embarqué).
Aujourd'hui, je suis plus ou moins spécialisé dans un domaine technique (os, langage, ...) de part mon experience (totalement différente du monde de l'embarqué), mais je participe toujours à chaque phase du développement. Je ne suis toujours pas expert en réseau ou bdd.
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éfinitionPffff... L'entretien va justement vérifier si tu sais définir le polymorphisme rapidement et clairement pour être sûr que tu sois capable de détecter son utilisation en temps voulu et bien l'appliquer. Ca me fait rire de dire "ce concept je l'utilise quand je veux de façon optimal, mais je dois chercher sa définition dans google". Le réflexe "je sais ou chercher donc je n'apprends plus" est une calamité. Ces personnes pensent savoir mais n'ont pas compris le concept puisqu'il le recherche pour le définir. C'est une perte de temps, moi je ne l'embauche pas.toute question qui prend 5 secondes pour trouver une réponse sur Google n’est pas une bonne question
Les questions de syntaxe sur une techno qui sera vraiment celle utilisée et nécessaire à l'emploie permettent aussi de vérifier les connaissances du candidat et sa familiarité avec le langage. Par exemple, c'est bien d'avoir un éditeur wysiwyg pour faire des interfaces graphiques en java, mais si tu ne connais pas un minimum les classes swing, leur arbre d'héritage, la notion d'évènement, ... tu feras n'importe quoi.
On est à limite entre "connaitre" et "comprendre".
Je ne fais que très peu de POO, donc le polymorphisme, je connais peu (bien que je l'avais compris lors des cours de POO). Tu me dis "qu'est ce que le polymorphisme?", je réponds "euh.....". Mais quand je lis sur Wikipédia :
Je me dis "ah c'est ça le polymorphisme !". Et je m'aperçois que j'ai fait du polymorphisme en Python avec mes classes dérivés en codant un outil de tests. Je le redis, je ne fais que très peu de POO, quelqu'un qui en fait et se prétend bon en POO se doit de le savoir.Polymorphisme par sous-typage (dérivation)
L'idée est de partir d'un type et de le modifier. Par exemple, on peut créer une classe de base, puis faire des classes dérivées.
L'exemple du polymorphisme n'est sûrement pas le meilleur d'ailleurs, le polymorphisme est un concept important en programmation utilisant un tel paradigme. Si tu ne sais pas du tout ce que c'est, tu ne peux pas le trouver en 2 minutes dans Google, et surtout le comprendre ! Je ne connais pas swing, mais idem, ce n'est pas en 2 minutes sur Google que ça se règle. Il faut les compétences de bases et même un peu plus pour faire du bon taff !
En revanche, je demande "que fait le mot-clé volatile en C ?", une recherche Google est acceptable. C'est un détail du langage. L'effet de ce mot-clé n'est pas très violent, et ce n'est pas une notion essentielle en C. Et encore, en général ! En programmation embarqué, c'est important !
Tout dépend du contexte, il n'y a pas de bonnes et de mauvaises questions universelles, applicables à tous les postes et à tous les niveaux de compétences.
D'accord avec BKtero.
Juste une petite remarque en passant : il fut un temps où il était encore possible d'être super pointu dans plusieurs domaines. Je vous parle du temps ou Internet débutait avec des modems 1400 bauds, où Windows était singulièrement plus simple, ou il existait moins de 6 langages de développement "massivement" utilisés...
L'informatique ayant une évolution vertigineuse, je pense sincèrement qu'il devient impossible d'être multi-spécialiste, à part quelques génies. Ou alors il faut y consacrer la totalité de son temps. Non pas que je sois nostalgique de l'ancien temps (encore que...) mais je pense que ça va un peu trop vite pour les vieux machins comme moi. Du coup, en entretien, on a forcément du mal à être performant si l'interrogateur se pique au jeu et décide d'aller "un pont trop loin...".
Je reviens sur un de mes précédents post sur ce fil, vouloir toujorus les meilleurs me semble dangereux car on laisse tomber les autres qui ont probablement encore "du jus".
On a à peine le temps de se familiariser avc une technologie que la suivante est déjà presque obsolète. Avant on avait des spécialistes BDD, maintenant on a des spécialistes Oracle 10g...
Je suppose qu'il faut lire 14400 bauds ? car je n'ai aucun souvenir d'Internet à 1400 baud (même le minitel 1 c'était du 1200/75).
Massivement utilisés, il y en a guère plus.où Windows était singulièrement plus simple, ou il existait moins de 6 langages de développement "massivement" utilisés...
Je n'ai pas l'impression que le nombre de langages se soit multiplié, au contraire, du fait de la quasi disparition des langages "propriétaires".
Si on admet que nous sommes de la même génération (je n'en sais rien) je ne suis pas vraiment d'accord avec toi; pas du tout même.L'informatique ayant une évolution vertigineuse, je pense sincèrement qu'il devient impossible d'être multi-spécialiste, à part quelques génies.
Exemple : les questions de réseaux se sont plutôt largement simplifiées par rapport à l'époque où il fallait jouer avec des protocçoles plus ou moins incompatibles sur les différents niveaux, le tout avec des débits qui empêchaient l'encapsulation brutale.
Quiconque a du gérer des archi effroyables où il fallait faire causer, par exemple, une appli dans un monde IBM/SNA avec une autre dans un monde CTOS/HDLC, le transport distant se faisant sur du X.25 à un débit de ligne (et à un coût au volume !!!!) ne permettant pas sérieusement de supporter le diminution du ratio payload/débit en encapsulant les protocoles, ne peut que saluer la simplicité actuelle.
Bref, non, je ne partage pas ton point de vue.
Sans compter que, financièrement, le métier était beauuuucoup plus valorisé à cette époque regrettée .
En fait je me suis un peu trompé (la fatigue certainement) c'était pas 1400 mais 1200 avec un vieil Olitec. Et on a fait la même erreur, c'était pas du BAUD mais du bps...
En fait il y en a quand même pas mal, plus qu'avant. Et comme je ne connais pas les langages proprios... A l'époque, on avait principalement BASIC, C, Pascal, COBOL, ASM, SQL, ADA et FORTRAN (un peu plus épisodique), LIST, Prolog,
Maintenant y a C, C++, C#, Java (avec toutes ses variantes et autres Swings...), Delphi, VB, SQL, PHP, Python, PERL, HTML 1, 2, 3, 4..., CSS, XML, XSDL, le tout encapsulé dans une multitude d'EDI et autres frameworks (VCL, FMX, .Net, JRE...), et j'en oublie encore certainement un bon paquet ! Ca fait quand même une grosse différence...
Et en plus, Turbo Pascal de l'époque n'a plus rien à voir avec Delphi XE2 de maintenant, que ce soit au niveau richesse du langage qu'an niveau de la compléxité !
C'est vrai ça me rappelle des bon souvenirs : faire causer des B38 sous CTOS avec un Tandem via du X.25, ou faire causer un RS6000 en Ethernet avec une imprimante HP en Token Ring c'était fun. A peu près autrant que d'installer IP sur des serveurs Novell configurés en Maître/esclave... J'ai géré des archi assez complexes en salles des marchés (architectures de flux boursiers en temps réel avec contributions externes et autres satellites). C'est vrai que c'était hardu, mais justemetn on était dans un domaine spécifique : le réseau. ET passé cette difficulté, le reste était assez simple (sauf la config de TCP/IP sous DOS 5).
Et contrairement à ce que tu dis, le réseau ne s'est pas simplifié, bien au contraire, il suffit de regarder la pallanquée de nouveaux protocoles et transports existant pour s'en rendre compte (PPP, PPPoE, DSL avec toutes ses variantes (ADSL, SHDSL...), Wan, Multicast, Routages divers, 100BaseT, 1000BaseX, 802.11 (avec toutes les lettres de l'alphabet derrière), BT, IrDA, ToIP...
Ca c'est bien vrai ! Faut dire aussi que à l'époque nous étions moins nombreux...Sans compter que, financièrement, le métier était beauuuucoup plus valorisé à cette époque regrettée .
Autant je veux bien croire que certaines questions trop pointues sur les langages n'ont pas d’intérêt, autant savoir ce qu'est le polymorphisme , et la différence entre un Set et une List ( peut importe comment on les appelle suivant les langages ) me parait un minimum pour qui veut faire du développement.
Pareil pour les design pattern , les expressions régulières ou unicode, c'est vrai qu'une recherche Google suffit, mais encore faut-il savoir que ça existe.
Y a quand même un minimum à connaitre.
Personnellement j'ai vu des candidats issus d’école d'ingé/info qui n'avaient jamais entendu parler de transaction sur une base de données ou n'avait pas la moindre idée de ce que pouvait être un octet, ou d'autres pour qui la seule différence entre Java et C++ c'est que le code est pus joli.
Le souci c'est qu'il y a effectivement une ambiguïté avec le terme ingénieur.
Non, un ingénieur n'est par définition pas un compilateur, dans le sens où l'entend les entreprises, si, entre autres fonctions.
1/ sauf être super fort et apprendre un langage uniquement en théorie, un ingénieur passe forcément par de la pratique. Il connait donc un minimum de syntaxe.
2/ l'entreprise veut un développeur-pas-trop-spécialisé-et-adaptable, et nomme ça "ingénieur".
Après, ça dépend du poste proposé, mais des questions techniques pointues ne sont pas absurdes. Pas plus que de demander de définir le polymorphisme : comme certains l'ont souligné, ils utilisent le concept sans le savoir; et à l'inverse, j'aimerai savoir quelle est la proportion des ingés qui ont réellement eu à manier ce concept (ou un autre), notamment en début de carrière.
Mais sinon, ce qu'il faut voir, je pense, c'est que vous tous, posteurs, vous êtes capables de répondre à ce genre de questions, et ça vous fait marrer (ou rire jaune). Mais il faut croire que beaucoup de prétendants, non.
Je te rejoins là-dessus, jbb2811, notamment parce que je pense qu'un ingé doit avoir un minimum pratiquer, mais au sujet du Set et List, je ne suis pas d'accord.Y a quand même un minimum à connaitre.
C'est un problème d'anglais et de mathématiques. Un "set", un ensemble, c'est mathématiquement une collection d'éléments distincts. Une liste, list, c'est ordonnée et tu peux dupliquer les éléments (comme ta liste de courses, elle est ordonnée de "haut en bas" et tu as mis deux fois "bières")
Répondre avec citation
Partager