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+

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

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 !

http://www.laurencegellert.com/2012/08/what-is-a-full-stack-developer/

Voili voilo… feedback welcome.