Discussion :

[MichaelREMY]

Si à 40 ans t'es pas déjà chef de projet t'as raté ta vie"
Hélas c'est ce que certain pensent

j'ai 38ans, et ce qu'on me dit le plus souvent maintenant c'est qu'à 40ans il faut être entrepreneur.
Pôle emploi m'a dit ça.
Mes ex-employeurs et ex-collègues aussi.
La CCI dit cela aussi à travers ses discours et réunion sur l'entreprenariat.

Pour revenir au sujet, voiçi des retours de mon expérience:

Mon plus beau entretien d'embauche (à 35ans je crois) , c'était avec le DSI (d'une tpe de 5pers à Amiens) avec qui j'ai discuté pendant presque 2 heures pour mon embauche (poste de développeur expert).
C'était le deuxième entretien pour le poste, sachant que le 1er avait duré 15min avec le cabinet RH de recrutement (cabinet de sélection plutôt).
On a parlé beaucoup technique, pas mal sur mon passé et expérience et parcours. On a bcp parlé aussi sur sa technique, son entreprise et ses choix technologiques.
Au final, le poste pouvait m'être accordé, mais je lui ai dit que j'avais ung gros doute pour retravailler dans une petite équipe dans un ptit bureau (après avoir connu une grande structure).
Il a décidé de ne pas m'accorder le poste, et j'en suis très content car je le comprends.
La discussion nous avait permis de voir jusqu'où on concordait l'un vers l'autre.
Si j'avais passé un test écris façon QCM, j'aurai peut-être été embauché mais le poste m'aurait sans-doute déçu.
J'en garde un très bon souvenir car tout a été limpide et transparent. Je me dis aujourd'hui que ce DSI devait vraiment vouloir qq de bien et bon pour "gâcher" autant de temps en entretien. Il avait 10 candidats à interroger.

Mon plus mauvais entretien d'embauche (à 25ans je crois), c'était pour aller travailler à Accenture (paris), un poste d'ingénieur en développement .net.
C'était un entretien groupé : 15 personnes dans la même salle, on nous avait distribué un QCM de 30 pages à faire en 1h je crois.
Tous dans la même salle, autour d'une grande table de réunion, sans surveillance, la "chef" avait indiqué qu'elle reviendrait dans 1h pour relever les copies. Le test était très très dur.
Quand elle est revenue, elle a indiqué que c'était en fait un test-match pour voir ce qu'il se passait dans le groupe, pour voir si une personnalité sortait du lot (par exemple si une personne aidait les autres ou animait la discussion, proposer des aides ou des pistes) ou si au contraire il y avait des mauvais profils (comme des tricheurs qui demandaient les réponses ou qui avait un mauvais comportement en groupe).
Elle nous apprenait ensuite qu'il y avait un CDP d'accenture dans les candidats qui était là pour surveiller (faire la taupe en fait), et il s'était présenté ensuite....
1 Semaine après, j'avais été retenu pour passer un second test et j'avais décliné. A l'époque, je crois que je n'avais pas bcp apprécier la méthode de recrutement.

QCM ou entretien, chacun peuvent avoir la part belle ou au contraire nuire à l'embauche. En tout cas la méthode en dit beaucoup sur l'employeur.
Un bon entretien c'est quand les deux parties savent pourquoi elles ont accepté ou refusé l'autre. Et je pense que le QCM/test technique ne permet pas vraiment cela.

[weberan]

Les entretiens d'embauche permettent-ils de trouver le bon développeur? Tout dépend de ce que l'on cherche. Si l'entreprise qui engage est une société de service qui cherche un candidat qu'elle pourra ensuite revendre en régie à un client qui est incapable de faire la différence entre un bon programmeur et un moins bon, il me semble correct de rester dans le superficiel.

Je ne résiste pas à l'envie de vous relater une anecdote. Dans ma longue carrière j'ai déjà postulé pour des centaines d'emplois et passé des dizaines d'interview. Il y a une seule entreprise où j'ai passé un réel exercice de programmation (les candidats pouvaient venir avec leur PC et étaient soumis à un exercice de programmation inspiré d'un besoin réel, exercice à réaliser en 3 heures). Cet examen portait sur la programmation en C++. J'ai très bien réussi ce test et j'ai été engagé. Ensuite, dans cette boite j'ai programmé en VB, jamais en C++.

