The Caffeinated Coder posted an interesting item today about a psychology study that shows that less competent people are generally over confident about their abilities by around 50%. Giggles about management aside, I've seen this bear out in my experiences. The study showed that the only way to make incompetent people understand that they didn't know what they were talking about was to educate them about the domain. Only then, did they truly understand how foolish they sounded.
This reminds me of something I look out for when interviewing Java developers. I have made it my business to get down deep and dirty on the nuances of the Singleton. I believe it is important for developers to do some sort of coding during the interview process. Typically I will stub out a class for candidates and ask them to fill in the rest:
public class SingletonTest {
// ... code goes here ...
public static void main(String[] args) {
// Your task, should you choose to accept it, is to make this line of code work
SingletonTest st = SingletonTest.getInstance();
}
}
Most folks know the Singleton. If they don't then I will explain it, but will probably not hire them because not knowing the GoF Design Patterns is a candidate smell to me.
After they have filled it in, I will ask questions along the lines of:
- Why is the constructor private, and not package or protected level access?
- What are some of the alternative ways of initializing the single instance?
- Is this class threadsafe?
- For a static class variable with an initializer (private static SingletonTest instance = new SingletonTest()), when does the object get created?
- If we make the constructor protected and extend the class with a new class SingletonTestPlusPlus and then call SingletonTestPlusPlus.getInstance(), what is the type of variable st in main - SingletonTest or SingletonTestPlusPlus?
- Trace the call stack with me at initialization time. Would SingletonTestPlusPlus's constructor be called before or after SingletonTest's?
Most people ace the code, and easily answer #1. I'm amazed how difficult #2 seems to be, but eventually people will figure out there is more than one way to initialize a class variable. By the time we get to #3 and #4 it starts thinning out pretty dramatically. I rarely get to #5 or #6.
The point of this exercise is not for the candidate to get everything right, but to see how they operate when they don't know an answer. My observation is that the more competent you are, the more intelligent a conversation you can have, and that is really what I'm looking for here. I like to see candidates who are on a voyage of discovery, buoyed by a passion for knowledge and personal improvement.
I certainly don't mind push back either - I think that is a good sign. You should not simply accept what anyone is telling you if it goes against everything you know and hold true. At the same time, you need to have an open mind and be willing to learn - that is the sign of a competent person.
One candidate I had called me out on the relevance of the Singleton and said he would write a Service Locator implementation instead. For the record, I think the Singleton is pretty much irrelevant in these days of Dependency Injection, but the candidate could not be convinced to write one in spite of my agreeing with him. That candidate was a "no hire".
Over the years I've had some interesting technical "discussions". No one has thrown a punch at me yet [1], but there has been some interesting and heated debates about the relative merits of lazy initialization over static initializers, or where the curly bracket should be, or double checked locking idioms, or why the main method in Java is so verbose. Reminds me of something my mother is fond of saying: "Ignorance is bliss". But then again, she was a teacher...
[1] I once worked with a project manager who got into a fight with a candidate during an interview and punches were thrown. Perhaps the fact that he was a pompous, self righteous, git had something to do with it.
Recent Comments