Ces questions d'entrevue avancées / injustes concernent-elles la concurrence Java? [fermé]

Dans l'état actuel des choses, cette question ne convient pas à notre format de questions / réponses. Nous nous attendons à ce que les réponses soient étayées par des faits, des références ou une expertise, mais cette question suscitera probablement un débat, des arguments, des sondages ou une discussion approfondie. Si vous pensez que cette question peut être améliorée et éventuellement rouverte, visitez le centre d'aide pour obtenir des conseils.

Fermé il y a 7 ans .

Voici quelques questions que j'ai récemment posées aux personnes interrogées qui disent connaître la concurrence Java:

Expliquez le danger de la «visibilité de la mémoire» - la façon dont la machine virtuelle Java peut réorganiser certaines opérations sur des variables qui ne sont pas protégées par un moniteur et non déclarées volatile, de sorte qu'un thread peut ne pas voir les modifications apportées par un autre thread. Habituellement, je demande à celui-ci en montrant le code où ce danger est présent (par NoVisibilityexemple l' exemple dans le Listing 3.1 de "Java Concurrency in Practice" par Goetz et al) et en demandant ce qui ne va pas.
Expliquez comment volatileaffecte non seulement la variable réelle déclarée volatile, mais également toutes les modifications apportées aux variables par un thread avant qu'il ne modifie la volatilevariable.
Pourquoi pourriez-vous utiliser à la volatileplace de synchronized?
Implémentez une variable de condition avec wait()et notifyAll(). Expliquez pourquoi vous devriez utiliser notifyAll(). Expliquez pourquoi la variable de condition doit être testée avec une whileboucle.

Ma question est - est-ce approprié ou trop avancé pour demander à quelqu'un qui dit qu'il connaît la concurrence Java?

Et pendant que nous y sommes, pensez-vous qu'une personne travaillant dans la concurrence Java devrait avoir une connaissance supérieure à la moyenne de la collecte des ordures Java?

java interview concurrency

— sparc_spread
source

La seule chose dont je m'inquiéterais, c'est d'éviter d'entrer dans les mauvaises herbes des «faits mémorisés» plutôt que des «compétences».

— tylerl

Ces questions semblent parfaitement raisonnables pour quiconque est embauché dans un poste java qui nécessitera un niveau élevé de simultanéité.

— Rig

Si vous embauchez pour un poste qui nécessite un développement simultané, ce n'est que le début. Mais je me demande comment réagiriez-vous si quelqu'un répondait à votre question à propos notifyAll()de "Je ne crois pas au travail du planificateur du système d'exploitation, donc j'utilise notify()"

— kdgregory

J'ajouterais également des questions sur les verrous juc, les structures de données, les pools de threads et les dangereux :-)

— Martijn Verburg

D'autres ont parlé de la complexité des questions. En supposant qu'ils sont pertinents pour le projet, assurez-vous de les aborder avec une question plus simple et d'abandonner cette ligne de question s'il devient évident que le candidat est hors de sa profondeur - c'est une perte de temps et la vôtre et ruine l'énergie de l'entretien. Il est inutile de poser des questions auxquelles vous savez qu'ils ne pourront pas répondre. Assurez-vous d'être prêt à approfondir de manière similaire sur d'autres sujets - ce n'est pas parce que quelqu'un est faible ici qu'il n'est pas compétent et capable de faire ses preuves à travers d'autres points forts.

— Sean McSomething

Réponses:

Cela dépend vraiment si vous demandez un candidat avec 2 ans d'expérience Java ou un avec 7 ans d'expérience Java. Pour un architecte / responsable technique / senior, elles semblent des questions appropriées, mais pour un junior et peut-être aussi un niveau intermédiaire, elles semblent plutôt difficiles.

