Howardism: Interview Questions

Interview Questions

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 know this.

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…

SELECT *
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.

Conclusion?

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:

Click here to submit this page to Stumble It


	Whence Jini? Java Not Fun? Freemarker vs. Velocity Loosely Coupled Components, Part 1 Computer Inspiration What's up with Java? Thoughtful Consideration better than any Pattern Why Not Use the Database? Perspectives on Struts Read other entries in Java...	Update I'm sorry, but I did forget to answer the question about the garbage collection. You'll probably find what you are looking for here. Improvements made in the GC in Version 1.4 are described here (and you can warp your brain here). Also, check out these lecture slides for an overview of this subject. By the way… a JVM doesn't have to have a garbage collector, but most of them do. —Howard Interview Questions 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 know this. 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… `SELECT * 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. Conclusion? 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:
	2014, Howard Abrams Some rights reserved	Originally written on 29 June 2004. Updated on 8 February 2014.