¿Son estas preguntas de entrevista avanzadas / injustas con respecto a la concurrencia de Java? [cerrado]

Aquí hay algunas preguntas que les hice recientemente a los entrevistados que dicen conocer la concurrencia de Java:

1. Explique el peligro de "visibilidad de la memoria": la forma en que la JVM puede reordenar ciertas operaciones en variables que no están protegidas por un monitor y no declaradas volatile, de modo que un subproceso puede no ver los cambios realizados por otro subproceso. Por lo general, le pregunto a este mostrando el código donde está presente este peligro (por NoVisibilityejemplo, el ejemplo en el Listado 3.1 de "Concurrencia de Java en la práctica" por Goetz et al) y preguntando qué está mal.
2. Explique cómo volatileafecta no solo la variable real declarada volatile, sino también cualquier cambio en las variables realizado por un hilo antes de que cambie la volatilevariable.
3. ¿Por qué podrías usar en volatilelugar de synchronized?
4. Implementar una variable de condición con wait()y notifyAll(). Explica por qué deberías usarlo notifyAll(). Explica por qué la variable de condición debe probarse con un whilebucle.

Mi pregunta es: ¿son apropiados o demasiado avanzados para preguntarle a alguien que dice que conoce la concurrencia de Java?

Y mientras lo hacemos, ¿crees que se debería esperar que alguien que trabaja en la concurrencia de Java tenga un conocimiento superior al promedio de la recolección de basura de Java?

Realmente depende de si está preguntando a un candidato con 2 años de experiencia en Java o uno con 7 años de experiencia en Java. Para un arquitecto / líder técnico / senior parecen preguntas apropiadas, pero para un junior y quizás un nivel medio también, parecen un poco difíciles.

También está haciendo preguntas sobre los mecanismos de sincronización de bajo nivel que han sido reemplazados principalmente por el java.util.concurrentdesarrollo actual de Java; en lugar de wait()/notify() cerraduras son preferibles. Puede ver que Effective Java 2nd edition ha dejado caer un capítulo que explica en detalle el mecanismo de espera / notificación, porque no se consideró útil. Además, el contenedor maneja subprocesos múltiples en un nivel superior en la mayoría de los casos; los métodos de un EJB son seguros para subprocesos, por ejemplo, sin ninguna preocupación por parte del programador (esto no significa que los programadores no deban conocer el subprocesamiento múltiple).

De hecho, veo que los subprocesos múltiples son una subparte de los sistemas operativos en lugar de una subparte de un lenguaje de programación. Para ver si una persona realmente comprende las preguntas de programación de subprocesos múltiples y paralelas sobre mutexes, se deben hacer primero los semáforos o la programación y, finalmente, solo después, detalles sobre la implementación en un lenguaje de programación particular.

¿Son apropiados o demasiado avanzados para preguntarle a alguien que dice conocer la concurrencia de Java?

Yo diría que son preguntas relativamente avanzadas. Sin embargo, no son "injustos" en el sentido de que no son preguntas capciosas.

De hecho, la "justicia" no es realmente un criterio relevante. Lo que usted (como entrevistador) debería preocuparse es si las preguntas y su interpretación de las respuestas seleccionan a los mejores candidatos para el puesto o los puestos para los que está entrevistando. (O para decirlo de otra manera, ¿está rechazando candidatos a los que realmente debería considerar más debido a que no responden estas preguntas "correctamente"?)

Y mientras lo hacemos, ¿crees que se debería esperar que alguien que trabaja en la concurrencia de Java tenga un conocimiento superior al promedio de la recolección de basura de Java?

Nuevamente, esa no es realmente la pregunta relevante. La pregunta que debe hacerse es si necesita a alguien que tenga un buen conocimiento de la recolección de basura de Java.