12

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?

Improve this question
8
  • 4
    The only think I'd worry about is to avoid getting into the weeds of "memorized facts" rather than "skills". Commented Dec 7, 2012 at 23:41
  • 5
    These questions seem perfectly reasonable for anyone being hired into a java position that will require high level of concurrency. Commented Dec 8, 2012 at 1:47
  • 2
    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()" Commented Dec 8, 2012 at 12:47
  • 2
    I'd also be adding Q's about j.u.c Locks, data structures, Thread Pools and Unsafe :-) Commented Dec 8, 2012 at 23:14
  • 2
    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. Commented Feb 21, 2013 at 17:44

2 Answers 2

Reset to default
11

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.

Improve this answer
4
  • 2
    +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). Commented Dec 8, 2012 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? Commented Dec 9, 2012 at 3:11
  • 1
    @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. Commented Dec 9, 2012 at 8:32
  • 1
    @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. Commented Dec 9, 2012 at 8:39
13

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.

Improve this answer
1
  • 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. Commented Dec 9, 2012 at 3:07

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.