Sind diese fortgeschrittenen / unfairen Interviewfragen in Bezug auf Java-Parallelität? [geschlossen]

Hier sind einige Fragen, die ich kürzlich Befragten gestellt habe, die angeben, Java-Parallelität zu kennen:

Erläutern Sie die Gefahr der "Speichersichtbarkeit" - wie die JVM bestimmte Vorgänge für Variablen neu anordnen kann, die von einem Monitor ungeschützt und nicht deklariert sind volatile, sodass ein Thread möglicherweise die von einem anderen Thread vorgenommenen Änderungen nicht sieht. Normalerweise frage ich diesen Code, indem ich zeige, wo diese Gefahr vorliegt (z. B. das NoVisibilityBeispiel in Listing 3.1 aus "Java Concurrency in Practice" von Goetz et al.) Und frage, was falsch ist.
Erklären Sie, wie volatilesich dies nicht nur auf die tatsächlich deklarierte Variable auswirkt volatile, sondern auch auf alle Änderungen an Variablen, die von einem Thread vorgenommen wurden, bevor er die volatileVariable ändert .
Warum könnten Sie volatileanstelle von verwenden synchronized?
Implementieren Sie eine Bedingungsvariable mit wait()und notifyAll(). Erklären Sie, warum Sie verwenden sollten notifyAll(). Erklären Sie, warum die Bedingungsvariable mit einer whileSchleife getestet werden soll .

Meine Frage ist - sind diese angemessen oder zu fortgeschritten, um jemanden zu fragen, der sagt, er kenne die Java-Parallelität?

Und wenn wir schon dabei sind, sollte jemand, der in der Java-Parallelität arbeitet, überdurchschnittliche Kenntnisse über die Java-Garbage-Collection haben?

java interview concurrency

— sparc_spread
quelle

Der einzige Gedanke, über den ich mir Sorgen machen müsste, ist zu vermeiden, dass ich in das Unkraut der "auswendig gelernten Tatsachen" und nicht in "Fähigkeiten" gerate.

— tylerl

Diese Fragen erscheinen für jeden, der in eine Java-Position versetzt wird, die ein hohes Maß an Parallelität erfordert, völlig vernünftig.

— Rig

Wenn Sie eine Stelle suchen, die gleichzeitig weiterentwickelt werden muss, sind dies nur die ersten Schritte. Aber ich frage mich, wie Sie reagieren würden, wenn jemand auf Ihre Frage notifyAll()zu "Ich glaube nicht, dass ich die Arbeit des OS-Schedulers notify()

— erledige

Ich würde auch Q's über juc Locks, Datenstrukturen, Thread Pools und Unsafe hinzufügen :-)

— Martijn Verburg

Andere haben über die Komplexität der Fragen gesprochen. Nehmen Sie an, dass sie für das Projekt relevant sind, und stellen Sie sicher, dass Sie sich mit einer einfacheren Frage an sie wenden. Lassen Sie diese Frage, wenn sich herausstellt, dass der Kandidat überfordert ist des Interviews. Es hat keinen Sinn, Fragen zu stellen, von denen Sie wissen, dass sie nicht beantwortet werden können. Stellen Sie sicher, dass Sie darauf vorbereitet sind, sich mit ähnlichen Themen zu befassen - nur weil jemand hier schwach ist, heißt das nicht, dass er nicht kompetent ist und sich durch andere Stärken beweisen kann.

— Sean McSomething

Antworten:

Es hängt wirklich davon ab, ob Sie einen Kandidaten mit 2 Jahren Java-Erfahrung oder einen mit 7 Jahren Java-Erfahrung fragen. Für einen Architekten / technischen Leiter / Senior scheinen sie richtige Fragen zu sein, aber für einen Junior und vielleicht auch für einen Mittleren scheinen sie irgendwie schwierig zu sein.

Sie stellen auch Fragen zu Synchronisationsmechanismen auf niedriger Ebene, die java.util.concurrentin der heutigen Java-Entwicklung zum größten Teil durch solche ersetzt wurden. anstelle von wait()/notify() Schlössern werden bevorzugt. Sie sehen, dass Effective Java 2nd Edition ein Kapitel gelöscht hat, in dem der Wartemechanismus / Benachrichtigungsmechanismus ausführlich erläutert wurde, da er nicht als nützlich erachtet wurde. Außerdem kann der Container in den meisten Fällen Multithreading auf einer höheren Ebene ausführen. Die Methoden eines EJB sind zum Beispiel thread-sicher, ohne dass der Programmierer Bedenken hat (dies bedeutet nicht, dass Programmierer kein Multithreading kennen sollten).