Vous posez également des questions sur les mécanismes de synchronisation de bas niveau qui ont été remplacés principalement par le java.util.concurrentdéveloppement Java actuel; au lieu des wait()/notify() verrous sont préférés. Vous pouvez voir que Effective Java 2nd edition a supprimé un chapitre qui explique le mécanisme d'attente / notification en détail, car il n'a pas été jugé utile. En outre, le conteneur gère le multithreading à un niveau supérieur dans la plupart des cas; les méthodes d'un EJB sont thread-safe par exemple sans aucune préoccupation du programmeur (cela ne signifie pas que les programmeurs ne devraient pas savoir le multithreading).

En fait, je vois que le multithreading est une sous-partie des systèmes d'exploitation plutôt qu'une sous-partie d'un langage de programmation. Afin de voir si une personne comprend vraiment les questions de programmation multithreading et parallèle sur les mutex, les sémaphores ou la programmation, il convient de se poser d'abord et seulement ensuite, des détails sur l'implémentation dans un langage de programmation particulier.

— m3th0dman
source

+1 sur les commentaires wait () et notify () - cependant un développeur connaissant bien la concurrence connaîtrait l'histoire et l'évolution des capacités de Java dans cet espace (y compris jusqu'à F&J dans Java 7).

— Martijn Verburg

@ M3th: La dernière personne à qui j'ai posé ces questions avait 10 ans d'expérience Java et prétendait connaître la programmation simultanée. Merci d'avoir posté lockcontre wait/notify- je savais à propos lockdu livre de Goetz mais je ne savais pas que c'était maintenant préféré à l'ancienne. Je suis d'accord avec @Martijn, cependant, une personne ayant ce niveau d'expérience devrait être au courant des anciennes approches. Quoi qu'il en soit, je ne veux pas poser la question à nouveau (surtout que je l'ai déjà marqué comme ayant été répondu - par vous :-)) mais je pense que quelqu'un avec 10 ans d'expérience devrait être en mesure de répondre à ces questions, non?

— sparc_spread

@Martijn Verburg Je suis d'accord avec vous deux; un bon développeur Java (en particulier celui qui dit qu'il connaît la concurrence) doit savoir comment utiliser wait () / notify (); au moins pour la curiosité de savoir pourquoi ils apparaissent dans la classe d'objets.

— m3th0dman

@sparc_spread Un programmeur qui déclare explicitement dans son curriculum vitae qu'il connaît la concurrence Java doit connaître les réponses (au moins les 3 dernières). En ce qui concerne le niveau d'expérience, comme je l'ai dit, un programmeur qui prétend / souhaite être architecte / responsable technique \ développeur senior et a 5+ expérience Java (backend, pas JSP et MVC Frameworks) devrait connaître les réponses. En ce qui concerne lockvs wait/notify, les verrous sont préférés lorsque vous avez vraiment besoin de fonctionnalités de bas niveau, mais dans la plupart des cas, une alternative de niveau supérieur est disponible; BlockingQueue est particulièrement utile.

— m3th0dman

Est-ce approprié ou trop avancé pour demander à quelqu'un qui dit connaître la concurrence Java?

Je dirais que ce sont des questions relativement avancées. Cependant, ils ne sont pas "injustes" dans le sens où ce ne sont pas des questions pièges.

En effet, "l'équité" n'est pas vraiment un critère pertinent. Ce que vous (en tant qu'enquêteur) devriez vous inquiéter, c'est de savoir si les questions et votre interprétation des réponses sélectionnent les meilleurs candidats pour le ou les postes pour lesquels vous interrogez. (Ou pour le dire autrement, rejetez-vous des candidats que vous devriez vraiment accorder plus d'attention car ils ne répondent pas «correctement» à ces questions?)

Et pendant que nous y sommes, pensez-vous qu'une personne travaillant dans la concurrence Java devrait avoir une connaissance supérieure à la moyenne de la collecte des ordures Java?

Encore une fois, ce n'est pas vraiment la question pertinente. La question que vous devriez vous poser est de savoir si vous avez besoin de quelqu'un qui a une bonne connaissance de la collecte des ordures Java.

— Stephen C
source

Merci beaucoup pour cette réponse. Je souhaite vraiment que j'aurais pu marquer les deux comme réponse. J'apprécie le temps que vous avez pris pour aider ici.

— sparc_spread