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

« Je suis un ingénieur, pas un compilateur »
les questions d’entretiens sont-elles trop orientées vers la maitrise des instructions et concepts des langages


De nos jours, les offres d’emplois sont de plus en plus orientées vers des langages bien définis. Conséquence : les questions d’entretiens abordent beaucoup plus les aspects liés aux concepts du langage.

C’est en tout cas le constat d’un développeur au pseudo de clements, dans un billet de blog intitulé « je suis un ingénieur, pas un compilateur ».

Celui-ci s’est rendu compte lors de plusieurs entretiens que des questions standards comme : qu’est-ce que le polymorphisme ? Quelle est la différence entre « List » et « Set » ? Quand utilisez-vous l’un ou l’autre ? Quelle est la différence entre le typage fort et le typage faible ? etc. revenaient de temps en temps.

Pour un entretien, « toute question qui prend 5 secondes pour trouver une réponse sur Google n’est pas une bonne question » estime clements.

« Pourtant, beaucoup d’interviews et beaucoup d’examens testent essentiellement comment vous pouvez vous substituer à un compilateur », regrette celui-ci. « Même les examens de certification Java ont tendance à se concentrer sur les questions de syntaxe et de compilation plutôt que la façon dont l’on peut réellement programmer ou concevoir un système ».

Selon clements , « un bon ingénieur pense de façon abstraite en termes de conception et de construction de systèmes, il pense en termes d’algorithmes, composants et conception technique. Il ne sait pas nécessairement tous les détails de la syntaxe d’un langage donné, surtout s’il est utilisé avec un bon IDE qui le fait pour lui ».

Le bon ingénieur doit plus être capable de justifier l’utilisation d’un concept que de le définir. « 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.

« Je suis un bon ingénieur, je ne suis pas un bon compilateur » conclut celui-ci, qui nous révèle par ailleurs sa question préférée pour une entrevue : « quel est votre langage préféré et quelles sont ses faiblesses ? »


Source : Numbergrinder.com

Voir aussi :
:fleche: Les emplois développeurs


Et vous ?

:fleche: Qu'en pensez-vous ?

:fleche: Les questions d’entretiens sont-elles trop orientées vers la maitrise des instructions des langages ?

:fleche: Quelles sont vos questions favorites pour les entretiens ?

Il y a aussi les questions stupide.
Du style(C++): Quel est le resultat de : int i = ++++a++a
A partir des question de l entretien vous pouvez vous faire une idee du job.
Une entreprise qui recrute comme cela montre qu elle ne sait pas recruter.
Cela implique:
1-Qu elle a recrute plein de "mauvais", potentiellement dans votre futur equipe
2-Qu elle ne va pas valoriser l'IT, vu qu elle ne se donne pas les moyens de savoir recruter (ce n est pas une priorite pour eux)
3- Si quelqu un de leur equipe ecrit du code comme int i = ++++a++a, avez vous vraiment envie de bosser avec lui ?

Conclusion:
A la suite d'un entretien du style "Es tu un compilateur", vous savez deja que si vous accepter le job ( il faut bien manger) vous n'allez surement pas rester longtemps.

Citation:

---

Qu'en pensez-vous ?

---

c'est vrai que les questions posées durant un entretien peuvent être complètement décalées par rapport à la réalité du poste à pourvoir, mais il ne faut quand même pas oublier que des questions de base comme le polymorphisme ou l'héritage sont vraiment essentiels à poser, notamment pour évaluer une personne fraichement diplômée.

Donc pour répondre à la question je dirais que les questions à poser doivent correspondre à la personne qui est en face, demander à un expert Java ce qu'est l'héritage revient à demander à un fermier ce qu'est un tracteur :)

L'entretiens ne dois pas se résumer qu'à ce genre de question. Non ?

Ce n'est pas tant le résultat qui intéresse le recruteur, mais ce que va dire le candidat, son raisonnement, son élocution, sa manière d'expliquer. Une question débile de temps en temps pour voir si on a affaire à un guignol ou à une personne qui maitrise son sujet.

Je suis d'accord sur le fond mais les exemple pris me semble peu pertinent, le typage faible/fort ou le polymorphisme sont quand même des concepts généralistes et sont à connaitre.

Demander dans quel contexte on l'utilise c'est mieux que de demander sa définition ça c'est sur, mais personnellement quand on me demande une définition je l'agrémente d'un exemple ou l'utilisation de X est pertinent.

Par contre quand on demande "En java, on écrit private void maFonction ou void private maFonction ?" la il faut pas répondre et courir, à pars si on a faim.

Citation:

---

:fleche: Qu'en pensez-vous ?

---

