Questions pour un entretien d’embauche
En ce moment, je fais passer quelques entretiens d’embauches (Software AG recrute pour Terracotta – si ca vous intéresse, pingez moi !). Ca m’intéresse de savoir comment d’autres font donc je vais expliquer comment je fais.
Je commence par le CV, j’ai souvent des gens qui ont plus de 15ans d’expériences donc je demande les 2 expériences les plus importantes pour eux et de les détailler (technos, nombre de personne dans l’équipe, challenges techniques/humains).
J’embraye sur des questions basiques sur les tests en fonction du cv du candidat :
- Différence entre JUnit et testNG et pourquoi on préfère l’un à l’autre
- Qu’est ce qu’un mock
- Qu’est ce qu’une Rules JUnit
- Quel est le moyen le plus simple de relancer n fois un test avec testNG ? Et sur plusieurs threads ?
- Quels frameworks de tests connaissez vous ? (culture G)
- Qu’est ce qu’un test paramétré (+ explications de la syntaxe) ?
Quelques basiques questions sur maven :
- Quels sont les différentes scopes ?
- Citer un plugin maven dédié au test ?
- Quelle est la différence entre maven et ant ?
- Comment activer un profile ?
Ensuite je passe sur la concurrence :
- Qu’est ce qu’une race condition ?
- Qu’est ce que volatile ?
- Est ce que ca garantit l’atomicité ?
- Qu’est ce que l’atomicité ?
- Comment marche l’intérieur de la ConcurrentHashMap ?
- Qu’est ce qu’une barrière ?
Culture G :
- Quel est le dernier livre technique que vous ayez lu ?
- Quel est votre livre technique préféré ?
J’aime bien aussi quand le candidat a un compte github.
Vu le poste, on veut des gens qui connaissent un minimum la concurrence (Java concurrency in practice est un très bon livre sur le sujet), un minimum de maven et un bon niveau de test.
Je continue jusqu’à ce que le candidat ne sache plus répondre pour chacun des 3 blocs. J’ai enlevé toutes les questions type SCJP, ca s’apparente trop à du bachotage. J’essaie de garder à peu près les memes questions pour pouvoir différencier les candidats.
Ensuite, on vient d’ajouter le kata sur les chiffres romains qu’on demande de mettre sur github pour voir si la personne sait effectivement coder. La dessus, je n’ai pas encore de retour mais j’espère bien que ca permettra de bien voir si la personne sait mettre en place un minimum de bonnes pratiques.
Et je recherche de nouvelles idées !
Et comment est ce que je sélectionne ?
Il est normal de ne pas tout savoir ! Avant toute chose, on essaie de voir surtout si le candidat réfléchit bien. C’est aussi utile pour moi de voir comment le candidat réagit quand il ne connait pas. Est-ce qu’il pipeaute, qu’il admet, qu’il tente un truc ? C’est surtout vrai pour les questions sur la concurrence et notamment la question sur la concurrent hashmap.
Les seuls points bloquants seraient une lacune complète sur les tests et sur maven. Sur la concurrence, je conseille en entretien de lire Concurrency in Practice. Et pour les lecteurs de ce blog,si vous n’avez qu’un temps réduit, il y a une refcard écrite par un ancien de terracotta sur DZone qui date un peu http://refcardz.dzone.com/refcardz/core-java-concurrency mais qui est claire. Pour postuler pour un job sur un cache distribué, maitriser un peu les concepts de concurrence c’est apprécié.
Merci à tous ceux qui m’ont aidé hier sur twitter !
Dans la section « Culture G » j’aime bien parler de communautés Java (« participez vous à des JUGs, conférences… »).
Pour voir comment un candidat réfléchit et comment il se comporte quand il ne connait pas, j’avais pour habitude de poser des questions à base d’un exemple de code pouvant contenir quelques subtilités.
J’en avais parlé dans un billet : http://agilitateur.azeau.com/post/2006/07/11/Dis-moi-comment-tu-codes-je-te-dirai-qui-tu-es
Après tu peux aussi aller un peu plus loin : j’ai une appli avec 1k threads, quelle implémentation de ConcurrentMap dois-je choisir ?
Sur la question de l’atomicité et de son lien avec volatile, la réponse est plus subtile qu’il y paraît. Tu peux prolonger la question : quid d’un long sur un processeur 32 bits par exemple.
Bizarre, tu poses beaucoup de questions sur des technos précises (testng notamment ), mais tu ne cités aucune question concernant la conception (design patterns).
De mon côté j’utilise beaucoup de questions « c’est quoi pour vous » et a la fin, tu peux mettre maven, Spring, jpa ou les technos qui t’intéressent, les réponses sont souvent très instructives.
poser des questions c’est bien, mais est ce suffisant ? Puisque tu recrutes pour un post de dev, pourquoi ne pas lui faire faire qq exo simples ?
Salut,
Questions tres orientées sur les techniques que tu utilises il semblerait.
* Pourquoi être maven centric ? un type qui maitrise gradle et peut expliquer pourquoi il le prefere n’est pas déconnant.
* Concurrence: on sent bien que tu cherche un lecteur assidu de java concurrency in practice… pourquoi pas, mais dans ce cas je prefere une reponse ou on parle de scabilité applicative et de design associé (ce qui rejoint la remarque de Brice). Car un design scalable sera plus important que la maitrise « low-level » de la concurrence (une fois que le type comprend ce que « visibilité veut dire, c’est largement suffisant de ce point de vue selon moi).
* Une question importante, cest de savoir si le type a un projet perso (est ce qu’il aime coder at home et sur quoi) => ca débouche sur des discussions super instructives à tout point de vue: en general on aime parler de ses projets persos et du coup on « cache » moins sa personnalité.
Voili voilo… feedback welcome.
Je trouve que cet article une belle source d’inspiration.
http://www.laurencegellert.com/2012/08/what-is-a-full-stack-developer/
Merci pour tous les commentaires !
Effectivement, les JUGs, confs et projets perso sont super important !
On fait coder le kata sur les chiffres romains pour la partie évaluation du code.
Après, le poste est assez spécifique donc le low level, c’est surtout ce qui est interessant.
Pour les questions ouvertes, oui c’est une bonne idée, mais j’ai toujours un peu peur de me faire pipeauter par un mec qui a lu wikipedia juste avant !
Bonjour,
Belle source d’inspiration, je suis en train de faire un site qui aide à la recherche d’emploi et potentiellement pour avoir plus d’idées sur les questions d’entretien (ayant cherché un emploi aux Etats Unis où il est impératif de bien savoir coder).
N’hésitez pas à poser vos questions d’entretiens sur :
https://www.vosentretiens.fr/
A bientôt
Grand merci pour ce billet, c’est très intéressant de voir un point de vue recruteur.
Pour ma part j’ai croisé en tant que candidat un certain nombre de recruteurs, j’ai un cv technique/fonctionnel avec une préférence sur la technique pourtant j’admet ne pas connaitre par coeur ces détails, on peut débattre sur le pourquoi, mais en gros en ayant conçu et écrit un volume de code que j’estime significatif, pourtant, je me pose toujours la question à savoir quel est le mieux au moment de commencer, plutôt que de partir sur des acquis peut-être obsolètes ou inadéquats dans le nouveau contexte.
En fait si j’étais recruteur, je privilégierais le candidat sortie du bac, qui veut tout apprendre, en lui laissant soin, et en l’aidant, de se former modulo les erreurs de jeunesse, plutôt que celui qui sortirait d’une grande école avec 2ans d’expérience, et qui arriverait avec tout un tas de vérités acquises sans forcément en avoir vérifié le fondement, et en les appliquant de façon presque dictatoriale.
Je le vois souvent, les collègues formés et expérimentés déduise des solutions pas forcément optimisées, le bon exemple, maven, la ou la boite faisait du ant.
D’expérience, j’ai vu du ant et du maven, les deux ont leurs avantages, je crois le plus important serait de savoir si le candidat sait faire un build tout court, c’est quoi un linkage en c, un .class, pourquoi fais t’on des jar, ear, war, etc….
Exemple, à quoi sert la commande java, quelles conditions doivent elles réunies pour faire tourner un programme java avec java -jar mon_programme.jar , sans autre arguments.
( c’est quoi un point d’entrée, le manifest, tout ça…)
Et pour la concurrence, vous pouvez demander ce qu’est un thread_local, ce n’est pas parce qu’un à jamais manipulés les threads qu’on serait mauvais dans cette technique de programmation.
Il peut y avoir des candidats qui n’auraient pas de grosse expérience en thread safe programming, est-ce un handicap.
Je ne crois pas tant qu’on reste ouvert et conscient de ce qu’est une allocation de ressource, et pourquoi un lock serait il dangereux sur un serveur de prod si mal géré.
Je ne sais pas pour vous, mais moi j’aurais orienté les questions sur le respect des pratiques de dev de la boite, et la sensibilité du candidat à la qualité de ce qu’il va produire, plus que sur ça façon de mémoriser des règles et pratiques de dev, qui ne va pas garantir que ce candidat respectera les autres développements et la qualité de l’application.
Peut-être aussi un exercice sur du merge de code.
Savoir utiliser les frameworks de tests, ok.
Mais je pense que le plus important est de demander qui doit tester, et quoi.
En gros, savoir si le candidat se responsabilise sur ce qu’il fait ou si il se dédouane sur d’autres services, en se cachant sur le fait que si son mock fait fonctionner son service en tests tout fonctionne.
Ce qui est inexact et laisse penser qu’on se fout de l’intégration.
Voila, j’espère que mon point de vue vous sera utile.
a+