Java Interview Questions and Answers: 8 Worked Examples

String immutability, junior engineer (first job) (148 words)

A String's value cannot change after it is created. The Java documentation says it directly: "Strings are constant; their values cannot be changed after they are created." When I call toUpperCase() or concat(), I get a new String back and the original stays the same.

That matters for three reasons. First, strings can be shared safely, which is why the JVM keeps a pool of string literals, so "abc" written twice in my code points to one object. Second, strings are safe to use as HashMap keys, because the hash code cannot change after the key goes in. Third, they are thread-safe without locking.

The cost is that building a string in a loop with + creates many objects. In my capstone project I had a report builder doing that over 50,000 rows, and switching to StringBuilder cut the run from about 4 seconds to under 1.

== versus equals, junior engineer (bootcamp graduate) (124 words)

== compares references: whether two variables point to the same object. equals() compares content, if the class overrides it. For String, the documentation says equals returns true "if and only if the argument is not null and is a String object that represents the same sequence of characters as this object."

So new String("cat") == "cat" is false, because they are two objects, but new String("cat").equals("cat") is true.

I hit this in a bootcamp project where a login check used == to compare a password string read from a form. It worked in my tests with literals and failed with real input. Since then I always use equals for content, and Objects.equals(a, b) when either side might be null.

HashMap internals, experienced engineer (five years, backend) (173 words)

A HashMap stores entries in an array of buckets. On put, it calls hashCode() on the key, spreads the bits, and uses the result to pick a bucket. If two keys land in the same bucket, they are chained, and since Java 8 a long chain is turned into a balanced tree. On get, it finds the bucket the same way and uses equals() to find the exact key.

The documentation promises "constant-time performance for the basic operations (get and put), assuming the hash function disperses the elements properly among the buckets." That assumption is the important part. When the map passes its load factor, 0.75 by default, it doubles the array and rehashes everything.

Two practical points from my work. We had a cache keyed on an object with a hashCode that returned the same value for most keys, and lookups degraded badly under load until we fixed the hash. And HashMap is not thread-safe: the documentation says it is "unsynchronized and permits nulls", so for shared state we use ConcurrentHashMap.

equals and hashCode contract, experienced engineer (three years) (119 words)

Because hash-based collections use hashCode to find the bucket first, and equals only within that bucket. If two objects are equal but have different hash codes, a HashSet can store both, and a HashMap get can miss a key that is really there.

The rule is: equal objects must have equal hash codes. Unequal objects may share a hash code, but performance suffers if many do.

On my last team, a Customer class overrode equals on the customer ID but not hashCode. Deduplicating a list with a HashSet left duplicates, and it took a day to find. Now I generate both together, or use a record in Java 16 and later, which gives me both from the fields automatically.

Interface versus abstract class, junior engineer (internship) (119 words)

An interface defines what a class can do, without saying how. Oracle's tutorial describes it as "a group of related methods with empty bodies" in its most common form, and says interfaces "form a contract between the class and the outside world". A class can implement many interfaces.

An abstract class can hold state and shared code, and a class can extend only one. Since Java 8, interfaces can have default methods, so the line is less sharp, but interfaces still cannot have instance fields.

In my internship I used an interface, PaymentProvider, with two implementations for two payment gateways. The checkout code only knew about the interface, so adding the second gateway did not touch checkout at all.

Exceptions, experienced engineer (service layer design) (118 words)

Checked exceptions extend Exception and the compiler forces you to catch or declare them. IOException is the usual example. Unchecked exceptions extend RuntimeException, like NullPointerException or IllegalArgumentException, and the compiler does not force handling.

My rule is: checked for conditions the caller can reasonably recover from, unchecked for programming errors. In our order service we wrapped a checked SQLException from the repository layer into our own unchecked DataAccessException, so the business layer was not full of try-catch blocks it could do nothing with, and one handler at the API edge turned it into a 503 with a log entry.

What I avoid: catching Exception and doing nothing. We found one of those hiding failed refunds for two weeks.

volatile, experienced engineer (concurrency) (82 words)

volatile guarantees visibility: when one thread writes a volatile variable, other threads see the new value, instead of a cached copy. It does not make compound actions atomic, so count++ on a volatile int is still a race.

I use it for simple flags, such as a running boolean that a shutdown hook sets to false and a worker loop reads. For counters I use AtomicInteger, and for anything with several fields that must change together I use a lock or synchronized.

Project question, junior engineer (career changer from QA) (126 words)

I spent three years in manual QA before moving into engineering. The project I am proudest of is a small Spring Boot service I wrote for my QA team that pulled failed test runs from our CI server every night and grouped them by stack trace.

Before that, two of us spent the first hour of every day reading logs. The service cut that to about ten minutes, and it found that two in five of our failures came from one flaky test environment, which the infrastructure team then fixed.

It taught me to write for the people using the tool: the first version had a beautiful API nobody used, the second sent a plain email at 7am, and that is the one the team kept.