Discussion :

[Imperium]

Bonjour à tous,

Tout d'abord, j'espère ne pas me tromper de forum, le cas échéant, veuillez accepter mes plus plates excuses .

Alors voilà, je réalise actuellement un petit devoir scolaire sur l'évaluation d'un Ingénieur développement lors du premier entretien et par rapport à son CV.
L'évaluation ne doit pas être très profondément technique, mais dois survoler les compétences (techniques ou non) mises en œuvre lors de ses différentes expériences professionnelles.

Je suis donc parti sur un tableau divisé en plusieurs points. Je ne suis pas ingénieur développement, je touche très peu au développement (je connais le théorique, très vaguement), et c'est pourquoi je poste ici afin de profiter de vos conseils avisés.

Mes questions sont les suivantes : Mes "points" sont-ils pertinents ? Et surtout, en voyez-vous d'autres que j'aurai pu oublier ?

Points purement techniques :
- Langage(s) de développement utilisé(s) ? Pendant combien de temps ?
- Plate-forme de développement utilisé(es) ? Pendant combien de temps ?
- Framework(s) utilisé(s) ?
- Utilisation de base de donnée ou de système de gestion de base de données ? Si oui, lesquels ?
- Type d'application développée ?
- Contraintes techniques rencontrées (exemple : temps réel) ?

Points sur le contexte de ses expériences professionnelles :
- Projet(s) réalisé(s) en régie ou en forfait ?
- Etait-il (elle) intégré dans une équipe ? Si oui combien de personnes ?
- Etait-il (elle) rattaché à un chef de projet / expert technique ?
- A-t-il (elle) du aborder le côté fonctionnel du projet ou s'est-il(elle) limité uniquement au côté technique ?


C'est à peu prêt tout

Je vous remercie par avance pour vos réponses !
Bonne journée !

[_vince_]

Le savoir-faire est important.

Mais il ne faut pas oublie le savoir-etre et les qualites non techniques (autonomie, debrouillardise, esprit cooperatif, rigueur, methode, esprit d'analyse, capacite a resoudre un probleme, capacite a apprendre une nouvelle technique, volonte de faire du travail de qualite en s'informant des bonnes pratiques, passion pour le logiciel, etc.). Mais ca a mon avis, ca ne se voit pas sur un CV.

[Imperium]

Merci pour ta réponse.

Effectivement, le savoir-être est important, et j'ai déjà terminé et "validé" cette partie

[_vince_]

Points purement techniques :
- Langage(s) de développement utilisé(s) ? Pendant combien de temps ?
- Plate-forme de développement utilisé(es) ? Pendant combien de temps ?
- Framework(s) utilisé(s) ?
- Utilisation de base de donnée ou de système de gestion de base de données ? Si oui, lesquels ?
- Type d'application développée ?
- Contraintes techniques rencontrées (exemple : temps réel) ?

Je rajouterais (pele-mele) :

- Connaissance d'outils de gestion de configuration (CVS, SVN, ClearCase, etc) ?
- Connaissance d'outils de suivi de bugs ?
- Methodes/outils de conception ?
- Methode de developpement ? (cycle en V, XP, etc.)
- Methode qualite ?
- Notion de programmation defensive ?
- Connaissance/maitrise de la programmation orientee objet ?
On peut coder en C++ sans faire d'orientee objet et a l'inverse, on peut coder en C et "faire" de l'orientee objet.

Etre temps reel est une caracteristique du systeme d'exploitation. Pour les passionnes, ce n'est pas une contrainte. Neanmoins la programmation temps reel exige d'autres connaissances en plus de la programmation "classique".

[Imperium]

Merci beaucoup Vince ! Ton post va beaucoup m'aider car j'avais effectivement oublié certaines choses importantes. Merci encore.