Je pense que la façon dont les interviews d'embauche se déroulent n'est pas pire que la suite. Par contre, il y a un vrai problème de considération de la réalité des choses en entreprise et ce particulièrement dans le domaine de l'informatique. Ce qui est particulier dans ce domaine est que chaque projet est généralement unique; personne n'a jamais fait ce travail et personne ne le fera jamais plus. Les différents projets (ou autres situations de travail en IT) ne sont pas comparables. Il en résulte que l'on ne peut pas mesurer précisément l'efficacité de chacun; il faudrait d'ailleurs définir ce qu'est l'efficacité (s'agit-il de produite vite, de produire bien - comment définir cette notion de bien, ...). On peut ajouter à ce constat une profonde déconsidération du travail de base (je pense que cette caractéristique n'est pas propre à l'informatique); les employeurs considèrent généralement que les personnes ayant quelques caractéristiques communes sont interchangeables. L'expertise technique, au delà d'un certain seuil, est très dure à valoriser. Pour progresser dans sa carrière, il est préférable d'aller vers le "management" que vers plus de compétences techniques

Vous qui commencez une carrière en informatique, j'espère que vous êtes conscients des modes de fonctionnement de ce milieu et que vous n'attendrez pas ce qu'il ne peut pas vous donner : cohérence des choix (dont les chois d'embauches), considération proportionnelle à votre "valeur", charge de travail équilibrée dans le temps, respect de votre personne, ...

J'espère que vous excuserez ces propos désabusés issus de mon expérience d'environ vingt années au sein de sociétés de service en informatique. Et tant mieux si votre expérience vous amène à penser autrement.

Cordialement,

André

[ustensile]

Idéalement, un entretien d'embauche devrait être fait par un profil senior qui connait l'aspect technique et qui a travaille dans le milieu dans lequel le candidat va évoluer. Malheureusement, on rencontre plutôt des TDC d'écoles de commerce de moins de 30 ans ou des nases qui sortent de fac de psycho et qui s'imaginent tout savoir. Le recrutement est une science voire un art, confier ça à des gens sans aucune expérience du domaine pour lequel ils recrutent, c'est perdre du temps et prendre des risques.

[danyclassique]

Oui mais le probleme est desfois beaucoup plus injuste que cela,et assurement beaucoup plus complique.
Car ,oui , il presente mieux que l'autre,
il a vraiement l'air d'un sorti d'ecole
mais , il n'est absoluement pas plus communicatif que l'autre voir meme tres robotise ,
alors que l'autre en plus d'etre dix fois plus competent , est tres gentil et abordable.
Les recruteurs comfirme, n'apprennent pas la pshycologie ou alors a tres bas niveau ce qui veut dire qu'ils manquent d'objectivite et impliquent leurs criteres personnels dans leurs decisions ,ce qui implique aussi une perte d'argent considerable au seint de la societe dans laquelle ils travaillent ,apres etre oblige de remettre en place un processus d'embauche ,a la recherche d'un nouveau developeur

[redbullch]

La communication, c'est comme le java ou le C++, cela s'apprend. Je ne comprend pas pourquoi on devrait opposer les compétences techniques et la communication. Je ne sais pas pour la France, mais en Suisse, plusieurs cours axés sur la communication sont compris dans le cursus d'ingénieur.

Dans une entreprise, il y a plusieurs cas ou un développeur qui communique bien est très utile :

• Vous devez rencontrer directement un client
• Vous devez exprimer pourquoi la solution A est meilleure que la solution B
• Vous devez rédiger de la documentation
• ...

Il n'y a pas besoin d'être un excellent communicant, mais je pense que c'est à la porté de tout le monde d'être d'un niveau correct.

