"Je suis un ingénieur, pas un compilateur"

Citation:

---

Envoyé par egrange

Citation:

---

Envoyé par gangsoleil

Au quotidien, j'utilise des tableaux, des pointeurs, ... Il m'est arrive d'utiliser des listes, des tables de hash, mais ce n'est pas si courrant.

---

Monsieur Jourdain faisait lui aussi de la prose sans le savoir. De nos jours toutes ces structures de données sont très courantes, et utilisées un peu partout, avec plus ou moins d'effets de bord.

Ceux qui font du code jetable où la performance ne joue pas peuvent rester ignorant, mais exploiter les bonnes structures et les bons algorithmes au bon moment, c'est gagner beaucoup de temps, à la conception et au développement, à l'exécution et en maintenance.

C'est la bonne vieille question d'utiliser le bon outil au bon moment, et de savoir quels outils existent et pour quels usages.

---

Pas de chance pour toi, je fais du C, langage dans lequel il n'est pas possible d'utiliser une structure sans le savoir. Il se trouve simplement que moi, dans mon domaine, je n'en ai pas besoin. Ah oui, et les performances sont souvent cruciales dans ce domaine (pseudo temps-reel, ...), donc il ne faut pas trop se tromper.

Ce que je voulais juste montrer, c'est qu'il n'existe pas de bonnes questions generalistes. Un ingenieur specialise en bas niveau ne doit pas avoir les memes connaissances qu'un ingenieur en verification formelle, qui lui meme n'a pas les memes connaissances qu'un ingenieur specialise en bases de donnees.

Citation:

---

Envoyé par el_slapper

Les premières fusées Françaises, avant Ariane, atteignaient leurs objectifs, parcequ'il y avait sur le pas de tir les gens qu'il fallait pour mettre le fil de fer là ou il fallait. Dans le tas, il y avait des techniciens, mais aussi quelques ingénieurs.

Mais effectivement beaucoup sont contaminés par une certaine manière de penser. Je pense à la fameuse question du gateau, qu'on m'a servi en école d'ingé, comme sans doute beaucoup d'autres. "Vous avez un gateau cylindrique. Vous devez le couper en 8 parts, mais vous n'avez droit qu'à 3 coups de couteau". La solution officielle est de couper en longueur, en largeur, et en épaisseur. Et le formateur de conclure fièrement "cet exercice permet de savoir su vous savez penser hors des standards. Tout le monde coupe verticalement. Vous devez aussi penser à couper horizontalement".

C'est évidemment de la connerie pure. Si les gens ne coupent leurs gateaux QUE verticalement, c'est parceque c'est la seule découpe qui marche. Un gateau, c'est un support de pate, puis un empilement de substrats fragiles(crème, fruit, mousse, chocolat.....), qui ne tiennent que grâce à la gravité. Si on découpe horizontalement, on va tout arracher. On aura pas 8 parts, mais une multitude de petit tas informes et hétérogènes.

Si on veut répondre de manière réaliste à cette question imbécile(sauf si la découpe se fait par jet d'eau, auquel cas la limitation du nombre de découpes est justifiée), il faut donc se rajouter la contrainte suivante : il faut découper verticalement(ce qui serait en plus justifié dans le cas d'une découpe à jet d'eau). Ce qui donne 2 solutions : soit on découpe en rond pour avoir des parts intérieures et extérieures(ce qui ne marche pas pour le jet d'eau qui va tout droit), soit on bouge les parts après chaque découpe.

Mais ça, personne ne me l'a appris. Et le prof m'aurait flambé si je lui avait dit. On respecte trop l'abstraction, dans ce pays. elle peut être utile, mais seulement si on arrive à la reconnecter au réel.

---

Dans le même style, à la même époque, un ingénieur qui était proche de la fin de ses études était capable de m'embrouiller la tête en me parlant de maths, de physique, de sortir x solutions éventuelles à un problème, etc...et un coup il me demande dans quel sens on met un cd vierge dans le graveur.....

