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 !

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 !