Petite remarque, ce ne sont pas les questions du type polymorphisme/List vs Set/typage qu'il remet en question, ces questions-ci sont plus ou moins standard, et a raison, pour permettre un premier filtre rapide (comprendre, un dev avec 5 ans d'XP qui vient pour un poste d'architecte et qui réponds "euhhhhh, chai pas", ca peut vraiment poser pb).

Les nano-questions de type "quel est le troisième paramètre de la méthode quuux de la classe Blox du namespace Zorg, sont par contre complètement contre-productives

Citation:

---

:fleche: Les questions d’entretiens sont-elles trop orientées vers la maitrise des instructions des langages ?

---

A titre perso, quand je fais passer un entretien, je préfère donner un petit test de code que lui poser des questions nécessitant de connaitre par coeur une API donnée (sauf cas super spécifique).

Citation:

---

:fleche: Quelles sont vos questions favorites pour les entretiens ?

---

Celle la, elle est facile ;):
http://blog.developpez.com/philippe/...entretien-net/

Les questions techniques précise sur les langages et API peuvent permettre de distinguer les développeurs expérimenté qui ont du bagage. Je penses qu'elles doivent être systématique pour s'assurer des compétences affiché sur le CV.

Beaucoup de chose peuvent se trouver sur google en 5 minutes (même moins), mais ce n'est pas pour autant que tout le monde aura la motivation d'aller chercher pour faire les choses proprement.

Citation:

---

le polymorphisme ou l'héritage sont vraiment essentiels à poser

---

Citation:

---

Je suis d'accord sur le fond mais les exemple pris me semble peu pertinent

---

En fait, c'est le billet qui est mal écrit. Dans l'article original, l'auteur mentionne ces différents points en disant que ce sont des questions normales, dignes d'être posées. En revanche, ce dont il se plaint, c'est les questions suivantes :

Citation:

---

What came next, however, were nano-questions:

• What package is List in?
• What package is File in?
• What keyword do you use to inherit with?

---

(Il en cite quelques autres par la suite.)

PS:
3ème paragraphe, "s'est" au lieu de "c'est"

Les recruteurs ont besoins d'experts dans une technologie, des personnes qu'ils n'ont pas besoin de former en perdant de l'argent.
En école d'ingénieur (et autres écoles publics) ont donne la base, la logique pour régler un problème, mais un vrai ingénieur, le type qui s'intéresse vraiment il va se spécialiser dans une techno en dehors des cours.
Arriver en entretien et dire moi je suis certifié Java, je fais du framework .Net ou du zend framework c'est un véritable plus et ces questions la seront qu'une formalité, elles sont le seul moyen pour un recruteur de faire la différence entre les candidats.
Ces également le moyen de pouvoir combler le manque d'expérience.

Citation:

---

Envoyé par Linkyu

En fait, c'est le billet qui est mal écrit. Dans l'article original, l'auteur mentionne ces différents points en disant que ce sont des questions normales, dignes d'être posées. En revanche, ce dont il se plaint, c'est les questions suivantes :


(Il en cite quelques autres par la suite.)

PS:
3ème paragraphe, "s'est" au lieu de "c'est"

---

Les deux premières ne sont pas très pertinente en effet, surtout que tout développeur utilisant un IDE ne ferra pas ses imports à la main (bien qu'à force on connaisse la réponse). La 3eme l'est quand même un peu plus, si un soit-disant programmeur java ne sait pas avec quel mot clef on utilise l'héritage, je doute qu'il y ai beaucoup pratiqué...

Mais oui il y a mieux pour tester le niveau d'un candidat.

@pavel, c'est sur que le mec qui écrit "int i = ++++a++a," on a pas envi de bosser avec lui. Mais le mec qui ne sais pas répondre à la question, on a encore moins envie !!!

Il y a des morceaux de codes complètement bidons dans un contexte applicatif mais qui ont l'avantage dans un texte d’entretien de tester plusieurs aspect sur une seule ligne de code (ou question). Et permet de voir si le candidat ne fait que survoler les sujet ou s'il maîtrise sont sujet.

je me rappelle d'un QCM de présélection à un entretien ou il y avait une question "sur un routeur vous mettez un câble droit ou un câble croisé"...j'ai répondu "le câble livré avec". Je trouve que c'est typiquement une mauvaise question car elle ne demande aucune réflexion, elle ne permet même pas de savoir si le candidat connait la différence entre les deux :)

Lorsque j'ai du faire passer des entretiens, j'ai toujours posé des questions techniques sur la façon dont le candidat s'y prendrait pour gérer tel ou tel problème (j'ai posé des questions sur l'internationalisation par exemple), pour vérifier s'il avance des trucs pertinents.

Même un gars qui ne l'a jamais fait dans son précédent travail peut sortir une réponse intéressante. Ca se termine sur une discussion et un échange d'idées. De mon côté, je peux réagir et essayer de prendre le mec en faute pour voir comment le mec réagit à la contradiction, s'il adapte sa proposition etc...

Il y a pas de mauvaises réponses et je pénalise pas sur des erreurs, mais ça permet d'écarter les champions qui (sur papier) savent tout mieux que tout le monde et de voir comment le type en face accepte la critique, s'il réagit en se braquant ou s'il argumente intelligemment vers le compromis.

Bref, je ne demande pas de savoir par coeur le code pour lire un fichier en java. En revanche un peu de conception sur un sujet assez large permet déjà de bien se faire une idée.

Citation:

---

Envoyé par _skip

Lorsque j'ai du faire passer des entretiens, j'ai toujours posé des questions techniques sur la façon dont le candidat s'y prendrait pour gérer tel ou tel problème (j'ai posé des questions sur l'internationalisation par exemple), pour vérifier s'il avance des trucs pertinents.

---

J'ai déjà eu une question du genre en entretien : "comment feriez-vous pour un projet multi-lingue ?". J'ai répondu "avec internationalization". Il a haussé les sourcils et m'a demandé "et i dix huit ène (i18n) ça vous dit quelque chose ?". :mrgreen:
Je suis bien content d'avoir trouvé mieux la semaine suivante.

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.
-Ensuite, on me demande de prendre des consultants qui soit assez rapidement opérationnel. Ok, on est pas un pourvoyeur de viande, on prend sur profil et on forme si besoin mais quand même, y a un minimum (sauf cas particuliers) :) Lorsqu'on positionne quelqu'un sur un appel d'offre de toute facon il aura les questions la par le client et en plus celui ci souhaite quelqu'un d'immédiatement opérationnel techniquement.

