Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Here are some questions I've recently asked interviewees who say they know Java concurrency:

  1. Explain the hazard of "memory visibility" - the way the JVM can reorder certain operations on variables that are unprotected by a monitor and not declared volatile, such that one thread may not see the changes made by another thread. Usually I ask this one by showing code where this hazard is present (e.g. the NoVisibility example in Listing 3.1 from "Java Concurrency in Practice" by Goetz et al) and asking what is wrong.
  2. Explain how volatile affects not just the actual variable declared volatile, but also any changes to variables made by a thread before it changes the volatile variable.
  3. Why might you use volatile instead of synchronized?
  4. Implement a condition variable with wait() and notifyAll(). Explain why you should use notifyAll(). Explain why the condition variable should be tested with a while loop.

My question is - are these appropriate or too advanced to ask someone who says they know Java concurrency?

And while we're at it, do you think that someone working in Java concurrency should be expected to have an above-average knowledge of Java garbage collection?

share|improve this question

closed as not constructive by gnat, Kilian Foth, Martijn Pieters, MichaelT, ChrisF Feb 21 '13 at 23:25

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

The only think I'd worry about is to avoid getting into the weeds of "memorized facts" rather than "skills". – tylerl Dec 7 '12 at 23:41
These questions seem perfectly reasonable for anyone being hired into a java position that will require high level of concurrency. – Rig Dec 8 '12 at 1:47
If you're hiring for a position that needs concurrent development, these are only the start. But I wonder how would you react if someone replied to your question about notifyAll() with "I don't believe in doing the work of the OS scheduler, so I use notify()" – kdgregory Dec 8 '12 at 12:47
I'd also be adding Q's about j.u.c Locks, data structures, Thread Pools and Unsafe :-) – Martijn Verburg Dec 8 '12 at 23:14
Others have spoken about the complexity of the questions. Assuming they're relevant to the project, make sure to lead up to them with some simpler question & abandon this line of questioning if it becomes obvious the candidate is out of their depth - it's a waste of their time & yours and ruins the energy of the interview. There's no point in asking questions you know they won't be able to answer. Make sure to be prepared to go into similar depth on other topics - just because somebody is weak here doesn't mean they're not competent & able to prove themselves through other strengths. – Sean McSomething Feb 21 '13 at 17:44
up vote 11 down vote accepted

It really depends whether you are asking a candidate with 2 years of Java experience or one with 7 years of Java experience. For an architect/technical lead/senior they seem proper questions but for a junior and maybe a mid-level too, they seem kind of difficult.

Also you are asking question about low-level synchronization mechanisms which have been replaced mostly by java.util.concurrent in current day Java development; instead of wait()/notify() locks are preferred. You can see that Effective Java 2nd edition has dropped a chapter that explained the wait/notify mechanism in detail, because it was not considered useful. Also, the container handles multithreading at a higher level in most cases; the methods of an EJB are thread-safe for example without any concern from the programmer (this does not mean that programmers should not know multithreading).

I actually see the multithreading are as a subpart of operating systems rather than a subpart of a programming language. In order to see whether a person truly understands multithreading and parallel programming questions about mutexes, semaphores or scheduling should be asked firstly and only eventually then, details about implementation in a particular programming language.

share|improve this answer
+1 on the wait() and notify() comments - however a developer well versed in concurrency would know the history and evolution of Java's capabilities in this space (including all the way up to F&J in Java 7). – Martijn Verburg Dec 8 '12 at 23:14
@M3th: The last person I asked these questions had 10 years of Java experience and claimed to know concurrent programming. Thanks for posting lock vs. wait/notify - I knew about lock from the Goetz book but didn't realize it was now preferred over the old way. I do agree with @Martijn though that someone with this level of experience should be aware of the older approaches. Anyway I don't mean to ask the question again (esp. since I've already marked it as answered - by you :-) ) but I would think someone with 10 years experience should be able to answer those questions, no? – sparc_spread Dec 9 '12 at 3:11
@Martijn Verburg I agree with you both; a good Java developer (especially one that says s/he knows concurrency) should know how to use wait()/notify(); at least for the curiosity on why they appear in the Object class. – m3th0dman Dec 9 '12 at 8:32
@sparc_spread A programmer that explicitly states in his/her resume that s/he knows Java concurrency should know the answers (at least the last 3). Regarding the experience level, as I said, imo a programmer that claims/wishes to be architect/technical lead\senior developer and has 5+ Java experience (backend, not JSP and MVC Frameworks) should know the answers. Regarding lock vs wait/notify, locks are preferred when you really need low-level features but in most cases a higher-level alternative is available; BlockingQueue is a specially useful one. – m3th0dman Dec 9 '12 at 8:39

Are these appropriate or too advanced to ask someone who says they know Java concurrency?

I'd say they are relatively advanced questions. However they are not "unfair" in the sense that they are not trick questions.

Indeed "fairness" is not really a relevant criterion. What you (as an interviewer) should be worrying about is whether the questions and your interpretation of the answers is selecting the best candidates for the position or positions you are interviewing for. (Or to put it another way, are you rejecting candidates that you should really be giving more consideration due to their not answering these questions "correctly"?)

And while we're at it, do you think that someone working in Java concurrency should be expected to have an above-average knowledge of Java garbage collection?

Again, that's not really the relevant question. The question you should be asking yourself is whether you need someone who has good knowledge of Java garbage collection.

share|improve this answer
Thanks very much for this response. I really wish I could have marked both as the answer. I appreciate the time you took to help here. – sparc_spread Dec 9 '12 at 3:07
You are welcome :-) – Stephen C Dec 9 '12 at 8:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.