La première chose que je me suis dit, c'est pas "il est con ou quoi ?" mais plutôt...il a peur d'essayer ? Comme si sa manière de fonctionner ne lui permettait pas de dépasser le stade de la réflexion...comme si il lui manquait cette fameuse "reconnexion au réel"...il y a eut ce cas la et bien d'autres où une fois arrivé au bout de sa réflexion il était arrivé au bout de tout...

Citation:

---

Envoyé par el_slapper

(.../...) "cet exercice permet de savoir su vous savez penser hors des standards. Tout le monde coupe verticalement. Vous devez aussi penser à couper horizontalement".
Mais ça, personne ne me l'a appris. Et le prof m'aurait flambé si je lui avait dit. On respecte trop l'abstraction, dans ce pays. elle peut être utile, mais seulement si on arrive à la reconnecter au réel.(.../...)

---

Je vois que tu mets en pratique ta signature ! C'est bien !
Il est clair que notre monde est conventionnel, par peur bien souvent de l'inconnu (problème que les religions essyent de gommer avec les croyances), ou par peur de devoir assumer par la suite un choix qui sur le moment semble "élégant".
Dans beaucoup de sociétés, on fait preuve de trop de retenue par peur de faire des erreurs. Or c'est en faisant des erreurs (toutes proportions gardées) qu'on progresse. Ne pas faire d'erreurs, c'est bien. En faire qui soient constructives, c'est mieux ! Je fais le parallèle avec la tirade de Gary Oldman dans le 5eme élément : c'est du chaos que nait l'action. Quand tout est bien ordonné et calme, ça ronronne certes, mais il n'en sort rien de nouveau. Or la nouveauté (et donc le risque inhérent) apporte de grandes choses. Cette nouveauté c'est ce qui fait marcher les chercheurs, et courrir les ingénieurs. Car dans "ingénieur", il y a "Génie" dans le sens création du terme.

Citation:

---

Car dans "ingénieur", il y a "Génie" dans le sens création du terme.

---

Étymologiquement, "ingénieur" et "génie" n'ont pas (tout à fait) la même origine, ce qui fait plus de nous des fabricants de machines de guerre que des gens talentueux :mouarf:

Citation:

---

Envoyé par Bktero

Étymologiquement, "ingénieur" et "génie" n'ont pas (tout à fait) la même origine, ce qui fait plus de nous des fabricants de machines de guerre que des gens talentueux :mouarf:

---

Raté (au moins partiellement) jeune paddawan :
"Le génie est l'art de l'ingénieur.".

