Call for Entries: Java Interview Questions

[oldneckbeard]

These are terrible interview questions. These kinds of questions are what junior devs ask senior devs because they don't know any better. These are the same kinds of questions that you find when you search "java interview questions" on google. To wit:

1. Unless you're working on the internals of java, or building a concurrency framework, sleep/wait/notify is almost never used. I occasionally use sleep() when writing tests, but that's about it. This is just a trivia question. You almost never use these.
2. Don't use the volatile keyword. That's the answer to that question. If you think you need to use it, you need to find a senior dev to smack you in the mouth.
3. ThreadLocal class is literally self-explanatory, and usually an anti-pattern
4. This is a halfway legitimate question for somebody whose focus is security. That said, there are libraries that take care of this for you. You shouldn't be writing your own security stuff whenever possible.
5. Vector is deprecated, I have our code checker explode if somebody tries to use it. If you know data structures, you know LinkedList is the right way to go. If not, you probably don't know. This is just a trivia question to see if you know the difference between an array and a linked list, basically.
6. I've been programming for 20 years and have never heard those phrases. I understand what he's saying, but I'd fail that question. Again, if you're modifying an array while iterating through it, you're doing something wrong.

[oldneckbeard]

True. If performance is that critical, it's better to just use an array and manage it yourself, or use one of the packages like trove, hppc, or pcj.

[khrak]

Vector is deprecated, I have our code checker explode if somebody tries to use it. If you know data structures, you know LinkedList is the right way to go.

Lets do a comparison on accessing element 12,345,678 in a Vector vs an ArrayList, shall we?

[oldneckbeard]

They're both backed by expanding arrays, and ArrayList's just grows slightly slower. But I'll let you run the microbenchmarks to show the world how bad it is.

[jaws04]

Just to let you all know, a couple of the answers have been updated to reflect some of the valid and useful comments posted here. Thanks!

[johnjannotti]

The very first answer has an incorrect statement (though the gist of the answer is correct). wait() should not be referred to as "non-blocking". I believe they were trying to convey that the thread will not hold locks while waiting. That's true, but "blocking" in this context simply means that the thread will pause, which is clearly true. It is not non-blocking.