The line
s.remove(i-1);//4

converts “i-1″ to int. thus s.remove doestn removes anything frm the HashSet as it has Short not Integer.

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.

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

@Sunil
No problemo.

Java Interviews and trick questions…

Developer Dude :

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

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.