[MichaelREMY]

La communication, c'est comme le java ou le C++, cela s'apprend. Je ne comprend pas pourquoi on devrait opposer les compétences techniques et la communication. Je ne sais pas pour la France, mais en Suisse, plusieurs cours axés sur la communication sont compris dans le cursus d'ingénieur....

Et dans le cursus de Miage aussi. !

il ne faut pas les opposer, mais les complémentariser.

Quelle que soit la taille de l'entreprise, je pense qu'il faut 2 phases de recrutement :

- un entretien avec une personne neutre pour vérifier la personnalité du candidat : Qui voudrait d'un très bon développeur qui a une carence en capacité de communication ? S'il ne sait pas dire "j'ai besoin d'aide" et engendre l'échec du projet, ce n'est pas bon pour l'entreprise ni pour lui (surtout s'il se démène trop dans son coin pour résoudre seul un problème). Personne ne voudrait d'une siège bébé dans son véhicule si ce dernier n'a pas de capteur pour indiquer que la ceinture est mise ou pas....et ceux même si le siège est solide et joli. Ou alors ce genre de super développeur non-communicant devra toujours être encadré par un CDP paternaliste pour le surveiller et ça c'est moyen niveau autonomie ou estime personnel pour le développeur.
Il faut une personne neutre car un technicien ou sénior informatique ne pourrait peut-être pas déceler ce genre de carence à cause de l'affinité du métier, de l'empathie alors qu'une personne hors métier technique (donc un expert, diplômé psycho ou professionnel RH..etc) peut déceler cela à la première rencontre.

- un entretien ou un test technique pour vérifier les bases des compétences attendues-recherchées. Forcément si la personne en face de vous est la plus gentille au monde mais qu'elle est incompétente face à l'outil de travail.

[pcdwarf]

Juste pour mettre mon petit grain de sel, Il se trouve que j'ai été quelques fois du coté recruteur.

Pour la faire simple, la DRH avait présélectionné des candidats en se basant sur des qualités d'ordre relationnel, des questionnaires de test et une certaine "apparence" de compétence dans le domaine technique, mais elle ne se sentait pas capable de juger des qualités techniques réelles des candidats et elle a eu le courage de mettre sa fierté de coté pour se faire assister par un tek. (ce qui est, je crois, assez rare ).

Et bien mon avis est que si l'entretien ne permet pas d'évaluer précisément à quel point quelqu'un est vraiment bon, il permet au moins de repérer relativement vite les "bachotteurs". C'est à dire ceux qui ne comprennent pas grand chose au métier mais qui sont capables de briller aux tests en remplissant sans faute un QCM de questions type.
J'ai été assez surpris, je dois dire, de constater que dans ceux qui sont les plus brillants aux tests, il y avait une proportion non négligeable de gens qui savent où et quand utiliser tel ou tel élément sans pour autant comprendre la différence entre eux.

[Chauve souris]

Juste pour mettre mon petit grain de sel, Il se trouve que j'ai été quelques fois du coté recruteur.

Pour la faire simple, la DRH avait présélectionné des candidats en se basant sur des qualités d'ordre relationnel, des questionnaires de test et une certaine "apparence" de compétence dans le domaine technique, mais elle ne se sentait pas capable de juger des qualités techniques réelles des candidats et elle a eu le courage de mettre sa fierté de coté pour se faire assister par un tek. (ce qui est, je crois, assez rare ).

Et bien mon avis est que si l'entretien ne permet pas d'évaluer précisément à quel point quelqu'un est vraiment bon, il permet au moins de repérer relativement vite les "bachotteurs". C'est à dire ceux qui ne comprennent pas grand chose au métier mais qui sont capables de briller aux tests en remplissant sans faute un QCM de questions type.
J'ai été assez surpris, je dois dire, de constater que dans ceux qui sont les plus brillants aux tests, il y avait une proportion non négligeable de gens qui savent où et quand utiliser tel ou tel élément sans pour autant comprendre la différence entre eux.