Ich sehe das Multithreading tatsächlich als Teil von Betriebssystemen und nicht als Teil einer Programmiersprache. Um festzustellen, ob eine Person Multithreading- und parallele Programmierfragen zu Mutexen, Semaphoren oder Zeitplänen wirklich versteht, sollten zunächst und schließlich Einzelheiten zur Implementierung in einer bestimmten Programmiersprache abgefragt werden.

— m3th0dman
quelle

+1 bei den Kommentaren wait () und notify () - jedoch kennt ein Entwickler, der sich mit Parallelität auskennt, die Geschichte und die Entwicklung von Javas Fähigkeiten in diesem Bereich (einschließlich bis hin zu F & J in Java 7).

— Martijn Verburg

@ M3th: Die letzte Person, die ich diese Fragen stellte, hatte 10 Jahre Java-Erfahrung und behauptete, die gleichzeitige Programmierung zu kennen. Vielen Dank fürs Posten lockvs. wait/notify- Ich wusste es lockaus dem Goetz-Buch, wusste aber nicht, dass es jetzt dem alten vorgezogen wurde. Ich stimme @Martijn allerdings zu, dass jemand mit dieser Erfahrung die älteren Ansätze kennen sollte. Auf jeden Fall möchte ich die Frage nicht noch einmal stellen (zumal ich sie bereits als beantwortet markiert habe - von Ihnen :-)), aber ich denke, jemand mit 10 Jahren Erfahrung sollte in der Lage sein, diese Fragen zu beantworten, nein?

— sparc_spread

@Martijn Verburg Ich stimme Ihnen beiden zu. Ein guter Java-Entwickler (insbesondere einer, der Parallelität kennt) sollte wissen, wie man wait () / notify () benutzt. Zumindest aus Neugierde, warum sie in der Object-Klasse erscheinen.

— m3th0dman

@sparc_spread Ein Programmierer, der in seinem Lebenslauf ausdrücklich angibt, dass er mit Java-Parallelität vertraut ist, sollte die Antworten kennen (mindestens die letzten 3). Bezüglich des Erfahrungslevels sollte, wie ich bereits sagte, ein Programmierer, der behauptet / möchte, Architekt / technischer Leiter \ leitender Entwickler zu sein und über mehr als 5 Java-Erfahrung verfügt (Backend, nicht JSP- und MVC-Frameworks), die Antworten kennen. In Bezug auf lockvs wait/notifywerden Sperren bevorzugt, wenn Sie wirklich Funktionen auf niedriger Ebene benötigen, in den meisten Fällen jedoch eine Alternative auf höherer Ebene verfügbar ist. BlockingQueue ist besonders nützlich.

— m3th0dman

Sind diese angemessen oder zu fortgeschritten, um jemanden zu fragen, der angibt, Java-Parallelität zu kennen?

Ich würde sagen, es handelt sich um relativ fortgeschrittene Fragen. Sie sind jedoch nicht "unfair" in dem Sinne, dass sie keine Trickfragen sind.

In der Tat ist "Fairness" kein wirklich relevantes Kriterium. Was Sie (als Interviewer) befürchten sollten, ist, ob die Fragen und Ihre Interpretation der Antworten die Auswahl der besten Kandidaten für die Position oder die Positionen sind, für die Sie ein Interview führen. (Oder anders ausgedrückt, lehnen Sie Kandidaten ab, die Sie wirklich mehr berücksichtigen sollten, weil sie diese Fragen nicht "richtig" beantworten?)

Und wenn wir schon dabei sind, sollte jemand, der in der Java-Parallelität arbeitet, überdurchschnittliche Kenntnisse über die Java-Garbage-Collection haben?

Auch das ist nicht wirklich die relevante Frage. Die Frage, die Sie sich stellen sollten, ist, ob Sie jemanden benötigen , der über gute Kenntnisse der Java-Garbage-Collection verfügt.

— Stephen C
quelle

Vielen Dank für diese Antwort. Ich wünschte wirklich, ich hätte beides als Antwort markieren können. Ich schätze die Zeit, die Sie gebraucht haben, um hier zu helfen.

— sparc_spread