Bonjour,
 
le titre du post c'est plutôt : Comment mesurer le niveau de maîtrise d'un langage de programmation par un développeur ? (Trop long..)
Je ne sais pas si cela est très claire ...alors je m'explique...
 
je cherche un développeur en ce moment et je compte donc mettre des petites annonces dans les sites.
Au lieu de recevoir les propositions par email, j'ai eu une idée extraordinaire lol ...je me suis dis
pourquoi pas envoyer les candidats sur un formulaire qu'ils pourraient compléter rapidement et y uploader  
leur CV... Pourquoi ? Parce que cela me permettrais de stocker tout ça dans une base de donnée et je pourrais
ainsi faire des recherches assez pointu dans la base sans relire les 30 CVs ...voilà donc l'idée..
 
Maintenant reste à faire ce fameux formulaire et c'est la ou j'aurais besoin de vos lumières. En effet,
j'aimerais que les candidats s'auto-évalue sur leur maîtrise d'une technologie..et donc la question est comment faire ?
 
Prenons un exemple :
Programmation en langage PHP :
Il y a des développeur junior, moyen et confirmé ..comment le traduire ?
Est ce qu'il serait opportun de mettre une note de 1 à 5 ? ou plutôt un truc du genre junior/midle/débutant/confirmé/expert...
C'est quoi pour vous l'échelle adéquate pour ce genre de mesure ? avec quelles graduations ?  
Je cherche quelque-chose de simple et efficace..
 
2eme question :
Quels sont les catégories dans lesquelles on pourrait ranger les domaines de compétence d'un développeur ?
Moi j'en vois 5 mais j'ai surement oublié des choses :
 
- Langage/code : Java, php, C etc
- Sript: CSS, HTML, javascript
- Framework : Zend,...
- CMS opensource : Joomla, magento ...
- Modélisation : UML/Merise
 
Merci pour votre aide
 
A+

 
T'as songé à le déclarer à la CNIL?
 
Pour le reste...un niveau déclaré par l'intéressé n'est pas une bonne mesure du niveau de quelqu'un. Et tes catégories me laissent perplexe.

Salut,
merci pour ta réponse rapide.
Je comprends ton point de vue mais au fond c'est pour faire la différence entre un développeur et un développeur ?
Un développeur ne peut pas maitriser 10 langages ..donc forcement il y a des langage ou il est hors-jeu et d'autres ou il est expert et d'autre ou il est débutant ...c'est pour formaliser cela en faite rien de plus.

A part peut-être pour Java où y'a tout un éco-système d'outils à connaître en plus du langage proprement dit, je pense pas que la maîtrise d'un langage de dév soit le plus important. Beaucoup de langages se ressemblent car ont une syntaxe proche du C/C++ (Java, PHP, javascript...). Par contre, savoir si un développeur sait créer une architecture de soft propre, s'il sait coder organiser son code proprement, qu'il a une bonne culture des algorithmes (dans le domaine des tris, de l'ordonnancement/optimisation de tâches, de la RF, de l'IA, de la modélisation de BD...), ça c'est plus important. Je préfère largement embaucher un dév bon architecte, codant proprement et connaissant bien l'algorithmie mais peu un langage plutôt qu'un dév qui connaît très bien un langage mais qui code comme un porc et est incapable de me sortir un algo capable de donner une solution à un pb que je lui soumets...
 
Un langage, ça s'apprend en 2-3 semaines. Les algos, l'architecture, ça s'apprend en plusieurs années
 
Edit : bien sûr, si tu peux avoir un dév bon en architecture/algos ET maîtrisant le langage de dév qui t'intéresse, c'est le top...

 
Tu as parfaitement rason rufo ..le point que tu reléve est fondamentale car effectivement l'espect architecture, conde propre, modélisation intellgente, structure de la base c'est fondamentale et moi ausi je préfére avoir un deve qui developpe proprement et qui sort des application scalable et maintenable. Maintenant la question c'est comment tu peux savoir cela avant d'embaucher la personne ? c'est trés difficile à percvoir..je n'en ais aucune idée..as-tu une idée sur comment procéder ?