Ca existe encore les tests ? Il me semble que c'était devenu le repoussoir généralisé. Bon des fois ça donne l'occasion de s'amuser. "J'ai réussi le premier test !" annonçais-je fièrement ayant réussi à trouver la boîte dans le dédale d'une "zone d'activité" aussi confuse que mal documentée (et pourtant je ne suis pas fortiche en Java ). Le "test du dessin d'arbre", par exemple, mais je le connaissais celui-là (faut dire qu'on avait passé une UV, à Paris-8 rien que sur les tests, leur démolition devrais-je dire(1) ). Je m'applique donc en tirant la langue à faire un beau cylindre ornementé d'ovales. "Retournez la feuille et dessinez un autre arbre" dit le testeur. Même application de bibi encore que, pour le dessin, j'en suis resté à Mat Sup (Maternelle Supérieure) et je leur colle un arbre halluciné dans le style Bernard Buffet avec des petits sachets accrochés et des seringues. Tête du testeur "Kékséksa ?", "Bien, un arbre à cames" (au moins un V8), perplexe il retourne la feuille "Et ça ?" "Aussi un arbre à came" (mais sans 's').

Une brave dame se désespérait que son fils, pourtant bien qualifié dans je ne sais plus quoi, et entrant dans la très étroite fenêtre d'âge du salariat (on peut dire entre 23 et 28 ans d'après ce que j'ai pu observer), échouait aux entretiens d'embauches. "Pourtant il réussit les tests !" s'exclamait-elle. "Chère dame", lui dis-je, "soyez certains qu'un gugusse absolument inembauchable comme mézigue sera toujours convoqué pour passer des tests. Car ces sous-traitants du recrutement sont payés au nombre de candidats qu'ils reçoivent pour passer des tests. Avec eux le but n'est pas de trouver un job mais de financer indirectement le leur".

Depuis j'ai compris qu'il fallait aller "loin, loin, ici la boue est faite de nos pleurs"...

(1) Un exemple ricain : deux psychologues se présentent à une institutrice de petite classe "pour faire passer des tests aux enfants". Ils remettent les résultats à l'institutrice en disant "On a pu dégager deux groupes : l'un qui apprendra facilement et l'autre pour lequel ça sera bien plus difficile, voici les noms, vous nous direz en fin d'année scolaire ce que vous en pensez". Nos deux psychologues se pointent donc en fin d'année et l'institutrice les reçoit, ravie "Excellent votre diagnostic ! J'ai bien eu les problèmes annoncés avec le deuxième groupe alors que ça passait tout seul avec le premier". Les psychologues lui ont alors répondu que les enfants des groupes avaient été tirés au hasard, c'était elle, l'institutrice, qui était l'objet du test.

[MichaelREMY]

Et dans le cursus de Miage aussi. !

il ne faut pas les opposer, mais les complémentariser.

Quelle que soit la taille de l'entreprise, je pense qu'il faut 2 phases de recrutement :

- un entretien avec une personne neutre pour vérifier la personnalité du candidat : Qui voudrait d'un très bon développeur qui a une carence en capacité de communication ? S'il ne sait pas dire "j'ai besoin d'aide" et engendre l'échec du projet, ce n'est pas bon pour l'entreprise ni pour lui (surtout s'il se démène trop dans son coin pour résoudre seul un problème). Personne ne voudrait d'une siège bébé dans son véhicule si ce dernier n'a pas de capteur pour indiquer que la ceinture est mise ou pas....et ceux même si le siège est solide et joli. Ou alors ce genre de super développeur non-communicant devra toujours être encadré par un CDP paternaliste pour le surveiller et ça c'est moyen niveau autonomie ou estime personnel pour le développeur.
Il faut une personne neutre car un technicien ou sénior informatique ne pourrait peut-être pas déceler ce genre de carence à cause de l'affinité du métier, de l'empathie alors qu'une personne hors métier technique (donc un expert, diplômé psycho ou professionnel RH..etc) peut déceler cela à la première rencontre.