Citation:

---

Envoyé par pavel

Il y a aussi les questions stupide.
Du style(C++): Quel est le resultat de : int i = ++++a++a
A partir des question de l entretien vous pouvez vous faire une idee du job.
Une entreprise qui recrute comme cela montre qu elle ne sait pas recruter.
Cela implique:
1-Qu elle a recrute plein de "mauvais", potentiellement dans votre futur equipe
2-Qu elle ne va pas valoriser l'IT, vu qu elle ne se donne pas les moyens de savoir recruter (ce n est pas une priorite pour eux)
3- Si quelqu un de leur equipe ecrit du code comme int i = ++++a++a, avez vous vraiment envie de bosser avec lui ?

Conclusion:
A la suite d'un entretien du style "Es tu un compilateur", vous savez deja que si vous accepter le job ( il faut bien manger) vous n'allez surement pas rester longtemps.

---

Dans l'idée je suis tout à fait d'accord avec toi pavel, par contre j'aurais peur de te décevoir en te disant que c'est comme ça que ça se passe partout maintenant.
En effet j'ai passé de nombreux entretiens avant d'être embauché assez récemment dans une boite informatique (très bonne boite :P ), les tests sont toujours les mêmes, visiblement les SSII n'hésitent pas à choper des quizz et de rajouter des questions plus perverses sur le comportement d'une technologie.
De toute façon les SSII sont complètement à la ramasse, on m'a déjà posé des questions sur la visibilité, le polymorphisme et autres notions lié à l'objet, et lorsque je leur répond ils ont l'impression que je me fou d'eux (je suis peut-être trop technique ?), "Euh vous savez Monsieur je ne suis pas développeur".
J'ai envie de leur demander pourquoi ils me posent la question alors :roll:

Le seul moyen de passer un entretien correct c'est de discuter avec un lead developper et non pas un RH, là vous serez sur de ne pas avoir en face de vous un perroquet à qui on a apprit les grandes lignes "Vous connaissez HTéML5, CéSS3, Droupal7, eZpubliche, Zénde, KakPHP, Xémèle ?", puis qui vous refile un QCM si votre tête lui convient.

Bref malgré que je sois passionné par l'informatique et que je me considère comme bon développeur, j'ai comme tout homme faim, il faut bien que je gagne des sous pour manger, et je n'hésite pas à bachoter sur ce genre d'aberration pour devenir un compilateur.

J'ai fait passer plusieurs entretiens sur du java ou du .net pour ma boite, avec des qcm maison (assez durs d'ailleurs) en dix questions.

Mais ce qui m'intéressait le plus, c'était les réponses sur le XML et l'uml (à quoi sert le XML :mrgreen:, qu'est ce que uml :mouarf:). Parce que pour moi, la culture informatique est bien plus importante que la technique.

Personnellement, quand je ne sais pas faire quelque chose, je regarde sur internet, sur des sites tel que codeproject, ou dans le forum de développez :ccool:. On trouve toujours une idée, un début de solution ou simplement une confirmation que c'est trop compliqué ou pas possible.

