Java Interviews and trick questions
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
1 2 3 4 5 6 7 8 9 10 | 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 
Nice gotcha. When somebody will asked me for another gotcha on interview i’ll have counter question
While I doubt I would ask this question, I do occasionally ask questions where I think it’s unlikely that the interviewee knows the answer purely to see how they attack the problem, what things they try, and whether they can get to an answer they’ll stand behind. I don’t even care whether they get to the right answer – it’s the thinking methodology that is interesting.
@Ashitkin Alexander
I doubt the interviewer will let you counter question
@Alex Miller
I agree that the answer itself might not matter. Most trick questions usually have one tough answer which 99% will not get and there is no guarantee that the 1% that were filtered out are good programmers.
I don’t have a good enough memory to remember the signature for every method in every Java API to know whether it is taking an object or an index. My first desire would be to look at the Javadocs to truly understand what is going on in someone else’s code. When asked questions about APIs (common or not) that should be the answer.
Second, I prefer to know how someone solves a problem, not whether they understand every nuance of a language, or every class in an API even if it is just the Collections API (maybe in their domain they do not use HashSet very much). While the latter helps and experience is of value, the former (problem solving) is more important. Question about what pattern they would use (regardless of language), what the advantages/disadvantages are, what kind of interfaces they write, and so on, are often more useful than questions constructed by language lawyers any day. Other questions about dev processes (such as iterative methodologies, etc.) are also more valuable to get an idea of their philosophy and how it matches how your team works.
Of course, if you are interviewing interns or someone right out of college, these kinds or question *might* give you a gauge of their understanding of the language, but you probably can assume that already.
Also, of the many interviews I have been in over the decades for dev positions, only two have ever asked me how I would test a given solution (and those two were in the last year, which says something to me about the importance placed on TDD or even just testing period, despite all the lip service given to being committed to testing/quality.
Most interviews and interviewers for dev positions (and I assume other positions) just plain suck. They interviewers don’t know what question to ask (how the hell do I know where I see myself in 5 years? If I knew that I would be there already, and no I am not going to tell you my worst trait or weakest skill/etc. – you don’t really want to know, trust me and do you really expect me to tell you anyway – or to give you some pre-canned platitude?)
No, rather than test me with stupid problems – get to know me.
Amen to that
Are you trying to ask a trick question here or giving a trick answer because the code outputs a 100 and does not fail
@Sunil
Sorry I did not see your line where you gave the answer
I think this example was demonstrated by Josh Bloch at a Google Talk. I am pretty sure that unless the job is working on Java internals, expecting an explanation is probably asking too much.
I take back what I said about internals only, but I would probably accept the answer “why are you using a Short as a hash key” It is worthwhile to understand the problem but I would wager this is far less common than say a case like this: double x = (1 / 2) * 2.
@Steve
I was not aware that Josh demonstrated this as a gotcha.
@Sunil
No problemo.
Not for nothing, but on iteration 1, the code will add a zero but try to remove -1 which will fail, regardless of the key’s object type. If you change the remove line to be s.remove(i-0), it will be not be removed (due to casting). Of course s.remove((short)(i+)) will remove.
Yeah, I’ve been on those dreaded Java interviews too. Not much fun. Especially when the person asking a huge list of questions doesn’t want to do it and doesn’t really want you there. Sigh.
Rob
Oops (typo) …. s.remove((short)(i+0))
Whats the point of trick questions, Java/J2EE has become very complex, WebServices, web frameworks, Middle Tier frameworks Spring Vs EJB vs, ORM vs JDBC vs Store procedures.
And so on.
I think instead of trick questions and checking to see if developers know there API. Interviews should be on frameworks, why choose one against another. How you will design a application, what technology or frameworks will you use and why.
How will you handle caching. Persistence. Threading issues, design patterns you have used and why.
Also a good discussion on Java 5 what it brings to development what problems has it solved.
@Tony Cavanagh
I agree with you except for the framework bit. In case the person being interviewed and the interviewer do not know any frameworks in common, the discussion would not go anywhere. There are way too many frameworks out there for java too.
Nice trick. I request all of you to post this kind of interesting blogs.