- un entretien ou un test technique pour vérifier les bases des compétences attendues-recherchées. Forcément si la personne en face de vous est la plus gentille au monde mais qu'elle est incompétente face à l'outil de travail.

je me cite

en fait après réflexion, il y a 3 tests, sachant que le premier c'est la lettre de motivation+CV qui permet au minima de déceler les manques d'orthographe ou d'expression ou manque d'originalité ou les copieurs-colleurs de modèles, donc de détecter la bonne rigueur d'expression en français !

[pcdwarf]

Je ne faisait pas référence à des tests psychotechniques mais à des tests sur le domaine spécifique un peu comme le QCM du code de la route.
Il y a de vrais nullards qui sont de bons perroquets qui brillent à ces tests parce-qu'ils se sont entrainés et savent reconnaitre les questions pièges. Alors qu'il y a de bons développeurs qui, sûr de leur maitrise de tel ou telle techno ont cru que ça pouvait suffire et tombent dans des pièges grossiers. L'erreur la plus classique est de réinterpréter intelligemment une question bête...

[Tr0n33]

Je compatis et comprends.
j'ai également cette difficulté (aisément compétent mais pas assez jeune (je ne dis pas âgé non-plus!).
Il serait intéressant de savoir si les "grandes boîtes" ont des tests en fonction de l’âge ou généraliste.

Je suis en phase de me faire embaucher par une grosse société et je vais avoir 35 ans.
Le commercial pour qui je suis en sous traitance depuis deux ans a été très clair :
1- Ils n'embauchent jamais au dessus de 35 ans sauf cas exceptionnel.
2- Ils veulent une pyramide des âges proches de 30 ans au niveau de leur masse salariale.
Il n'y a pas de "tests" en fonction de l'âge, c'est juste un critère rédhibitoire à l'entrée, sauf cas "à part".

Dans le cas du recrutement d’un développeur par exemple, ce que l’employeur recherche, c’est premièrement des compétences techniques, plutôt que des qualités communicationnelles

De mon point de vue c'est faux. N'importe quel individu qui sort d'IUT, DUT, Université, Ecoles d'ingénieures, est capable d'être développeur. Un employeur d'une entreprise de taille modeste cherchera avant tout un individu capable de s'intégrer dans son équipe, dans son entreprise et qui ne posera aucun souci hiérarchique. C'est la peur numéro 1 de tout patron (totalement exacerbé dans des petites entreprises). L'assise technique de son entreprise ne nécessite réellement qu'une qualité d'adaptabilité à l'embauche et d'une évaluation d'un coût de formation. Grosso modo, peu importe le niveau technique à l'entrée, il faut savoir juger de la marge de progression, de l'investissement et du temps que cela prendra. J'ai embauché une vingtaine de développeurs en 10 ans et à chaque fois, mis à part un ou deux, ce n'était pas des cadors de la programmation; pourtant ils sont désormais pour la plupart des experts en programmation. L'important n'est pas du tout le niveau technique d'entrée (évidemment il faut un socle minimum), mais l'adéquation entre un poste et un individu.

Le problème de cet article c'est qu'il fait l'amalgamme entre tous les types de programmeurs. Un développeur à EADS pour des éléments de physiques des particules n'a pas besoin de la même assise technique qu'un développeur pour Capgemini et de l'informatique de gestion. C'est en fonction du type de poste de développement qu'il faut regarder la façon de recruter. Le scoring, c'est sympa mais ça fout aussi sur le carreau tous les individus qui ont une marge de progression colossale. Si je n'avais fait que du scoring, j'aurais raté des développeurs avec des qualités intrinsèques d'adaptabilité gigantesque. Un processus de recrutement est un tout "indivisible". Il faut comprendre qu'une embauche en tant que développeur, ça ne veut pas dire rester développeur toute sa vie dans une société. Les ressources humaines se projettent aussi sur l'avenir, sur le devenir des individus (beaucoup ne seront pas d'accord, mais c'est leur rôle premier bien que souvent dévoyé).

