Il me semble que le polymorphisme d'inclusion c'est ce qui te permet de faire appel à tes méthodes d'une classe de base dans une classe dérivée grâce à l'héritage.
Si je me trompe n'hésitez pas à me rectifier.
voyons voir...
sur mon cv, est-ce qu'il y a écrit " notions en latin" ou je "maîtrise le latin" ?
parce que dans le deuxième cas, je ne peux légitimement pas faire d'objection à ce que mon recruteur aie envie de vérifier le degré de prétendue maîtrise .
si je m'offusque des questions pointues, sur quoi l'entretien doit il se baser ?
mon allocution ? ( trèeees important mais pas le coeur du métier )
ma bonne bouille ? ( important , mais ce n'est pas un entretien pour manequinat )
une autre caractéristique physique? ( très important , mais ce n'est pas un casting pour films X)
donc oui aux questions pointues , posées par quelque'un ayant plus d'expérience que moi et amème de comprendre les réponses SVP.
par ailleurs, même en français , il y a quelues tournures syntaxiques et quelques éléments de glose que j'ignore ( entendez que j'ignore ignorer ) , donc en latin, je suis un peu excusable , et ça n'est qu'une évalutation de mon degré de maîtrise, pas de ma capacité à apprendre ( très très très important )
na !
Bktero : l'opérateur ++ préfixe renvoie une référence en C++. Donc ++++a est valide (a est incrémenté deux fois), tandis que a++++ ne l'est pas. En C, les deux sont invalides car le C n'a pas la notion de référence. En C++, c'est important que ça renvoie une référence pour éviter une copie coûteuse (quand on manipule des types plus gros qu'un int). Comme quoi, même une question idiote peut mener à des discussions intéressantes.
Oui, mais il faut vérifier que la personne sait programmer. Dans ma boîte, je fais du Java actuellement, alors que je n'en avais jamais fait avant : j'ai tout simplement passé l'entretien en C++. Trouver l'algorithme est super important, mais il faut vérifier que la personne sait passer de la théorie à la pratique (peu importe s'il y a quelques erreurs de syntaxe, si on parle de Vector au lieu de Array ou ArrayList, etc.).Les compétences et les lacunes éventuelles au sujet des outils de programmation n'ont que très peu d'importance: quand on a pratiqué 23 langages, l'apprentissage du 24^ème n'est l'affaire que de quelques jours.
Bonjour à tous. Sujet très intéressant que le recrutement d'un développeur, et par exentsion d'un spécialiste.
D'abord, tordre le cou à une idée reçue : quand on connait 23 langages, on apprend le 24eme en 2 jours.
Vrai et faux.
Faux car les langages sont regroupés en grands familles ou catégories : 1ere, 2eme 3eme 4eme 5eme génération (on en a déjà parlé). Donc si on connait 23 langages de 1ere génération, y a peu de chance que Prolog (5eme generation) soit ingurgité en 2 jours. En même temps, je connais pas grand monde qui connaisse 23 langages machine... En même temps, Prolog est pas vraiment simple à apprendre...
Vrai car quand on connait 23 langages, y a des chances qu'on ait abordé chacune des familles de langages, et du coup effectivement passer du Pascal à PHP ou C se fait rapidement.
Mais dans la majeure partie des cas, apprendre un langage prend quand même plus que 2 jours. Et pour plusierus raisons :
Ce qui m'amène à une autre remarque : connaître un langage, c'est quoi ? En connaître les bases et principes, ou en avoir une maîtrise suffisante pour en faire quelque chose de bien ?
- le pascal que j'ai appris il y a 35 ans n'a plus rien à voir avec celui mis en place dans Delphi XE2
- on peut apprendre un langae, sans pour autant être capable d'en faire quelque chose de propre
Et tout ceci nous amène... à l'entretien d'embauche !!!
Il vaut mieux quoi :
- un grand khador qui sera un grand spécialiste, mais qui sera un "inadapté social" ?
- un mec qui présente bien et qui a un bon contact et une bonne capacité d'intégration, au risque qu'il ne soit pas un pointu furieux ?
Le premier pondra probablement un code parfait, mais que personne ne sera capable de reprendre derrière, et qui sera probablement une sorte de gourou intouchable et non-intégrable...
Le second sera peut être moins efficace, mais pourra progresser et s'intégrera...
Une entreprise est un microcosme fragile, et un service l'est encore plus. Vérifier par des questions pointues qu'un mec qui a marqué "maîtrise de Java" est pas en train de pipauter, c'est bien. Mais poser des questions super techniques juste pour filtrer et repérer le mouton à 18 pattes, ça me semble pas forcément utile et pertinent. Chacun doit avoir sa chance, les bons et les moins bons. A force de ne vouloir prendre que des êtres parfaits et performants dès le départ, on se coupe de toute une frange de personnes désireuses d'apprendre. Et ça c'est grave, car ce sont les débutants d'aujourd'hui qui deviendront les spécialistes de demain et qui formeront les futurs spécialistes... Sous réserves de pouvoir s'épanouir...
N'en déplaise aux syndicalistes (dont je fais partie) de base et retrogrades (ceux là je n'en fais pas partie), la définition d'une entreprise est :
"la mise en commun de moyens de production (dans tous les sens du terme, le Capital en faisant partie) dans le but de dégager des bénéfices...".
Il s'agit donc ici de faire des bénéfices, donc d'être rentable et efficace. Dans cette optique, n'embaucher que des princes du clavier semble être une bonne approche. Pourtant, ce même prince sera-t-il capable d'une grande rentabilité pour l'entreprise ? Pas si sur, si le prince ne sait pas travailler avec les autres, partager le fruit de son travail (but pédagogique...) et devient une sorte d'ilot numérique isolé... L'entreprise n'a pas vocation à faire du social (je vais encore me faire frapper par les syndicalistes), mais pour autant elle ne survivra pas si elle n'en fait pas. C'est tout le dilemne de notre temps : considérer les salariés non pas comme des Unité à Temps Plein mais comme des personnes humaines, ayant leurs forces et leurs faiblesses.
Seul Dieu est parfait, et encore...
De mes expériences, je pense que le problème vient du manque de connaissances des recruteurs en informatique.
En école d'ingé, on m'a appris le Java pour me présenter la conception objet avec tous les principes.
Dans mon parcours pro, je n'ai jamais fait de java... et pourtant j'ai fait beaucoup d'objets C#, C++, et j'ai souvent souri au entretien quand tu as le ou la RH qui te sort que tu n'as jamais fait de ce langage ou celui-là.
Comme quand on voit des annonces avec expert en php, C++, C, java, netbeans, C#, base de données... le tout mélanger avec une grande maîtrise de n'importe quoi.
En résumé, ça serait bon que les rh se forment un peu plus à ce qu'est la science de l'informatique.
Il n'y a pas grand chose que je puisse ajouter. Je suis tout à fait d'accord sur le fait que la plus part du temps on prend le développeur pour un compilateur.
Avec de bons EDI, il y a beaucoup de gens qui n'ont plus envie de retenir des particularités d'un langage ou d'un API par cœur, ce qui est aussi une perte de temps puisque chaque API évolue continuellement.
D'un autre coté, l'entretien d'embauche est un moyen de vérifier qu'une personne est vraiment compétent et expérimentée. Simplement, qu'il utilise un langage quotidiennement depuis plusieurs années. Cette personne devrait pouvoir répondre facilement a des choses qu'il voit tous les jours.
L'idéale, ce serait comme les situations décrites par beaucoup de gens ici, qu'un recruteur soit quelqu'un qui connait le métier.
Oui et non. Qui est le recruteur en fait ? L'opérationnel ou le RH ? Les deux mon adjudant. Normalement, le RH est là pour cerner la "psychologie" du candidat, quand l'opérationnel est là pour évaluer ses compétences et sa capacité à être efficace pour l'entreprise.
Le problème, c'est en fait de vouloir mélanger les deux... On peut pas être bon partout...
Ce qui à mon avis est une erreur :on ne présente pas un concept grâce à une de ses implémentations. Il y a des fois ou la théorie est indispensable. Présenter la POO avec Java, c'est n'en présenter qu'une facette. Encore une fois, la théorie est importante. Sans bases solides, point de salut...
Ah le fameux super omni-spécialiste généraliste à double échappement latéral gauche semi-thermo capable...
Pas d'accord. Qu'ils restent dans leur domaine, au lieu d'empiéter sur celui des autres. La profession souffre déjà sufisamment "d'amateurs éclairés" sans en ajouter d'autres...
J'avoue que je ne savais pas que a++ ou ++a renvoie une R-value et non une L-value, en C. En même temps, c'est logique. Donc OK que ça ne marche pas en C.
En C++, a++ ne renvoie pas une référence comme ++a ?
Au final, ce qui me posait problème est plus le a++a : comment cela peut-il donner quelque chose de valide / compilable ?
C'est à ce genre de détails qu'on reconnait les gens qui aiment la technique
Je vais préciser ma pensée. Je souhaite juste que le RH est un peu plus de "connaissances" en informatique. Pas qu'il remplace l'opérationnel, mais qu'il puisse faire une différence ou les liens entre les différents langages pour fournir à l'opérationnel des CVs plus intéressants ou plus proche de sa recherche.
Bon, après c'est aussi des problèmes politico-inter-service à l'entreprise... des problèmes de com et de pouvoir.
Et si on prenait le problème dans l'autre sens ? Pourquoi un RH fait-il le premier filtre ? Un CV est déposé (quelle que soit la candidature) pour un type de poste. Donc le premier filtre DEVRAIT être l'opérationnel, car il est le seul à même de savoir si le profil technique peut correspondre au besoin. Ensuite, le RH passe pour voir l'adéquation du candidat à l'entreprise et à ses valeurs. A demander aux RH de faire le premier filtre, on se coupe de candidats intéressants. D'autant plus que je vois pas comment un RH peut faire le premier filtre sans rencontrer la personne...
Ah la politique. C'est comme le mouton à 5 pattes. Sauf que le mouton en question qui serait efficace, on le voit jamais. Les politiques eux, on les voit bien...
Bonjour,
étudiant en fin de parcours, je suis ce genre de discussions depuis un moment sur le forum, et j'ai quelques entretiens (RH ou techniques) à mon actif.
Et il y a un truc qui me surprend dans tout ça. Au lieu des questions (plus ou moins bidons), pourquoi ne pas demander aux candidats de venir avec des projets déjà réalisés ? Pour les jeunes diplomés au moins, c'est possible sur leurs projets d'étude (pour les autres pas sûr).
Sur un projet Objet, si le candidat peut expliquer son projet, et pourquoi il a pris telle solution ou telle autre, on devrait être plus sûr de sa maitrise de l'Objet que si il a répondu à 3 questions, non ? (si non, il a récupéré un projet sur le net ou auprès de sa promo)
PS : en plus, le code éviterais que je vous enfle en vous parlant d'un projet trop cool où j'ai compris la théorie mais j'ai été incapable de mettre ça en pratique
J aurais envie de dire : Ne bosse JAMAIS pour une SSII.
Si tu es jeune diplome se sera la solution de facilite mais peut etre pas la bonne.
Il vaut mieux chercher une "vrai" entreprise, qui va te faire bosser avec des gens competent. A travers d une SSII cela est tres complique pour un tas de raisons dont le turn over.
Si tu jeune diplome, que tu cherches juste un job pour manger, la SSII est faite pour toi. Meme si tu es "mauvais", tu t entraines a faire 10 quizz sur le net.Tu vas retrouver les meme questions a l entretien, donc un peu de bachotage et c est bon. Evidemment, ton travail sera de la meme ampleur que ton entretien, c est a dire ininteressant.
Il vaut mieux chercher a bosser avec des gens competents et apprendre d eux.
Le meilleur moment pour cela, cest quand tu es jeune dip.Apres tu as plein de mauvaise habitude qui sont dur a changer.
Pour les etudiants, je conseille d apprendre au moins un langage objet, le C++ biensur , et un langage de script comme le python 2.7 (on peut aussi faire de l objet) .
Pas bête en effet. On va dire que çà permettrait probablement de filtrer quelques énergumènes qui pourrissent le métier. Mais ça risque de faire des entretiens assez longs et laborieux. Si j'apporte un de mes projets perso pour prouver que je suis pas trop mauvais en développement, c'est 80 000 lignes de code à expliquer dans 40 fichiers sources... Ca risque de finir en thèse de doctorat...
Totu ceci illustre bien le challenge énorme du recrutement : c'est un pari sur l'avenir. Des fois ça marche, des fois pas. J'ai été recruté (et parfois aussi pas recruté), et j'ai moi même recruté. Je me suis parfois trompé, j'ai parfois été abusé par des candidats, j'ai probablement raté de bons candidats. C'est humain. Et prions pour que ça le reste !
Pour le recrutement, il faut s adapter au cv du candidat.
Eviter les QCM avec les gens de plus de 3 ans d exp (C est demotivant).
Je conseille sur la partie IT :
1- CV avec 0-3 ans d'exp:
1.1- Test QCM
1.2- Face a face avec un lead developer
Mise en situation, pour savoir comment le candidat va pense une solution sur un pb donne.
2-CV superieur a 3 ans d'exp:
2.1- Face a face avec un lead developer
Discution sur les design pattern, le multithreading, les lib utilisees
comme Boost, STL, Apache et autre... Le design des appli sur lesquelles ils ont travaille, pkoi ils ont choisi ce design et pas un autre .
Les livres qu'il a lu, connait il les references, etc...
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager