David Kramer’s high-entropy blog

Two Java Phone Screen Questions

When I phone screen a Java candidate, I ask just two technical questions to assess their competency and give me a feel for where they are on the scale of “Heads-down coder” to “Java Software Engineer”.  In general, I try not to discount any candidate on just one factor, because we all have different weaknesses and strengths.  That’s why I consider these assessment questions instead of must-haves.

This is especially true of SQL questions in interviews.  I am way more interested in their thought process and how they come up with an SQL query than I am the query they respond with.  I’m not testing whether they have SQL syntax memories; I’m testing whether they understand how relational data can be joined and aggregated and filtered to produce the desired results.

Question 1:

Given the code

  1. String greeting = “Hello “;
  2. String name = “World”;
  3. greeting = greeting + recipient;

What is happening on line 3, and what will greeting be set to after it?

Answer 1:

Strings in Java are immutable.  They cannot change. However, String variables can point to different Strings at different times, or no String at all.  What happens on line 3 is a brand new String is created in memory with the concatenation of greeting and name (“Hello World”) and the String variable greeting will now hold a reference to that new string. The String “Hello ” is still in memory (unless it’s been garbage collected) but there’s no variable holding a reference to it.

  • If the candidate does not mention that Strings are immutable, they probably know very little practical Java.  I would not consider that candidate for more than a junior position, as this is such basic knowledge.
  • If they don’t understand that the variable greeting is not immutable, and can hold a reference to different immutable strings, they probably don’t have a good understanding of what’s going on under the covers.

Question 2:

If you are asked to create a LIFO (Last In First Out) stack (think of it like a stack of plates) that will grow and shrink a lot, and you are told to use just the base collection classes, would you choose LinkedList, or ArrayList?

Answer 2:

This question is definitely more advanced, and I would not exclude someone who gets it wrong unless you are looking for Principal Software Engineer or higher.

There are several reasons why LinkedList is the better solution.

  • The simplest answer is that the interface of LinkedList provides methods to add things to either end and take things off from either end, with no need for extra variables to point to the ends.  Not every developer has the APIs memorized, but conceptually linked lists are designed to grow and shrink.
  • The more advanced answer is that an ArrayList’s memory is allocated at a single fixed block of memory, so offsets to elements can be easily computed, while a LinkedList’s memory is allocated and freed in single-element blocks as they are added and removed.  But when an ArrayList grows past its allocated size (actually close to it), in order to expand, an entirely new block of memory is allocated, and every single element from the old memory block is copied into the new memory block, then the old memory block is freed.  This operation can take time to complete, and requires both blocks of memory to be allocated for a while.  Giving this answer requires a pretty deep understanding of how these collections work, and I would consider the candidate advanced based on this.



October 30th, 2015 Posted by | No comments
Categories: Employment, Java |

No Comments »

No comments yet.

Leave a comment

Site info