Je trouve dommage que cet article ne soit pas un peu plus fouillé. Lorsqu'on embauche un musicien dans un orchestre, lui faire jouer de la musique n'est pas suffisant du tout, surtout s'il est incapable d'obéir au troisième concert ou qu'il fout en l'air l'esprit de l'orchestre. Un virtuose c'est bien; je préfère un individu moins bon, mais qui s'intègre parfaitement à mon orchestre et qui est capable de "devenir un virtuose". Mon orchestre n'a pas forcément besoin d'un virtuose pour bien fonctionner au départ; tout dépend de mon public.

Trouver un "bon" développeur, techniquement parlant, n'est pas toujours l'objectif d'une société. Rien ne me prouve que d'utiliser du scoring va me faire constituer une équipe en symbiose. Pas du tout même. La stimulation et l'esprit d'équipe sont des moteurs très importants dans des équipes de développement. Quand vous arrivez à les faire bosser ensemble, même le moins bon techniquement peut devenir talentueux. Et ça, aucun scoring de développement ne peut le deviner. C'est à l'humain de le déterminer. Je trouve particulièrement étonnante cette phrase que j'ai citée, vraiment. Je ne suis donc pas d'accord sur le critère de recrutement, difficile de l'être sur la suite de l'article.

Ensuite, il y a un problème dans la logique. Si tout le monde ne recrutait que des "bons" développeurs, que ferait on de ceux qui ont un scoring moyen ? Ils n'auraient pas droit à un job ? C'est une grossière erreur d'utopiste de croire que le recrutement premier doit se faire par la technique même pour un poste technique. Non justement, il doit se faire par une adéquation entre un poste, un individu, une entreprise, une mission, une équipe. Oubliez l'un des critères et votre recrutement ne sera pas "bon". Sinon, il y aurait un paquet d'individus qui serait encore au chômage si nous n'usions que de la méritocratie technique pour ce genre de poste. Pour moi, un bon développeur n'est pas un monstre technique capable de répondre à toutes les problématiques du code. Il doit surtout être capable de me l'expliquer, de le justifier, de progresser et s'intégrer dans mon équipe.

Le scoring n'est qu'un indicateur et pas le meilleur pour un recrutement. Tous les développeurs techniquement très bons que j'ai croisé, ont toujours mal fini dans leurs structures. Ceux qui sont devenus à mes yeux les meilleurs, sont ceux qui étaient capable de surpasser certaines problématiques humaines de gestion dans une société. Ils se sont bonifiés avec l'âge.

Evidemment, une perle rare, on la prend toujours mais elle peut avoir un coût plus important pour un gain d'efficacité qui n'est pas foncièrement nécessaire. Pourquoi ? Imaginer un des développeurs de l'équipe qui code en 1J homme ce que font ses petits copains en 4J homme. A qui va-t-on demander un meilleur rendement ? Comment réagira l'équipe ? Bref... Des questions qui sont très importantes dans un recrutement même technique. Pourquoi croyez vous que les RH se fichent de la technique ? Ils préfèrent avoir des équipes à niveau proche pour une meilleur stabilité des relations humaines. D'autres vont préférer avoir le top du top (et se rendre rapidement compte au final qu'ils perdent du temps à cause de problématiques humaines). La science du recrutement est quelque chose de très complexe, bien plus complexe qu'un calcul de niveau dans un domaine et d'adéquation communicante. Des éléments que n'évoquent pas cet article. Le recrutement est une science de la sociologie avant d'être un problème de compétences. Le calcul du niveau de compétences est ce qu'il y a de mon point de vue, de plus facile dans un recrutement (peu importe que ce soit par test, scoring etc). Un mauvais RH va virer directement un postulant qui a peur au lieu de creuser - c'est par flemme. Tous mes recrutements ont duré entre 2 h et 3 h; impossible qu'un candidat soit timide tout du long. Au bout d'un moment, il se détend et le vrai entretien peut commencer. J'ai croisé beaucoup de RH qui faisait la même chose mais ce n'est à priori pas la majorité.