Demander sur quel projets open-source ils ont bossé et sous quel nom ils faisaient leurs commit. Cela permet assez vite de voir comment ils codent.

Par un entretien. Tu peux lui demander s'il peut te montrer des projets sur lesquels il a bossé en entreprise ou à titre perso (c'est un bon indicateur, un bon dév fait presque toujours des softs sur son temps libre, certains publiés en GPL ou autre licence gratuite : dans ce cas, facile de voir la qualité du code source). Dans le cas de projets en entreprise, lui demander :
- avec quels outils il a travaillé,  
- quelle méthodologie pour modéliser le soft,  
- quelle méthode pour développer (cycle en V, méthode agile comme Scrum, XP, test driven...). L'emploi d'une méthode agile (et correctement) peut-être un indicateur de maturité dans la façon de développer en équipe car les méthodes agiles sont pas si répandues que ça dans les SSII apparemment (en général, très old school avec le cycle en V)...
 
Mon avis est qu'à un moment donné, le candidat devra passer devant une personne suffisamment compétente dans le ou les domaines techniques recherchés pour lui poser des questions de culture dans ces domaines.
 
Ex : si c'est pour faire un outil web, lui poser des questions sur les frameworks qu'il connaît et/ou déjà utilisé, s'il a déjà tuné le fichier de conf de MySql (si oui, quelles parties et pourquoi), ce qu'il sait des règles d'accessibilité sur le web (A, AA, AAA), voir s'il connaît l'utilisation sémantique des balises html (ex : la différence entre <b> et <strong> )...
 
En général, ça permet de voir la culture du candidat dans le domaine technique concerné. Si on reste sur le web, un candidat qui connaît pas de framework, qui ne sait pas que les règles d'accessibilité A/AA/AAA c'est en rapport avec le handicap (et non l'ergonomie, réponse souvent donnée par ceux qui connaissent pas), qui sait pas trop ce qu'est l'utilisation des balises pour leur caractère sémantique et non leur rendu visuel, ça donne une bonne tendance (mais c'est pas infaillible).
 
Pour le côté algo, pourquoi pas proposer au candidat un petit problème où il faudrait simplement qu'il expose l'algo qu'il mettrait en oeuvre (bien souvent, juste le nom de l'algo suffit, ex : un pb modélisable par le un pb du plus court chemin -> Dijkstra). Dans le cas d'une heuristique, l'expliquer un peu plus. Rien que déjà si le candidat part sur un algo "connu" ou une heuristique permet d'évaluer sa capacité à détecter la classification du problème à résoudre (P, NP)... Genre pour le pb du plus court chemin, s'il commence à inventer à truc à sa sauce et qu'il donne pas de suite Dijkstra, méfiance ! (bon, sauf s'il retrouve tout seul l'algo de Dijkstra, là, c'est que le mec n'a pas de culture, mais qu'il doit pas être mauvais du tout en algorithmie )...

Dans l'ensemble je suis plutôt d'accord rufo, et j'imagine que c'est sans doute seulement un exemple, mais c'est un peu réducteur,.

Tripleclick demande en gros la définition d'un développeur sans préciser une seconde la finalité, de nos jours (et depuis qques temps) développeur c'est large, il le dit lui même mais sans aller au bout => sauf à trouver une méthode d'évaluation du génie et ça marchera partout, il faut cibler la demande en fonction du but à atteindre, bref tripleclick, on veut bien t'ader, mais sois plus précis, on ne vas pas te pondre un manuel du drh ^^

Il s'agissait bien entendu d'un exemple. C'était surtout pour insister sur le fait qu'il vaut bien mieux embaucher un dév qui a de bonnes connaissances des algos/modélisation/architecture/méthodo + une bonne culture/état de l'art du ou des domaines techniques recherchés par l'entreprise plutôt qu'un dév qui pisse du code rapidement en exploitant certes la puissance du langage (voire même en optimisant la vitesse d'exe de son code) mais produisant au final du code difficilement maintenable, donc peu intéressant pour une entreprise.
 
A pas négliger non plus, les qualités humaines du dév : perso, je trouve plus pratique d'avoir un employé autonome, qui sait prendre des initiatives, qui réfléchit avant d'agir, qui est structuré dans sa démarche, qui est organisé, qui est ponctuel... plutôt qu'une personne bordélique, qu'il faut surveiller en permanence et lui dire de faire la moindre petite tache, sinon elle fait rien, ...

merci pour vos conseils ! trés interessant !
rufo : ce que tu dis est pertinent mais malheuresement cela dépasse un mes compétences technique...Tu vois ce qui serait bien c'est qu'un âme charitable me fasse une questionnaire avec les réponses attendus..une dizaine de question bien pointu qui éliminera 80% des mauvais développeur. Mais je comprends que c'est long à faire si on veut que ce soit carré.
De plus c'est pas un truc ) posté sur un forum car tout le monde verra les réponses ..donc what is the solution ? une idée lumineuse à suggéré ?

 
Ben déjà, faudrait savoir pour quel poste tu recrutes et quel projet de dév le candidat sera amener à travailler. Et y'a pas de questionnaire type, ça dépend aussi de la sensibilité de celui qui fait passer l'entretien. De plus, si le candidat voit que le recruteur n'y connaît rien et lit un questionnaire, ça va pas le faire. En effet, si y'a pas de questionnaire type, y'a pas non plus de réponse type. Ce qui est intéressant, à mon sens, pour le recruteur, c'est de voir comment le candidat comprend les questions (partagez-vous tous les 2 le même langage, la même terminologie, ce qui fait que dans le boulot, vous aurez pas trop de pb de communication) et comment il construit sa réponse (+ la pertinence de la réponse elle-même bien entendu), s'il a besoin que le recruteur le mette un peu sur la voie de la ou les réponses attendues. Mais des fois, le candidat peut donner une réponse à laquelle le recruteur n'avait pas pensé mais qui peut s'avérer juste ou correcte dans un certain contexte auquel cas, le recruteur doit être capable d'analyser la réponse et si celle-ci est partielle, de demander au candidat d'apporter des précisions.
 
Pour moi, un bon entretien, c'est un dialogue, un échange dans les 2 sens entre le recruteur (qui ne sait pas tout) et un candidat (qui doit convaincre qu'il correspond au poste demandé).
 
Si tu n'as pas sous la main une personne compétente dans le domaine concerné par le poste, il faudrait te faire aider. Sinon, tu risques d'y aller à l'aveuglette et te faire avoir par un candidat qui aurait juste "lâché" les bons mots/termes/réponses pour faire illusion devant qq'un qui ne s'y connaît pas. Alors qu'avec qq'un qui va "gratter" un peu plus, ce type de supercherie tient rarement longtemps...
 
Edit : du reste, dans les SSII, y'a toujours au moins 2 entretiens : l'un avec le DRH pour présenter la boîte, les avantages, salaire..., l'autre avec le chef de projet ou un mec technique pour évaluer les compétences techniques justement.

N'importe quoi.
J'ai côtoyé nombre de bon développeurs au cours de ma carrière, que ce soit en France ou aux USA, et la grande majorité consacrait son temps libre a sa famille, a faire du sport, ou une autre activité de loisir.  
A+,

 
Je pensais à ça plus particulièrement pour les jeunes développeurs qui ont donc rarement une famille à charge... Concernant mon expérience, je fais parti de plusieurs assos avec un certains nb de membres qui sont dans le dév : un grand nb d'entre-eux font des "softs" plus ou moins important pour les assos en question. Moi-même, je suis en train d'en faire un. Dans mon entourage, j'ai pas mal de bons dév : j'en connais pas un qui ne fais un peu de dév à ses heures perdues (y compris ma femme ), pour automatiser des trucs, améliorer des choses...
 
Après, je suis d'accord avec toi que mon "presque toujours" est sans doute un peu surestimé.