I have taken many java interviews over the last few years. As time passed by, I learned from mistakes I have made. One of them being to ask candidates trick questions or questions that do not necessarily have an obvious answer.

I read a blog post recently that detailed such a question. I will highlight the question here along with the answer

public class JavaPuzzler{
    public static void main(String[] args) {
        HashSet<Short> s = new HashSet<Short>();//1
        for(short i = 0; i<100;i++){//2
            s.add(i);//3
            s.remove(i-1);//4
        }
        System.out.println(s.size());//5
    }
}

Can you guess the answer to this question ? Simply drag and select the text near the spoiler to see the answer.

Spoiler: The answer to the question is 100. The gotcha is that the statement s.remove(i-1); at //4 will autobox to an Integer and not a Short. Equals comparison between an Integer and Short fails.

This is a nice gotcha. One more to add to the collection of autobox/unbox gotchas . But by no means is this a fair interview question. The candidate may not know java 5 and this reduces the scope of the question. Debugging this problem is also quite difficult. Finding the bug is even more difficult without a debugger. Asking a programmer for the answer by giving him/her this question on a piece of paper is unfair.

I sometimes do ask questions that absolutely do not make sense. These are asked so that the candidate will (hopefully) call out my bull poop. For example I say something ridiculous like ‘But if the client can request for the JSP page, all he/she has to do is right click -> View source and they can see the JSP code….’. Most candidates stop me and say ‘huh ? are you kidding me ?’. Some go the distance and give me a stare. Others respond and say ‘Yeah. Perhaps we need to use SSL’. This question does help an interviewer know if the candidate knows what he/she is talking about or simply nods and tries to answer every question.

This question is however not intended for everyone. I ask this question to about 5% of the sample space, as a litmus test, only if I suspect that I am dealing with a bad apple. Asking the question to everyone would do some damage, since a good candidate may wonder ‘mmm… do I really want to work at a place where some one thinks this is possible ?’ and misintepret the question’s real intention.

When you interview some one for a DEV position, it is imperative that they write code and display problem solving skills. It is however not beneficial to the process if we add trick questions to the lot. It does not say anything about the candidate, whether or not they get the question right.

PS: The author of the blog that posted this question also agrees that it is not fair to ask it. I do hope we see less of it in interviews

I came across a post on the Adam Bien blog recently about using the prefix ‘Abstract‘ to define Abstract classes. The argument was that using the ‘Abstract‘ prefix is superfluous. I do not fully agree with the post. As I read the points he had mentioned on the post, here are some that came to mind

Abstract classes are already distinguishable by the keyword abstract. There is no need to further emphasize it.

A prefix “Abstract” doesn’t provide any additional value to the user – in contrary it blurs the actual intention

The Abstract in the class name helps a developer know that a class is Abstract even before they open it. Of course if some one bucks the convention and names a Concrete class abstract, it creates confusion but that scenario is rare.

Modern IDEs don’t let you instantiate an abstract class, even before saving / compiling.

The IDE would not let you instantiate the class whether or not the Abstract prefix is placed on the class name. If Abstract is used as a prefix, a developer would know before hand that the class is abstract.

If you really have to, it is easy to find / distinguish an abstract class with modern IDEs.

An IDE should be able to give you such a filter, but I wonder if it is a common feature across IDEs. I am not aware of a shortcut in eclipse that can do this (it might exist, I am just not aware of one). When I want to open an Abstract class, I type ctrl+shift+R and type ‘abstract’. That usually yields good results.

Even in UML class diagrams abstract classes are easy to distinguish – their name is italicized.

This is true. If you name your class AbstractSomething just because you want to distinguish them in UML diagrams, it is not justifiable.

So what good does an Abstract prefix do for a class ? Here is my opinion

1. Developers know a class is Abstract without opening it.
2. The name helps the developer realize that the class is meant to be inherited by a subclass, which will provide methods that the boiler plate does not.
3. Provides a developer one more way to search for Abstract classes.

In summary I would say that whether or not you want to use the Abstract prefix depends. Most boiler plate classes that you encounter (non abstract) use the word Default as a prefix. Example – DefaultContentHandler. Boiler plate code with some abstract methods use the word ‘Abstract’ as a prefix. Example – AbstractList. There are classes that do not follow the convention, but I would still vote for the word Abstract as a prefix because of the advantages that it presents.