Même si autrefois les ingénieurs ("ingénieurs du Roy" étaient principalement de deux catégories : les sapeurs (démolisseurs) et les ingénieurs (plutôt pour batir des trucs qui resistent aux sapeurs...)

Mais pour te (re)donner raison, d'après l'Académie Française :
"(1)INGÉNIEUR n. m. XIIe siècle, engigneor, au sens de « constructeur de machines de guerre » ; refait au XVIe siècle d'après s'ingénier. Dérivé d'engin."
Mais on voit bien dans "s'ingénier" la racine de "Génie"...
La nouvelle définition serait donc plus proche de Genie que de engin...

Un partout ?

Citation:

---

Envoyé par arkhamon

...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.

---

J'ai toujours du mal avec cette séparation, dans le monde du développement logiciel, entre ingénieur (qui conçoit) et technicien (qui programme).
Je suis ingénieur développeur et mon activité au quotidien c'est de concevoir et de développer ce que j'ai conçu.
C'est deux activités sont, pour moi, indissociables. Je dois connaître les "rouages du langage" que j'utilise et les "les rouages de la conception" (comme l'abstraction).

Autant dans le btp, je différencie l'activité de l'architecte de celle du maçon mais en génie logiciel cela me semble difficile.

Citation:

---

Envoyé par arkhamon

... 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...

---

C'est pour cela que j'aurais tendance à dire qu'être sensibilisé aux design patterns ou à des notions telles que l'abstraction, c'est nécessaire, non pas pour les utiliser absolument mais surtout pour pouvoir les reconnaître.

En me basant sur Larousse :

Citation:

---

ingénieur = nom masculin (de l'ancien français engigneor, constructeur d'engins de guerre, avec l'influence de s'ingénier)

---

On est seulement influencé par le génie, pas directement des génies :D

Mais je parlais étymologiquement, et uniquement étymologiquement.

Surtout que le génie dont tu parles ressemble plutôt au corps de l'armée : http://www.larousse.fr/dictionnaires...C3%A9nie/36570

Citation:

---

génie = nom masculin (de génie 1, avec l'influence de ingénieur)

---

qu'à celui d'Einstein ("génie 1" dans la citation précédente) : http://www.larousse.fr/dictionnaires...ais/g%C3%A9nie

Citation:

---

génie = nom masculin (latin genius, divinité tutélaire, puis talent)

---

M'enfin, on pinaille et on divague là :lol:
PS : elle ne tourne pas un peu en rond les étymologies du Larousse là ?

Citation:

---

J'ai toujours du mal avec cette séparation, dans le monde du développement logiciel, entre ingénieur (qui conçoit) et technicien (qui programme).
Je suis ingénieur développeur et mon activité au quotidien c'est de concevoir et de développer ce que j'ai conçu.

---

Pour ça que je disais qu'en informatique "pure", la vision est un peu faussée.

Citation:

---

Envoyé par Nathanael Marchand

Une fois qu'une appli est finie, je préfère passer sur autre chose.

---

:ccool:

Je ne peux que plussoyer.

Citation:

---

Envoyé par lod101

J'ai toujours du mal avec cette séparation, dans le monde du développement logiciel, entre ingénieur (qui conçoit) et technicien (qui programme).
Je suis ingénieur développeur et mon activité au quotidien c'est de concevoir et de développer ce que j'ai conçu.
C'est deux activités sont, pour moi, indissociables. Je dois connaître les "rouages du langage" que j'utilise et les "les rouages de la conception" (comme l'abstraction).

---

C'est justement là que le bât blaisse ! Il ne faudrait pas faire les deux. C'est idéologiquement presque "incompatible" !

Citation:

---

Envoyé par lod101

Autant dans le btp, je différencie l'activité de l'architecte de celle du maçon mais en génie logiciel cela me semble difficile..

---

Tu viens pourtant de prendre un excellent exemple qui devrait te permettre de comprendre ! Le problème vient du fait qu'on fait le mélange de plusieurs métiers informatiques :

• Le chef de projet qui pilote l'ensemble des choses pour arriver au résultat voulu en temps voulu et au prix convenu
• les ingénieurs qui conçoivent
• les analystes qui formalisent ce que les ingénierus ont pensé
• les techniciens (ou programmeurs) qui REALISENT ce qui a été conçu

Plus on descend dans la lsite, plus on a besoin d'être pointu dans le domaine final. Et j'aurais même tendance à dire qu'un ingénieur trop pointu dans le domaine risque de biaiser son raisonnement en ayant un paradygme trop restreint des différentes solutions possibles.
Je laisse volontairement de côté (snas notion péjorative) toute la partie support et exploitation, on parle ici d'ingénieurs (oui je sais ça va en faire bondir plus d'un...).
[/QUOTE]

Citation:

---

Envoyé par Bktero

En me basant sur Larousse :

On est seulement influencé par le génie, pas directement des génies :D

---

Bien dommage... :P En même temps, l'ingénieru doit faire preuve de génie... :mouarf:

Citation:

---

Envoyé par Bktero

Mais je parlais étymologiquement, et uniquement étymologiquement.

Surtout que le génie dont tu parles ressemble plutôt au corps de l'armée : http://www.larousse.fr/dictionnaires...C3%A9nie/36570

qu'à celui d'Einstein ("génie 1" dans la citation précédente) : http://www.larousse.fr/dictionnaires...ais/g%C3%A9nie

M'enfin, on pinaille et on divague là :lol:
PS : elle ne tourne pas un peu en rond les étymologies du Larousse là ?

---

C'est pour ca que je proposais sportivement un match nul... :?

On peut pas gagner à tous les coups. Et j'ai sorti le mot de mémoire (j'ai du étudier ça en seconde, ca fait maintenant 30 ans) et je me suis dit que c'était forcément compliqué à écrier. Et puis des "H" muets et un "Y" ça pête non ? :aie: Bon d'accord...

Citation:

---

Envoyé par psychadelic

Apres l’entretien on me dit que je n’avais pas répondu à sa question…
Ce type ne savait même pas ce qu’est un sémaphore en informatique !

Depuis cette histoire, je me suis rendu compte que lors des entretiens d'embauche, que certains n'ont qu'une connaissance très partielle des questions qu'ils posent... :whistle:

---

Comme quoi ...
Mais même pour les notions cités comme "basiques" sur ce thread y'en a des vertes et des pas mures !
Lors de mon premier entretien, le gars que j'avais en face (qui se disait chef de projet et pas commercial ni RH) me soutenait que le polymorphisme, ça n'existait qu'en JAVA .... :/

Citation:

---

Envoyé par egrange

C'est aussi des notions de base pour pouvoir comprendre les technologies, des notions de maths, de physique, de mécanique, d'électronique, etc.

---

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.

Citation:

---

Envoyé par arkhamon

C'est justement là que le bât blaisse ! Il ne faudrait pas faire les deux. C'est idéologiquement presque "incompatible" !

---

T'y vas fort! J'veux bien des précisions...

Citation:

---

Envoyé par arkhamon

...Le problème vient du fait qu'on fait le mélange de plusieurs métiers informatiques :

• Le chef de projet qui pilote l'ensemble des choses pour arriver au résultat voulu en temps voulu et au prix convenu
• les ingénieurs qui conçoivent
• les analystes qui formalisent ce que les ingénierus ont pensé
• les techniciens (ou programmeurs) qui REALISENT ce qui a été conçu

Plus on descend dans la lsite, plus on a besoin d'être pointu dans le domaine final. Et j'aurais même tendance à dire qu'un ingénieur trop pointu dans le domaine risque de biaiser son raisonnement en ayant un paradygme trop restreint des différentes solutions possibles.
Je laisse volontairement de côté (snas notion péjorative) toute la partie support et exploitation, on parle ici d'ingénieurs (oui je sais ça va en faire bondir plus d'un...).

---

Je suis d'accord avec toi sur le rôle du chef de projet, mais pour le reste...
A part instaurer une hiérarchie entre les gens, maintenir le développeur (ou programmeur) dans une condition méprisable, déconnecter les concepteurs de la réalité (comme certains le regrettent ici) et frustrer tout le monde...
Que cela soit lors de ma formation ou en entreprise je n'ai jamais constater une répartition des rôles aussi marquée. Cela me semble un peu dépassé

Qu'un concepteur ne pratique pas ou qu'un développeur ne théorise pas pose un problème à mon sens.

Citation:

---

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

---

Citation:

---

toute question qui prend 5 secondes pour trouver une réponse sur Google n’est pas une bonne question

---

Pffff... 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.

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 :

Citation:

---

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.

---

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.

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... :oops:) 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...

Citation:

---

Envoyé par arkhamon

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,

---

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).

Citation:

---

où Windows était singulièrement plus simple, ou il existait moins de 6 langages de développement "massivement" utilisés...

---

Massivement utilisés, il y en a guère plus.
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".

Citation:

---

L'informatique ayant une évolution vertigineuse, je pense sincèrement qu'il devient impossible d'être multi-spécialiste, à part quelques génies.

---

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.

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 .:aie:

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.

Citation:

---

Envoyé par jbb2811

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.

---

8O