Alors que les concepts fondamentales des langages objets (encapsulation, héritage, polymorphisme, ...), la modélisation d'une base de données, les différents types d'architecture logiciels, etc... sont, pour moi, des points essentiels que doit maitriser un développeur.

j'ai aussi passé des entretiens techniques avec des développeurs et des chefs de projets. Et franchement, les questions étaient du genre :
expliquez-nous votre dernière mission ou donnez-nous des exemples de missions sur tel technologie,
plutôt que : que fait la ligne &(toto*)tata ou dans quelle package se trouve la classe fichier (:cry:).

10 questions seulement ? 8O (la chance :calim2:)... j'en ai passé 80 sur PHP et 10 seulement sur MySQL (pour ne pas dire SQL...).
Les questions XML (1 seule en faite) c'était pour savoir la différence qu'il y avait entre les 2 API existants et il fallait dire que l'un était chargé à partir d'un flux et l'autre à partir d'une chaine.
Je n'ai pas beaucoup croisé de questionnaire sur l'UML durant mes entretiens, c'était sur quel type de diagramme UML ? Un classique sur les classes ? :)

Je pilote des SSII, je développe aussi, mais pour repondre a

Citation:

---

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.
-Ensuite, on me demande de prendre des consultants qui soit assez rapidement opérationnel. Ok, on est pas un pourvoyeur de viande, on prend sur profil et on forme si besoin mais quand même, y a un minimum (sauf cas particuliers) :) Lorsqu'on positionne quelqu'un sur un appel d'offre de toute facon il aura les questions la par le client et en plus celui ci souhaite quelqu'un d'immédiatement opérationnel techniquement.

---

Je crois qu'en tant que client, effectivement on paye une compétence, j'ai jamais vu un plombier ou un chirurgien apprendre en live, quoique,:mrgreen:. Il existe une forme intéressante qui se nomme le tutorat, et j'apprécie moyen ce mensonge organisé en info (client et prestataire). De toute façon, avec l'expérience du dépouillement de dossiers, on sens les profils montés de toutes pièces. Il y a des choses qui ne trompent pas, l'expérience, le type de projet, l'école ;), il suffit d'être un peu dans le domaine pour soulever le lièvre.
Parfois on est a côté de la plaque, on nous demande simplement de recruter des personnes compétentes pour un budget donné. Nous ne sommes pas non plus des oeuvres caritatives de formation, cependant j'accepte un profil débutant quand il peut être soutenu pas un profil expert. C'est une question de risque mesuré.
J'ai déjà vu une société débarqué avec le livre "Initiation à ...." et franchement, parfois cela fait froid dans le dos.
Je ne demande pas à un ingénieur de connaître par coeur l'API de java.io. Cela me semble ridicule, par contre de l'UML, du design pattern, une conception générique et un code propre avec le respect des bonnes pratiques. Genre faire du PHP4 avec un framework symfony, j'ai déjà vu un gars remplacer le MVC de symfony, pour faire du bon PHP4 non objet et affirmé connaître le langage objet. Franchement ... :cry:
Les tords sont partagés, on sélectionne le moins disant en espérant avoir que des experts (vécu en interne !).
Un ingénieur est un concepteur, s'il ne sait pas il va chercher et apprendre, on paye son autonomie et sa capacité à s'adapter. Sinon on cherche un développeur expert voir un bon technicien.
Par expérience, je trouve les RH mauvais, comment sélectionner un bon vin sans aucune compétence d'oenologie. Le problème est entier, mais j'ai toujours trouvé le recrutement français des SSII mauvais, et sans imagination. Je suis sans concession avec les pratiques d'un autre âge.
On cherche simplement à faire de l'argent, le côté humain est semble t'il secondaire, c'est aussi de notre responsabilité d'essayer de changer les choses.

Olivier

Citation:

---

Envoyé par Gugelhupf

10 questions seulement ? 8O (la chance :calim2:)... j'en ai passé 80 sur PHP et 10 seulement sur MySQL (pour ne pas dire SQL...).

---

Ils ont du temps à perdre.

Citation:

---

Envoyé par Gugelhupf

Les questions XML (1 seule en faite) c'était pour savoir la différence qu'il y avait entre les 2 API existants et il fallait dire que l'un était chargé à partir d'un flux et l'autre à partir d'une chaine.

---

Super. Et la différence entre sax et dom, ce n’est pas plus important ?

Citation:

---

Envoyé par Gugelhupf

Je n'ai pas beaucoup croisé de questionnaire sur l'UML durant mes entretiens, c'était sur quel type de diagramme UML ? Un classique sur les classes ? :)

---

Je ne me rappel plus la question, mais la réponse était du style : Uml n'est qu'un symbolisme.

En fait, ce qui est important c'est la méthodologie que l'on met avec (RUP, ..).