Hello,
A votre avis, quelle est la meilleure façon d’évaluer les compétences d’un développeur (par exemple, lors d’un entretien d’embauche) ?
Je suis encore novice dans ce domaine, mais je pense que c’est au niveau de projets que l’on à realisé
A mon avis ça dépend du projet sur lequel il est recruté :
Pour du long terme, le principal est d’avoir quelqu’un qui se tient au courant des nouveautés et qui peut apprendre facilement plus que quelqu’un avec de l’expérience.
Pour une mission courte, il faut bien sur quelqu’un avec un bagage suffisant pour attaquer le projet tout de suite.
Pour moi un bon développeur c’est quelqu’un qui a conscience de ne pas simplement écrire du code mais surtout fournir de la valeur métier et qui ne se cantonne pas à ses connaissances.
Perso, je pense que la meilleure évaluation, c’est de parcourir ensemble le code d’un projet réalisé par le dev.
C’est l’occasion de voir les bons réflexes et les gros défaut :)
On arrive rarement à tronquer son niveau avec ce genre de demo.
2 « J'aime »
Hello,
Le plus important pour évaluer les compétences d’un développeur, à mon sens, reste la discussion. En fait, plus un développeur back ou front est à l’aise avec l’explication de son code, plus il est compétent sur ce qu’on lui a demandé de réaliser. L’avantage que j’en tire à “perdre du temps à discuter” est qu’on arrive à lever certains loups bien cachés durant la phase de développement.
Coté entretien, je vous partage un lien bien sympathique pour les développeurs front : https://github.com/h5bp/Front-end-Developer-Interview-Questions/tree/master/Translations/French
Attention cependant, ce document est très accès technique, en sachant que ce qui m’a permis de choisir entre 2 développeurs front a été la réponse à la question “Tu es plutôt ninja ou pirate ?” : le premier n’a pas compris la question, alors pour le 2nd la réponse était évidente :)
1 « J'aime »
Mettre à l’épreuve la maîtrise d’une toolchain au choix du candidat.
Personnellement, si un employeur prononce un mot du genre de ninja/pirate/gourou, je décline l’offre.
2 « J'aime »
Tu me fais peur @Bahanix, dans quel contexte ?
Parce qu’il y a les fameux “Ninja CSS” ou “Gourou CSS”, et juste le choix d’être soit un ninja dans l’âme ou un pirate (tu sais, avec le bateau et tout).
Je rappelle juste que dans notre domaine, on se tutoie tous, on communique tout ce qu’on fait, on partage bien plus que de simples lignes de code, etc. On est d’abord des passionnés avant d’être des employers.
Evaluer les compétences d’un développeur ne relève pas juste de la qualité de son code, mais aussi de sa capacité à s’adapter à un milieu aussi hostile soit-il, c-a-d à ses coéquipiers, son environnement de travail. Il est donc aussi évaluer à travers sa capacité à communiquer et s’entendre avec les autres.
Je te suis sur ton dernier paragraphe. Si j’ai parlé de toolchain, c’est parce que la question porte sur les compétences.
Si ça n’a pas vocation à faire référence à la culture Ninja/Guru/Jedi/Rockstar, je trouve cela risqué, c’est le premier lien que j’ai fait. Si l’idée est de savoir quel est la vie fantastique de nos rêves, autant le demander tel quel, sans contraindre à un lexique guerrier.
Ah oui, je te l’accorde : de mon coté, je suis ultra fan des pirates, du coup j’ai toujours une référence à cet univers, ça me permet de sortir du cadre “pro” pour en savoir plus sur l’esprit de la personne en face de moi :)
Vaste question d’évaluer quelqu’un.
Si on se concentre sur les compétences en général nous faisons un mix d’échange oral entre le candidat et en général 2 ou 3 développeurs si possible avec des spécialités différentes (ce qui permet aussi de mieux appréhender les aspects non technique) et un coding dojo. En pair programming (en rotation avec 2 dev en général), avec git et l’utilisation d’un framework de test unitaire (sur le langage choisi par le candidat).
C’est pour le moment ce que nous avons trouvé de plus efficace pour confirmer (ou non) les dires des candidats mais aussi pour aller voir beaucoup plus loin que la maitrise ou non d’une techno. Car la maitrise de la techno n’est pas suffisante, il est important de voir comment la personne code, si elle fait des tests ou non, comment elle réfléchi et si on serait prêt à bosser en binome avec la tout de suite maintenant. C’est assez strict comme test mais le résultat est que si on refuse pas mal de monde on ne se trompe que très peu. Par contre, ça prend du temps de notre côté.
1 « J'aime »
Et juste parce que certains en parle, on évite tous les trucs de geek, ninja, pirate, “quel est le meilleur xkcd ?”, etc. Ça n’a pas grand intérêt et ce n’est pas ça qui indique si la personne va pouvoir s’intégrer ou non. On s’attache plutôt à faire les entretiens à plusieurs, voir si le “feeling” passe et si on pense que la personne va pouvoir s’intégrer correctement dans l’équipe. On est plus intéressé par l’autonomie de la personne et sa capacité d’apprentissage que par sa culture geek ou autre.
2 « J'aime »
Pas grand chose à rajouter à ce qu’a dit CrEv :
Entretient en 2 étapes :
- Dicussion ouverte avec plusieurs personnes de l’équipe tech
- Session de pair programing avec le candidat
C’est ce qu’on fait et ça marche très très bien, à la fois pour valider les réels compétences tech de la personne mais aussi tout ce qui va autour et qui est tout aussi important :
- Le relationnel : Est ce que l’équipe aurait envie de travailler avec lui
- Les habitudes et méthode de travail : test first / test after / pas de tests, style de code, etc
J’ajouterais qu’en plus ça évite le stress d’un test plus scolaire avec des exercices à résoudre, souvent les candidats eux aussi préfèrent le pair programming.
Ca permet de donner une image plus sympa de la boite, y a rien de plus froid et impersonnel qu’un challenge d’algo à résoudre…
2 « J'aime »
Testcandidat.com permet de tester les compétences d’un développeur pour les langages les plus utilisés Java python C# C++ javascript… Ils ont une offre gratuite je penses.
Salut,
Chez nous, ce qui marche bien, ce sont deux choses: un test d’entrée qui vise à juger les compétences d’algorithmie du candidat et ses compétences d’analyse du besoin (parce que les pisseurs de code, on s’en tappe), et le feeling que l’on avec ce candidat, pour savoir s’il s’intègre bien à l’équipe et s’il complète bien les compétences existantes.
Comme dit, osef totalement que le candidat ne connaisse pas les stream Java8, qu’il ne maitrise pas à 100% les grilles CSS, ou qu’il soit resté coincé à ECMAScript4 & jQuery 1. Ce qui compte, c’est de voir sa démarche pour répondre au besoin/à la problématique qu’on veut lui sousmettre car c’est ce qui sera décisif sur la qualité de l’équipe à long terme (on travaille sur des projets de 20 ans de durée de vie chez nous).
1 « J'aime »