Many years old, while sitting in a job interview, the interviewer asked me
to describe the garbage collection algorithm for Java. I just happened to
have attended a seminar on the changes in Java 1.2 the week before,
with significant discussion on the changes made to the garbage collector.
Needless to say, I really impressed him (or snowed him, depending on
the view), and he offered me a job.
We've all had some person try to gage your technical chops.
These questions come in various flavors:
- General questions, which you should know if you put the acronym on your resume, but don't help much in ascertaining virtuosity.
- Obscure references that make you roll our eyes. "Please explain the chip-on-the-shoulder and the something-to-prove design patterns."
- Clever algorithms that you wish could effortlessly regurgitate. If you want to make me look foolish, ask me some variation on the dropping glass balls from a tower. I just don't have that sort of acumen, but I don't work that way, either.
- Thought-provoking questions that invite spirited discussions. If you are trying to determine if you can work with someone, ask these questions.
Over the years, I seem to be asked the same questions in every
interview. So I thought I would publish the answers here.
Note: In case I am the one doing the interviewing, and you are smart
enough to find this page before the interview, then you are probably smart
enough for me to hire you.
In Java, what is the difference between a abstract class and an interface?
While you can't instantiate either one, this is where the similarity ends,
and it is probably this reason why people ask it.
An abstract class is marked abstract because you want a class that
contains methods that can only be used by children classes that extend it
(and supposedly add some remaining ingredients to make the class valid).
This allows a class to contain code, but can't be instantiated (for
whatever reason you need).
An interface, on the other hand, is really an API contract. It contains no
code, just the list of methods that any class claiming to implement it
needs to create.
These two things have such a different semantic meaning that I was
surprised the first time I heard it. But it has been asked in every one of
my screening interviews. As a design note, if you are building a library,
make your users implement an interface instead of extending one of your
classes, since Java doesn't do multiple inheritance, it is mean to use up a
user's one chance at extension.
In Java, what is the difference between Collection classes (added in version 1.2) and the Hashtable/Vector classes (in version 1.0)?
While the Collection classes create a better model for dealing with
data structures, the biggest difference is that the Hashtable and Vector
classes are synchronized and the Collection classes are not.
What this means is that every interaction with a Vector has a slight
performance hit as it needs to acquire a lock on the underlying data. Yes,
it is slight, but with 99% of the uses of data structures, it is
unnecessary. What this means if you share data structures between multiple
running threads, you either use the Vector/Hashtable or you do your own
locking with the Collection classes.
In SQL, what is the difference between an inner and outer join?
I'm not an SQL-wiz, but have used both types of joins, but didn't know them
by these names (ok, I'll admit that I'm an SQL hack). Still, it is good to
An inner join is your typical join where your result set lists only the
matching rows in both tables. An outer join will list all of the rows
from one table (whether they match or not), so in this join, the order of
the tables is important. This is often called a "left" join…
FROM clients LEFT JOIN orders
WHERE clients.id = orders.clientid
In this example, all of the clients are listed, whether or not they have an
order. If you replaced "LEFT JOIN" with a simple comma (for a typical inner
join), then only customers that have an order will be listed.
In Java, what is the difference between the IO streams and the Reader/Writer classes?
The biggest difference (aside from some minor interface changes and being
slightly more efficient) is that the Reader/Writer classes (or Character
Streams) can deal with differences in character encodings (multibyte
characters like Unicode) and do not assume that a single byte is equal to a
character (as some of the Stream classes do).
See Sun's documentation on I/O.
The original classes that supposedly dealt with characters (but really
didn't) have been deprecated. But if you need to deal with byte-oriented
data, then you can still use them.
One of my irritations with Java is the fact that while you can upgrade the
API and deprecate older/badder classes, the entire library needs to be
upgraded as well. It is painful to have a "Reader" but can't pass it over
to another class library that only accepts "Stream" classes. (Streams can
be converted up to a Reader/Writer, but the reverse is not possible).
General Knowledge Questions
Looking for more questions? Well, there are a number of "general purpose"
questions about Java that everyone should be able to ask. For instance:
- When is the
finalize() method called? Just before the instantiated object is garbage collected (read these details).
Never depend on
finalize since it isn't guaranteed to ever be called.
- What is the default access modifier for a class? Package … meaning that only classes in the same package can access it.
- What is the default access modifier for an interface? Public … meaning that any other class can implement it.
I can't believe that in one interview I was asked to pseudo-code a
doubly-linked list data structure… Are you kidding me? I suppose we could
still ask juniors this, but while I can still do these in my sleep, it is
almost always better to use a standard library that has been debugged and
optimized than "roll yer own."
Of course, you could have heard my jaw smack the floor when I was asked to
write out the code for walking a binary tree… in SQL!
Update: I've changed my opinion on this paragraph since I wrote
it eight years ago. I regularly meet engineers, fresh out of
college, only knowing Java, and clueless about how the underlying
library works. While you should probably use the library's sort
routines, you should understand how it works.
A collegue of mine, while interviewing engineers in China was amazed
that none of them could implement a merge sort. I responded that
sorting isn't important in a land without a specific word order, and
that perhaps a hashing algorithm might more applicable.
Oh, and I hope nobody asks me any combinatorics questions, for I've
certainly flushed those brain cells away years ago.
Tell others about this article: