Separating Advanced Java Programmers from Competent Ones: “Stump the Chump” Interview Questions Part 1

Having participated in a number of technical interviews and conducted others, I’ve noticed a pattern. About two thirds of the way through the interview, the interviewer will throw out a specific type of question, one that I’ve come to think of as a “stump the chump” question. This question will generally be fairly obscure in nature and the interviewee isn’t generally penalized for not knowing the answer. (At least it doesn’t appear to hurt the interviewee’s chances of getting hired. On the other hand, knowing the answer really impresses the interviewer.)

The purpose of the stump the chump question is to determine whether the interviewee is merely competent or really knows his or her stuff. What I’ve noticed about these questions though, is that it can give fairly good insight into what kinds of nasty, low-level problems the company’s alpha geeks have spent their time on. Here is a list of the stump the chump questions I’ve run across and what they relate to.

Q: When a Java object calls wait(), what happens to the mutex lock that it’s holding?
A: The mutex lock is silently released and the thread sleeps. When another thread acquires the lock and calls notify(), the lock is again silently released and, sometime later, is returned to the waiting thread. It is possible for a third thread to acquire the lock at any time that the lock is released. This behavior is implemented deep within the virtual machine and requires support from the underlying operating system. However, the code can confuse programmers because the lock is actually released for a time even though it is in a synchronized block. Consider the following code that implements a rudimentary blocking queue. (Please note: As of Java 1.5 a blocking queue is supplied in a standard API and you shouldn’t need to code your own in most cases.):

import java.util.LinkedList;

public class BlockingQueue {
private LinkedList items = new LinkedList();

public synchronized T getItem() {
while (items.isEmpty()) {
try {
this.wait();
}
catch (InterruptedException e) {
return null;
}
}

//TODO Check for race condiditon here.
T returnValue = items.getFirst();
items.remove(0);
return returnValue;
}

public synchronized void addItem(T newItem){
items.add(newItem);
this.notify();
}
}

Note that it isn't necessarily obvious that the lock is lost inside the synchronized block.

Q: What is an “old” object?
A: This question relates to the inner workings of the garbage collector (and most of the time you shouldn’t care). Basically, the designers of garbage collectors noticed that objects tended to have one of two lifespans: either very short (like variables declared in a fairly tight for loop), or very long (like members of a long-lived object). As such, when the garbage collector starts to recover memory that is no longer in use, it tends to start by examining the very short lived objects and not checking the long lived objects as often. Certain implementations divided the object lifespans into three groups but the effect was basically the same: objects that are still in use after enough iterations of the garbage collector are promoted from the "new" bucket to the "old" bucket and the collection of new objects is swept more frequently.

Q: What is a soft reference? How is it different from a weak reference?
A: This is another garbage collector question. The short answer is to compare it to a strong reference. A strong reference is any reference to a variable that can be accessed from any running thread. The garbage collector will never recover anything that is accessible through a strong reference. However, it may choose to recover objects that are only available through a soft reference. This can be useful when implementing things like caches where the information may be re-obtained or re-derived if needed but the garbage collector can still recover the memory if it’s about to run out. Weak references are references that are not available as either strong or soft references. The final type is a phantom reference. It refers to any object that has already been reclaimed by the garbage collector. Weak and phantom references are primarily useful for determining whether or not the garbage collector has started to reclaim an object. A far more detailed explanation of these reference types can be found here.

The final “stump the chump question will be posted as a separate entry because it involves a fair bit of background explanation.