Crédit photo : st3f4n Creatives Commons Attribution-NonCommercial-ShareAlike 2.0 Generic
Nous sommes dans une salle de réunion il y a quelques jours. Je fais passer un entretien à un candidat. Nous sommes assis devant un PC avec Eclipse. Le candidat m’explique ce qu’il fait.
– Ici donc j’additionne les chaînes de caractères pour construire la phrase, en mettant une virgule
– Je vois cela. Est-ce que vous connaissez une autre technique que la concaténation de chaine ?
– Pardon ?
– … que votre addition de chaîne pour utiliser le même terme
– Euh… je ne connais pas très bien Java 5
Recruter un développeur est un exercice intéressant. Vous serez amené un jour à faire passer un entretien, c’est un exercice intéressant qu’il faut bien préparer. Cela vous rappellera aussi comment vous aviez été sélectionné. Cela doit aussi vous donner l’opportunité de bien recruter. En Anglais nous disons plutôt « evaluation interview », ce qui montre bien l’importance d’évaluer le niveau d’un candidat par rapport à votre besoin. Ce que je vais dire est tiré de différents blogs comme le blog de Joel Spolsky. Les initiés ne seront donc pas surpris.
Tout d’abord peu importe le CV, il n’y a pas de bons développeurs et de mauvais développeurs. Ce qui fait la différence, c’est une chose toute simple : la capacité à coder. Ce qui compte et ce qu’il faut évaluer, c’est le nombre d’heures de programmation que vous avez derrière vous. Moi par exemple je fais du piano depuis 20 ans. Mais en fait je suis un mauvais pianiste de Jazz car je n’en fais plus que très rarement. Vraiment une fois par mois… et encore. Lorsque je faisais vraiment de la musique j’étais bon. Mais malgré mes 20 années au compteur je ne suis pas très bon. Il faut donc évaluer le nombre d’heures de vol de votre candidat. Certains en 3 ans codent plus que d’autres en 6 ans.
Certaines entreprises lorsqu’elles reçoivent un candidat, font passer des tests type QCM. Je me souviens chez Blue XXX_ing que le QCM en 2008 ne portait que sur Java 1.4 et qu’en plus il comportait 2 erreurs sur les 20 questions. Si pour attirer des candidats vous n’êtes même pas fichu d’avoir un questionnaire correct… Evitez d’utiliser un questionnaire pour sélectionner un candidat. Ils sont rarement en rapport avec ce que nous faisons sur le terrain. Ce n’est pas parce que je connais la différence entre une Hashtable et une HashMap que je suis un bon développeur.
Le secret de l’entretien : faire coder le candidat.
Imaginez que vous êtes un producteur de musique. Votre groupe favori part en tournée dans quelques jours. Or pas de bol, votre guitariste a décidé de claquer la porte et de rejoindre une chorale de rock catholique. Bref vous voilà pressé par le temps pour recruter un vrai talent.
Si je suis guitariste et que je viens vous voir, est-ce que franchement vous allez :
– me demander mes 10 dernières expériences en insistant lourdement sur un trou de 2 mois en 1999 ?
– me demander si je sais lire une partition ? Si je sais accorder une guitare ?
– me demander de répondre à des questions de culture générale sur la musique ?
– me proposer de lire à voix haute une partition ?
Bien évidemment que non !
Vous allez me demander de jouer de la musique. Et j’aurai 15 minutes pour vous impressionner… ou pas.
Et bien c’est ce que j’ai fait la semaine passée avec les 2 candidats que nous avons rencontré. J’ai préparé un exercice réalisable en 8-10 minutes, 2 mn si vous êtes très fort et 20 mn si vous êtes vraiment pas bon. Au bout de 20 mn je vous raccompagne dans le couloir, pas besoin d’en demander plus.
L’exercice est simple : une classe Java et une classe de tests unitaires. J’ai codé les tests unitaires afin de servir de recette et d’aider le candidat à trouver les réponses.
Ensuite voici ce que j’ai demandé :
« Ecrire une classe Java avec 3 méthodes statiques pour manipuler une collection de chaîne. Une méthode pour transformer une liste de String en une seule String, chaque élément étant séparé par une virgule. Une deuxième méthode pour afficher en ordre inverse le contenu de ma liste de chaine. Enfin une troisième méthode pour mettre en majuscule chacune des Strings de ma liste. »
Vous le voyez, rien de très méchant. Est-ce qu’il sait itérer une collection ? Est-ce qu’il sait ce que signifie List<String> ? Est-ce qu’il sait faire un peu d’algo ?
Voici le test unitaire que j’ai donné au candidat
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
import java.util.ArrayList;
import java.util.List;
import static junit.framework.Assert.assertEquals;
public class ListUnitTest {
private List<String> aTestList;
@Before
public void setUp() {
aTestList = new ArrayList<String>();
aTestList.add("one");
aTestList.add("two");
aTestList.add("three");
}
@After
public void tearDown() {
aTestList = null;
}
@Test
public void shouldConcatenateASimpleString() {
assertEquals("one,two,three", ListTest.concatenate(aTestList));
}
@Test
public void shouldRevertAList() {
List<String> result = ListTest.reverseList(aTestList);
assertEquals("three", result.get(0));
assertEquals("two", result.get(1));
assertEquals("one", result.get(2));
}
@Test
public void shouldUppercaseContent() {
List<String> result = ListTest.toUppercase(aTestList);
assertEquals("ONE", result.get(0));
assertEquals("TWO", result.get(1));
assertEquals("THREE", result.get(2));
}
@Test
public void shouldTestAll() {
List<String> list = new ArrayList<String>();
list.add("un");
list.add("deux");
list.add("trois");
list.add("quatre");
assertEquals("un,deux,trois,quatre", ListTest.concatenate(list));
assertEquals("quatre,trois,deux,un", ListTest.concatenate(ListTest.reverseList(list)));
assertEquals("QUATRE,TROIS,DEUX,UN", ListTest.concatenate(ListTest.toUppercase(ListTest.reverseList(list))));
}
}
J’ai regardé comment le candidat se débrouillait. Sur quels points il bloquait un peu, et sur quel point il se débrouillait. A la fin de l’exercice, je prends le clavier et le candidat me dicte ce qu’il faut faire. Souvent cela l’aide à terminer, il n’est pas freiné par sa maitrise d’Eclipse par exemple. Et il termine l’exercice même si le reste ne s’est pas très bien passé. J’encourage aussi le candidat à lancer 15 fois les tests unitaires. J’ai vu les candidats ne pas oser exécuter les tests unitaires pour avancer… dommage.
Attention, nous savons tous qu’avoir quelqu’un assis à côté de soi peut être déstabilisant. Mais d’un autre côté, si je vous demande de travailler en pair-programming, et que vous ne supportez pas la présence d’un autre développeur… il faudra aller travailler autre part.
En conclusion donc : préparez un entretien avec beaucoup de soins. Le recrutement est vraiment très important. En tant que candidat, je vous conseille de venir avec votre PC le jour de l’entretien, avec un bout de code de votre projet. Vous pouvez défendre vos connaissances plus facilement en montrant votre maîtrise au recruteur avec un beau code, qu’avec votre costume trois-pièces.
Soyez prêt à taper quelques lignes de code, à corriger un fichier XML Spring, à ajouter un mapping Hibernate ou à taper 3 lignes de HTML. Si vous marquez HTML sur votre CV je vais vous demander de m’écrire une page simple avec quelques balises. Si vous maîtrisez JPA, je vais vous demander de lire un mapping et de me commenter votre code…
Faire coder n’est qu’une étape d’un processus de recrutement, mais je crois qu’elle est importante.
Cela nous apprend beaucoup sur les candidats, bien plus qu’un CV bidouillé par un commercial qui m’a assuré que « à ce prix là c’est une affaire » et « je vous le garde mais on va me le prendre pour d’autres missions » ou encore « il participe au Paris jugeu« .
A bon entendeur…
[Mise à jour] Damien Metzler a proposé une solution basée sur Google Guava suite à ma série d’article publiée après ce post
Voici sa proposition:
import java.util.List;
import com.google.common.base.Function;
import com.google.common.base.Joiner;
import com.google.common.collect.Lists;
public class ListTest {
public static String concatenate(Iterable aTestList) {
Joiner joiner = Joiner.on(",").skipNulls();
return joiner.join(aTestList);
}
public static List reverseList(final List aTestList) {
return Lists.reverse(aTestList);
}
public static List toUppercase(List aTestList) {
return Lists.transform(aTestList, new Function() {
@Override
public String apply(String source) {
return source.toUpperCase();
}
});
}
}
0 no like
Le recrutement d’un développeur ne peut pas se faire uniquement avec un test mais pas non plus en le faisant pratiquer. Partant d’un projet existant il est très difficile d’évaluer en 10 minutes beaucoup de choses. Généralement, on se focalise que sur un point. Dans ton exemple, tu axes ton test autour des collections, des JUnit et des String. Mais quid de la persistance ? des WS de tous types ? de la conception ? etc. Surtout que tu parles d’un développeur de 3 ans d’expérience. Chez nous, on attend autre chose d’un développeur de 3 ans d’XP que de savoir développer.
Pour résumer, je dirais que faire développer en live est à peine mieux qu’un QCM. La seule vraie stratégie selon moi, c’est un entretien technique de deux heures qui donne le temps de tout explorer et de jauger du niveau du candidat dans tous les domaines tout en débusquant les bidouilles du candidat ou du commercial.
On ne peut être que d’accord. Cela dit il y a des recruteurs qui ont pour seul but de destabiliser le candidat on allant chercher des tests assez vicelards. Et quand ils tombent sur un candiat assez bon qui ne bronche pas ça tourne au confrontement. ça m’est déjà arrivé, lorsqu’on m’a fait faire un test technique avec chef de projet qui n’avait pas un niveau si avancé que ça sur Spring.
Mais c’est clair qu’on ne peut pas prétendre entrer dans notre industrie en étant incapable de « pondre » quelques lignes de codes.
« il n’y a pas de bons développeurs et de mauvais développeurs » = ca m’a fait sourire, j’ai cru entendre Edouard Baer dans ‘Asterix 2’, genre « il n’y a pas de bons ou de mauvais architectes » 😉
C’est vrai que qques questions (ou tests ?) bien choisis peuvent faire gagner bcp de temps, en permettant de détecter ceux qui arrivent avec un bagage bien trop léger. Je me rappelle d’un candidat à qui j’avais demandé quelles étaient les grandes façons (sous-entendu, API) de traiter un document XML : ben, il n’a pas su quoi répondre… Et pour le coup, je n’avais pas été bien méchant.
Moi je trouve que c’est bien de demander à un candiat des questions simples sur des manips de String ou de XML.
Souvent des candidats parlent de leur « expérience » sur de nombreux frameworks alors qu’ils ne maitrisent même pas les bases du JDK. C’est assez étonnant.
(Comme s’il y avait une inflation sur le nombre de frameworks qu’on doit référencer dans un CV.)
J’ai préparé un exercice réalisable en 8-10 minutes, 2 mn si vous êtes très fort et 20 mn si vous êtes vraiment pas bon. Au bout de 20 mn je vous raccompagne dans le couloir, pas besoin d’en demander plus.
Je suis toujours assez atristé de constater que la qualité d’un développeur est mesurée par le temps qu’il passe à écrire 3 méthodes de manipulation de String…
Qu’est sensé mesurer le test ? La capacité qu’à un mec à savoir itérer sur une collection et effectuer des toUpper() sur une des String en un minimum de temps ?
J’imagine la réaction du recruteur : « Waou, le mec à réaliser le test en 5 minutes, ça doit être une véritable brute en java ! Dépêchons-nous de le recruter, il va apporter énormément à l’équipe ! »
Sérieusement, je ne compte plus le nombre de prestataires recrutés sur la base de ce type de tests qui se sont révélés très mauvais.
De même, je ne compte plus le nombre de développeurs réellement intéressents à côté desquels la société pour laquelle je travaille est passée à côté, ceci à cause d’une mauvaise concentration en situation de recrutement (perte de moyen due à un éventuel chrono, etc…).
Pour ma part, quand je fais passer un entretien technique, le code m’intéresse peu. Ce que je veux évaluer sur le plan technique, c’est le degré d’abstraction du candidat par rapport à un problème donné.
Par quel bout prend-il le problème ? Comment l’analyse-t-il ? Est-ce qu’il plonge tête baissée dans le code ?
Tout le monde sait faire un hello world en java, ou un équivalent algorithmique tel que celui proposé par cet article, pour peu d’avoir lu un ou deux tuto j2se. Tout le monde sait également utiliser une api, pour peu qu’une documentation soit livrée avec.
En revanche, connaître les fondamentaux des langages objets, savoir imaginer et concevoir une application élégante, appliquer tel ou tel design pattern quand il le faut, savoir faire du code réentrant, appliquer un style architectural plutôt qu’un autre, etc… Telles sont les questions auxquelles je veux confronter le candidat.
On ne fait pas de l’ingénierie logicielle pour rien. C’est un métier qui demande de la culture informatique et de solides bases théoriques.
Même pour un poste en développement java, je préfèrerai de loin un candidat avec un profil c++ qui maîtrise parfaitement les concepts objets plutôt qu’un candidat avec un profil java qui ne sait pas ce qu’est le polymorphisme (véridique, ça c’est vu).
Le contexte d’examen de recrutement est déjà assez déstabilisant en soi pour rajouter le côté « chrono » ainsi que la punition suprême « on vous appellera » si l’examen dure plus de 20min…
Je préfère quand le test prend la tournure d’une discussion autour d’un pc et d’un café (qui a dit « plutôt autour d’une bière » ? :P), avec du code et des tests pour concrétiser, à la fin, lorsqu’on tombe d’accord sur une solution et comment on la met en oeuvre.
Si à la fin, je vois que le code est propre et clair, c’est la cerise sur le gateau.
Il m’est arrivé de discuter avec un candidat pendant une heure, et de conclure sur le fait que le langage java n’était pas forcément le choix le plus judicieux pour le problème posé.
Il ne faut pas non plus perdre de vue que l’entretien est aussi l’occasion pour le candidat d’évaluer l’entreprise pour laquelle il postule…
Faire coder n’est qu’une étape d’un processus de recrutement
Cette simple ligne rattrape l’article entier.
Bonjour Nico,
on parlait justement ce soir au Scala User de recrutement. Voici un retour d’expérience puisque depuis 3 ans maintenant, c’est moi qui recrute (pratiquement) tous les profils technique de la société.
Mon processus est le suivant :
1. entretien téléphonique avec le candidat. En général cela dure 15 / 20 mn max.
2. entretien physique avec présentation du candidat puis questionnaire technique (2h max)
3. codage sur un problème algorithmique pur, et je demandes des tests (TU ou TF) (6h max)
4. une journée à la R&D en travaillant par pair avec 1 ou 2 futurs collègues du code en prod (1j max)
5. entretien avec le DG pour croisement des points de vues
L’entretien tel me permet d’éliminer 80% des candidats. On voit vite la motivation, l’intérêt pour le poste et la programmation en général, Si la personne a un projet personnel ou non. Ses tournures de phrases, son vocabulaire, ses références donnent beaucoup d’indications (début de profil psychologique).
Le questionnaire (qui porte sur Unix, Python, la programmation et la culture informatique) n’est pas noté, et il est plus utile pour voir les gens réfléchir que pour savoir s’ils connaissent par coeur des trucs. Les questions sont souvent trés simples et *sans* piège. Selon les réponses et l’expérience citée par le candidat, je pose d’autres questions (plus pointues, plus completes…).
Le défaut numéro 1 des questionnaires est d’étre bien trop pointue. Connaitre la signification de l’option -b de la commande machin, ca a peu de sens si c’est pas une option usuelle.
Le defaut numéro 2 est d’être traité automatiquement. Rien ne vaut un échange avec un candidat, pour adapter ses questions, jauger ses réponses et voir comment il résonne.
Les questions simples suffisent souvent, même celles qui semblent anodines. Par ex: je pose la question, qui est l’inventeur du langage Python, Java et C ? Ca me permet de savoir si la personne est passionnée, si elle a lue, si elle connait l’histoire de l’info (et non la réponse n’est pas K & R pour le C :). Un passionné Python qui ne connait pas les PEPs ou PyPI a une grosse lacune.
Ce questionnaire dynamique donne beaucoup d’indications, qui faut jauger au regard du profil du candidat.
Ensuite, il code sur un sujet trés simple : peu de math et purement algorithmique (pas de réseau, IHM, SGBD,…). Il doit m’expliquer son cheminement, comment il voit la solution, comment il code et fait ses tests. Je m’absente souvent pour éviter la pression (cela reste un entretien d’embauche). Encore une fois, le maitre mot est adaptation.
Il m’arrive de faire intervenir des collegues quand je ne suis pas 100% sur de mon point de vue, soit pour une expérience que j’ai du mal à jauger (tel domaine de compétence), notamment le profil psychologique : et oui, un ex chercheur n’a rien avoir avec un dev open source par ex. Vocable différent, postures intellectuelles différentes, je me sens moins à l’aise avec certains profils.
Je debriefe avec lui, sur le résulat, la méthode. A ce stade, j’ai une bonne vision du candidat.
Dernier pallier important, la journée R&D, qui a 2 objectifs :
– voir si je n’ai pas menti sur nos méthodes de travail et savoir si l’ambiance et les collegues sont interessants.
– que les autres développeurs le jaugent et donnent leur avis.
L’embauche est un choix *collectif* car c’est eux qui vont bosser 8h/j avec lui et a ce titre, il est ridicule que seul le chef décide (meme si le chef n’est pas si mauvais ;).
La derniere étape est avec le DG et / ou PDG pour parler salaire, et avoir de mon coté un avis de non techos.
Voila, j’ai essayé de faire court sur ma façon de faire. A mardi 22h 😉
En me relisant, je pense avoir oublié 2/3 trucs.
– Voir la candidat en vrai donne beaucoup d’indications. Pour un Unixien par exemple : voir sa façon de taper, l’éditeur qu’il utilise…
– Poser des questions non techniques est essentielle. Quand je parle du PyPI, c’est pas anodin, si le candidat ne connait pas, cela signifie qu’il n’a jamais cherché de librairie ou code Libre avant de coder qq chose. Pas bon du tout ! (PyPI = CPAN perl ou Gem Ruby).
– L’adaptation autour d’une base commune (cela permet de juger par rapport aux autres candidats et donc de se faire un barometre) me semble fondamentale.
Bel article, bravo ! Difficile de bluffer dans cette situation 🙂
Comme je l’ai déjà entendu plusieurs fois, les fondamentaux doivent être maîtrisés à tout prix, le reste peut s’apprendre sur le tas. Où serait la plus-value de l’entreprise si elle ne recrutait que des développeurs qui connaissent tout ?
@Sebastien: les candidats ne peuvent pas tous se permettre de passer 15 jours par entretien…
et sinon, j’utilise gedit, je suis recalé ? 😉
@Alex l’article est forcément caricatural et je te rassure, je ne me permettrai pas de couper au bout de 20mn. J’ai un respect pour notre métier et pour les personnes. Par contre si tu as un candidat qui est vendu comme développeur sénior à 500 EUR/jour et que ce candidat n’est pas en mesure d’écrire correctement une ligne, même avec mon aide, au moins je n’ai perdu que 20 minutes. L’exercice du recrutement est d’essayer de mesurer l’aptitude d’un développeur à répondre à une tâche pour un budget donné. Je visualise un escalier. Je me dis que si le candidat arrive à la marche 4, il sera parfait pour le poste et le profil recherché. On pourrait en discuter des heures, mais sinon merci pour ton retour qui contre-balance le côté un peu caricatural (oui je me suis amusé en écrivant l’article) par rapport à la réalité
🙂
@sdouche excellent complément. Il y a le recrutement pour un éditeur ou pour une SSII. La différence se ferait sur l’intégration avec l’équipe. Cependant Xebia par exemple propose aux nouveaux et futurs candidats de participer à leur journée XKE où l’ensemble des consultants se retrouvent pour des présentations et des échanges. Chez SFEIR aussi les futurs recrutés peuvent participer à des présentations je crois.
Merci pour ce test, je viens de le proposer à un postulant aujourd’hui !
Ca m’a permis de voir que la personne ne maîtrisait pas les fondamentaux. Quand on est bloqué sur l’écriture de concatenate() parce qu’on ne sait pas qu’un string est immutable, je pense que c’est révélateur…
Ce n’est pas le test ultime on est bien d’accord, mais ne pas le réussir c’est flagrant d’un manque d’expérience/connaissance.
Bien évidemment, toute personne qui a été ou est encore développeur et qui se retrouve à devoir recruter des développeurs ne pourra qu’être d’accord.
J’emettrai toutefois quelques bémols :
– La capacité à coder ne se limite pas à savoir *écrire* du code. La plupart du temps elle consiste à *lire* du code existant pour le modifier. Et ça fait quand même une différence non négligeable.
Pour reprendre l’analogie du musicien, si on veut vraiment recruter un bon, on va se mettre à jouer et il va nous accompagner.
– Je doute qu’un tel test puisse évaluer le nombre d’heures de vol en Java. Quelqu’un qui a fait, mis bout à bout, pas plus de 2 mois de java dans sa vie (au hasard : moi) n’aura pas de difficulté majeure pour arriver au bout (certainement pas en 2 minutes mais à coup sûr en moins de 20)
Pour ces raisons, je préfère des tests :
– où on va analyser du code existant plutôt qu’en écrire (et du coup je me contente de code sur papier, sans aucun ordi)
– où on introduira progressivement de la difficulté pour arriver sur des éléments du langage qui ne sont pas à la portée du premier venu.
N’ayant jamais été confronté à ce type de test, je l’ai fais en conditions réelles : 4 à 5mn ont effectivement suffit pour tout faire passer au vert. Je suis loin d’être un gourou java : j’ai du aller voir ce que voulais exactement dire « l’immutabilité d’une String ». Oui, on peut être développeur Java sans connaitre le JDK par coeur, les autodidactes ça existe ! Voilà typiquement le genre de questions où je me plante dans un QCM, mais qui ne m’a jamais posé problème en pratique.
Ce genre de test, cependant aurait pu me service lors de recrutement de personnes sur le CV, à déceler de grosses lacunes. D’autre part, même si une personne se gauffre en entretien, on voit au moins comment elle a cheminé tout au long de l’exercice. C’est le chemin qui est important, pas le résultat.
Pour ma part j’ai codé bourrin pour faire passer les tests, et ensuite j’ai refactoré. Je suis aussi allé voir d’autres exemples de concatenate sur le net pour améliorer le mien. Ca permet donc aussi de voir comment le candidat réagit face à une problématique et comment il s’améliore en continu (ya du lean là dessous !).
Je pense qu’un développeur peut ne pas savoir certaines choses qui pourraient sembler évidentes à d’autre (ah immutabilité !). Ce que je cherche ce sont des développeurs qui ont soif d’apprendre et qui ne se retrouvent pas bloqués à la première petite difficulté. Je préfère penser que l’expert WS, JPA, Spring, EJB, CDI, Swing, JNDI, RMI etc… n’existe pas et que si il existe il n’est pas dans mes moyens. Prenons donc des développeurs qui ont envie d’apprendre.
Ce qui m’a fait pencher pour un collaborateur dernièrement, c’est la réponse à la question : « Pourquoi aimeriez vous venir chez nous ? Parce qu’il y a plein de choses que je ne connais pas et que je veux découvrir ». Cette personne était opérationnelle en 2 semaines sur des technos qu’elle ne connaissait pas auparavant… et tout comme moi, ce n’est pas un gourou Java !
@Damien Le problème n’était pas en soit de connaitre la définition d’immutabilité, ni même de savoir qu’un string est immutable, mais plutôt de rester bloquer sur ça :
(...) result.substring(0, result.size()-1); return result;« Mais pourquoi mon string n’est pas modifié ?? »
@Thomas Ok, c’est vrai qu’en plus
return result.substring(0,result.size()-1);Même si j’aime vraiment pas utiliser ce genre de chose (substring) pour la fonction concatenate. Après avoir fait passer le test au vert, c’est justement le refactoring que j’ai fait. Une solution que j’ai trouvée plus élégante :
public static String concatenate(Iterable stringList) { Iterator stringListIterator = stringList.iterator(); StringBuffer sb = new StringBuffer(stringListIterator.next()); while(stringListIterator.hasNext()) { sb.append(',').append(stringListIterator.next()); } return sb.toString(); }Mais bon c’est vrai qu’un candidat qui sait sortir la bonne signature de fonction générique au premier coup passe déjà le test 😉
Ce que j’aime bien faire comme autre test avec un développeur est de lui donner une classe métier qui implémente une interface List ou Map et de voir comment il implémentes toutes les méthodes de l’interface. En gros se tape-t-il l’implémentation de toutes les méthodes une à une (à coup de copier/coller) ou fait il une façade avec une Map/List interne (qui peut être récupérée par des méthode privée fromMap(), toMap() ).
« Evitez d’utiliser un questionnaire pour sélectionner un candidat. Ils sont rarement en rapport avec ce que nous faisons sur le terrain. Ce n’est pas parce que je connais la différence entre une Hashtable et une HashMap que je suis un bon développeur. »
Malheureusement, c’est encore pratiqué par beaucoup trop (une majorité ?) d’entreprises. J’ai passé un entretien d’embauche il y a peu et les questions du recruteur ressemblaient à un QCM de certification portant uniquement sur des points de syntaxe du langage. Même ma grand-mère qui aurait appris par coeur la doc de la techno aurait décroché le job. Pas de questions ou d’évaluation sur des pratiques courantes du génie logiciel, refactoring, design patterns, tests unitaires ; pas un gramme de réflexion demandée sur la conception ou l’architecture du code… Ca fait un peu peur.
Et tout à fait d’accord avec Oaz pour dire qu’il ne suffit pas de tester la capacité du candidat à écrire du code, il faut aussi qu’il sache lire et comprendre du code existant et l’améliorer.
Un collègue qui faisait passer des entretiens de recrutement il y a quelques temps proposait aux candidats – en majorité des jeunes diplômés – des classes parsemées de code smells et leur demandait de les réécrire plus proprement. Beaucoup ne voyaient pas ce qui clochait (malheureusement on bourre souvent plus le crâne des étudiants de dogmes algorithmiques débiles qu’on ne leur apprend à produire un code clair et maintenable), mais on pouvait mesurer la marge de progression et la rapidité d’adaptation du candidat qui comprenait (ou pas) au fur et à mesure de l’exercice pourquoi c’était du code à refactorer.
À quoi sert de rendre la variable aTestList null dans le tearDown ?
@After
public void tearDown() {
aTestList = null;
}