[la drogue c'est mal]

"évaluer" un developpeur, ca prend 5 min.

Tu lui demandes d'expliquer ce qu'il a fait sur un projet, tu poses 2/3 questions et en fonction de ses réponses, tu sens si c'est un pipoteur ou non.

Je ne pose jamais de question directe mais plutot des questions vagues, ca me permet de distinguer qu'est ce qui est le plus important à ses yeux (généralement la premiere chose qui me raconte).

Par exemple, si un type commence par me parler de l'algo qu'il a développé sans me parler du contexte, bah soit il a pas pigé le contexte soit il s'en fou. Pour moi, c'est pas bon si il doit travailler avec des personnes non techniques.

En gros, faire parler le développeur pour qu'il se "grille" lui même

[_vince_]

"évaluer" un developpeur, ca prend 5 min.

Tu lui demandes d'expliquer ce qu'il a fait sur un projet, tu poses 2/3 questions et en fonction de ses réponses, tu sens si c'est un pipoteur ou non.

C'est vrai si la personne qui fait passer l'entretien est lui-meme developpeur.

Si la personne n'est pas developpeur, ca doit etre un peu plus dur a mon avis...

[_vince_]

Merci beaucoup Vince ! Ton post va beaucoup m'aider car j'avais effectivement oublié certaines choses importantes. Merci encore.

Je dirais que ma liste ne sert pratiquement a rien, car tout ca s'apprend.

[la drogue c'est mal]

Si la personne n'est pas developpeur, ca doit etre un peu plus dur a mon avis...

Apres, si la personne n'est pas technique, je ne vois pas en quoi ca va l'avancer ton questionnaire

parce que

On peut coder en C++ sans faire d'orientee objet et a l'inverse, on peut coder en C et "faire" de l'orientee objet.

moi je te réponds :

tout dépend de la définition meme de la programmation objet. Si on parle de concepte ou d'implémentation.

Sur le concept, on peut essayer difficilement de mettre en œuvre en "C" quelques principes de l'OO sans pour autant aller jusqu'au bout (polymorphisme etc...) bien qu'entre 2 langages reconnus comme étant de l'OO, on ne retrouve pas exactement les memes les choses. Par exemple en C++ on peut faire de l'héritage multiple et pas en JAVA, meme si en JAVA on retrouve une approche d'héritage multiple à travers les interfaces.
etc...

si j'ai pas un teckos en face de moi, il est largué.


recruter un developpeur sans passer par un entretien avec une personne technique est tres risqué (sans forcement parler d'entretien technique).

[Imperium]

Merci pour vos réponses.
Il s'agirait en fait d'une sorte de fiche récapitulative qui servirait lors d'un entretien de présélection de type RH mené par un chargé de recrutement. Ce type de "questionnaire" (sans en être un, il s'agirait plus d'un référencement technique) servirait de support pour orienter les questions de l'entretien technique.

[_vince_]

tout dépend de la définition meme de la programmation objet. Si on parle de concept ou d'implémentation.

Je suis d'accord avec toi. Le but de ma remarque etait de dire:
Attention! Ce n'est pas parce qu'on ecrit C++ dans un CV qu'on a compris ce qu'est la programmation objet. Car actuellement, je maintiens du code ecrit en C++ mais pas orientee objet pour un clou. Le programmeur originel est un ancien trop habitue au C pour se remettre en question.

[el_slapper]

(.../...) Le programmeur originel est un ancien trop habitue au C pour se remettre en question.

à la rigueur, je dirais que si il fait du propre sans objet, ça vaut sans doute mieux que des expérimentations dans des domaines qu'il ne maîtrise pas et qui seraient illisibles.....

Sinon, j'aime bien la méthode de "la drogue c'est mal". Simple, efficace, et ça marche même pour des technos que l'on ne connait pas.

[gl]

Par exemple, si un type commence par me parler de l'algo qu'il a développé sans me parler du contexte, bah soit il a pas pigé le contexte soit il s'en fou. Pour moi, c'est pas bon si il doit travailler avec des personnes non techniques.

Oui et non, ça dépend fortement du cadre de l'entretien.

Dans le cas d'un entretien technique, ce choix du candidat peut sembler logique lors d'un entretien technique, surtout si un entretien "métier" ou plus "orienté projet" est prévu (puisque le contexte devrai être abordé à ce moment là).
Même si il est certes préférable pour le candidat (et d'ailleurs de manière générale) d'aborder le contexte de la réalisation avant de rentrer dans le détail de celle-ci, utiliser un entretien technique pour savoir si le candidat à compris ou s'intéresse au contexte est amha une erreur.

Maintenant s'il ne s'agit pas d'un entretien technique mais d'un entretien plus "global" (par exemple dans le cadre d'un recrutement avec un entretien unique), la méthode me semble plutôt bonne.
Même si je ne pense pas qu'il soit judicieux d'en faire un motif rédhibitoire en lui-même (après tout, le candidat peut malgré tout s'intéresser au contexte mais a mal juger l'intention de son interlocuteur), par contre c'est un bon indice pour orienter la suite de l'entretien dans une direction plus "métier" afin de valider l'intérêt et la compréhension du candidat sur le contexte.

[gl]

Il s'agirait en fait d'une sorte de fiche récapitulative qui servirait lors d'un entretien de présélection de type RH mené par un chargé de recrutement.

J'ai quand même des doutes sur l'utilité et l'intérêt d'un tel questionnaire durant un entretien RH.
A priori :
- le RH ne vas pas comprendre ce qu'il remplit (avec les risques de mal le remplir que cela sous-entend),
- ca ne va pas intéresser le RH qui risque de remplir ce questionnaire rapidement et pas forcément correctement voire de ne pas le remplir du tout.
- que va-t-il bien pouvoir faire si le candidat ne "rentre pas dans les cases" ?

A la limite, je vois l'intérêt de demander à un candidat de remplir un tel questionnaire en vu d'un entretien technique.
Par contre je reste dubitatif sur le fait de le faire remplir par un recruteur lors d'un entretien RH.

[gl]

Attention! Ce n'est pas parce qu'on ecrit C++ dans un CV qu'on a compris ce qu'est la programmation objet.

Oui, ce n'est pas nouveau.
C++ n'est pas un langage purement objet mais un langage autorisant plusieurs paradigme dont l'orienté objet.
Croire que "C++ implique objet" est une erreur (ou dans certains cas une approximation simplificatrice).

[Imperium]

La conversation a légèrement dévié, mais voici les critères "savoir-être" que j'avais retenu :

Aptitude à progresser
Esprit analytique
Adaptabilité
Esprit d’équipe
Sens de la communication
Esprit de service
Sens de l’organisation

[leila92]

Voici une liste de questions que je pose habituellement en entretien (après en général on s'adapte à ce que dit le candidat et à son profil). C'est pas exhaustif.


au niveau savoir être :

sérieux et fiabilité
sens du service
expression, capacité à communiquer
dynamisme
potentiel d'évolution
ouverture et curiosité


au niveau technique pour chaque expérience :

langages de dév, AGL
frameworks
serveurs d'appli
SGBDR
syst d'exploit
outils de modélisation, de gestion de conf, de tests,
progiciels
les versions
Ensuite on peut demander des précisions en fonction de l'environnement technique

contexte :

quelles types d'applications
est ce de la maintenance ou des nouveaux développements
taille de l'équipe et son organisation
quelles ont été ses "tâches" : cahier de charge, conception, modélisation de base, réalisation, tests d'intégration, mise en prod...
normes de dév, methodologies
régie ou forfait
raisons des départs à chaque fois qu'il a changé de société

On valide aussi le niveau anglais et l'obtebtion des diplômes

Il faut aussi valider ses motivations, voir ce qu'il souhaite faire (préférence tech et au niveau du secteur d'activité et en terme de poste...), et son évolution.

Date de dispo, mobilité et les pretentions salariales.

Et surtout on évite les questions bidons du genre citez moi vos qualités et défauts ou est ce que vous aimez travailler en équipe.

Voilà, si t'as des questions,faut pas hésiter

[leila92]

C'est vrai si la personne qui fait passer l'entretien est lui-meme developpeur.

Si la personne n'est pas developpeur, ca doit etre un peu plus dur a mon avis...

Je te confirme c'est un peu plus dur!!

[_vince_]

Et surtout on évite les questions bidons du genre citez moi vos qualités et défauts ou est ce que vous aimez travailler en équipe.

Pour les defauts, n'est-ce pas un moyen de tester l'honnete du candidat ?

On peut voir s'il donne une reponse tout aussi bidon en disant par exemple : "je suis trop rigoureux".
Ou au contraire, il peut donner une reponse honnete...

Qu'en pensent les specialistes des entretiens ?

[Imperium]

Merci Leila ! C'est vraiment sympa d'avoir pris le temps de me répondre.

Effectivement, le plus dur est d'assimiler la partie technique, au moins de quoi discuter un minimum avec la personne que l'on a en face pour comprendre ce qu'il dit !

Je suis personnellement chargé de recrutement stagiaire (stage de 6 mois), et c'est pour moi le plus gros obstacle à surmonter.