Il y aurait tellement à débattre sur le sujet.

[Traroth2]

Si on considère qu'un développeur n'est qu'un pisseur de lignes, automatiser le recrutement peut sûrement donner de bons résultats. Si on est dans une logique d'ingénierie, où chaque membre de l'équipe a une véritable valeur ajoutée, où connaitre Java ou PHP sur le bout des doigts n'est pas suffisant, mais où il faut surtout savoir trouver des solutions intelligentes, savoir communiquer, savoir travailler en équipe, savoir trouver les informations nécessaires, etc.

[mchoucroun]

Pour la compétence technique:
A une époque, j'avais une méthode pas trop mal:
Je faisais passer un QCM au candidat et je recherchais les réponses qui étaient des grosses bétises.

[mayens]

Je suis tout à fait d'accord avec cette nouvelle approche. Les codekata pourraient être un très bon exemple à appliquer en entretien. C'est la même démarche pour les personnes certifiés en une techno et celles non certifiées mais expérimentées.

[MichaelREMY]

dans une autre réalité, j'aurai souhaité que juste présenter les originaux des diplômes, ou des certifications suffirait à faire valoir un savoir-faire lors d'un entretien...
C'est à se demander maintenant à quoi servent les études....

Normalement un entretien ou un QCM devrait servir à trouver le meilleur parmi des candidats tous bons , et non pas à évincer les impostures comme c'est le cas maintenant...
si des impostures arrivent au stade de l'entretien, c'est que le sélectionneur (la RH, le chargé RH, le cabinet..) a mal fait son job!

[foetus]

C'est à se demander maintenant à quoi servent les études....

/mode cynisme ON

Ce n'est pas de notre faute si tu ne peux ni accéder ni te payer ton diplôme d'ingénieur avec un stage à l'étranger

/mode cynisme OFF

[Neckara]

C'est à se demander maintenant à quoi servent les études....

Prend une école, prend le major de promotion et le dernier puis compare leur niveau.

Un diplôme permet en effet de sanctionner un certain niveau, mais ce n'est qu'un niveau "minimum" pour les diplômés. Le diplôme ne permet que de "pré-filtrer", on va demander un BAC+2, un BAC+5, etc.

Cela dépend donc d'où le diplôme place la barre de ce niveau "minimum" requis dans différentes matières.
J'ai connu des personnes qui, en sortant d'IUT, étaient bien plus douée que d'autres sortant d'ingénieur, ce qui ne les a pas empêcher de faire une école d'ingénieur et de s'améliorer encore plus.

Mais qu'on soit dernier avec 10 de moyenne ou premier avec 20 de moyenne, le diplôme acquis est le même, sa valeur est donc conditionnée par le niveau de tous les diplômés.


Ainsi si un employeur veut le haut du panier, ou tout du moins ne veut pas le fond du panier, il ne peut pas uniquement se baser sur le diplôme. D'autant plus s'il demande des compétences dans un domaine précis, chaque école ayant ses propres spécialités.

[GeoffreyOnRails]

dans une autre réalité, j'aurai souhaité que juste présenter les originaux des diplômes, ou des certifications suffirait à faire valoir un savoir-faire lors d'un entretien...
C'est à se demander maintenant à quoi servent les études....

Un QCM ne sera jamais qu'un filtre passe-haut, choisir la bonne réponse dans un QCM ne permet que de sélectionner ceux qui ont un minimum de connaissance du sujet pour distinguer la bonne réponse parmi les mauvaises. Tu ne distingueras jamais les meilleurs des bons avec ça. Sans compter que tu mesures un savoir et pas un savoir-faire.

Quant aux études, elles servent à acquérir des compétences. Le diplôme prouve un minimum atteint, mais n'est pas le saint-graal de l'évalutation de compétences.

Normalement un entretien ou un QCM devrait servir à trouver le meilleur parmi des candidats tous bons , et non pas à évincer les impostures comme c'est le cas maintenant...
si des impostures arrivent au stade de l'entretien, c'est que le sélectionneur (la RH, le chargé RH, le cabinet..) a mal fait son job!

Concernant le diplôme, ça pourrait presque suffire lorsque tu es jeune diplômé. Par contre, j'espère que tu as/auras appris des choses en 5 ans de carrière, et qu'on pourra discuter de ce que tu as appris lors de tes expériences et pas juste de ton option de dernière année ou de la certification que tu as passé en deux jours il y a 3 mois...

Je ne sais pas comment tu veux qu'un RH repère des impostures sur la plan technique sans entretien et sans QCM. Ce sont pas des magiciens. (ça au moins, on devrait être tous plutôt d'accord )

[acx01b]

si t'es un bon développeur et que le RH te parle de trucs sans intérêt, tu le coupes et tu parles de technique, au bout de 10 minutes il s'en va et arrive à la place ton futur chef de bureau qui te parle lui de technique (et qui est souvent à moitié autiste)

et à foetus

/mode cynisme ON
Ce n'est pas de notre faute si tu ne peux ni accéder ni te payer ton diplôme d'ingénieur avec un stage à l'étranger

c'est drôle mais ça montre que tu ne sais pas qu'à la fac (500euros par an en master, 350 en licence) d'informatique ce sont des CHERCHEURS en informatique, donc pour quelqu'un de bon intéressé et si la fac n'est pas blindée de monde (comme Paris 6) c'est l'idéal pour faire ses études d'informatique bien plus que n'importe quelle école d'ingé, et tous les employeurs le reconnaissent : il y a de très bons qui sortent de la fac

personnellement j'étais 1 à mon cours de compilation, ben je peux te dire que j'ai appris plutôt assez bien l'assembleur les parseurs les compilateurs...

[Neckara]

c'est drôle mais ça montre que tu ne sais pas qu'à la fac [...] d'informatique ce sont des CHERCHEURS en informatique, donc pour quelqu'un de bon intéressé et si la fac n'est pas blindée de monde (comme Paris 6) c'est l'idéal pour faire ses études d'informatique bien plus que n'importe quelle école d'ingé

Parce que tu crois qu'il n'y a pas de chercheurs en école d'ingé ?
D'ailleurs il y a même des profs qui enseignent à la fois en école d'ingé et en fac.


En quoi une fac serait-elle "plus idéale" que "n'importe quelle école d'ingé" ?


J'ai connu une personne qui en sortant d'un master en sécurité informatique en connaissant bien moins sur la sécurité que d'autres sortant d'IUT ne connaissant pas spécialement la sécurité informatique.

Pour moi, et pour caricaturer :

• IUT : apprendre à coder, ie pisser des lignes de code, comprendre le langage.
  
  • Très guidé, contrôles continues + partiels ;
  • Petites classes, peu d'amphi
  • Très pratique, beaucoup de TP/TD, quelques projets en binôme ou à 4.
  
  
• Ingénieur : apprendre à développer, ie gérer un projet, faire un code maintenable, avoir une solide culture en informatique.
  
  • Guidé, examens semestriels, parfois des partiels ou quelques notes en cours d'années, mais rare.
  • Petites classes rares pour TD/TP, principalement des amphi.
  • Pratique via TP/TD, mais aussi par plusieurs projets pratique en équipes (jusqu'à 8).
  
  
• Fac : théorie
  
  • Peu guidé, on peut parfois même choisir ses cours.
  • Surtout des amphi
  • Peu de TP/TD en petit groupe.
  
  

Pour la Fac, je ne suis pas allé en Fac d'informatique, et je n'ai pas non-plus suivi de cursus continu, mais un cursus "adapté" pour poursuivre des études d'ingé à côté.

Donc je ne vois pas pourquoi l'un serait "plus idéal" qu'un autre.
Je les vois plus comme étant complémentaire. L'idéal étant de tous les faire, sinon de choisir celui qui convient le mieux à notre façon de travailler.