10 senior Java developer interview questions and answers

In this guide to senior Java developer interview questions, EPAM Anywhere’s Certified Java Technical Interviewer Gaetano Piazzolla shares his take on the top questions asked, along with sample answers and tips that can help you prepare for your senior Java developer interview.

ArrayList and LinkedList are one of the most used Java structures (since Java 1.2) for day-to-day development tasks. As a senior Java developer, you should be able to dig deep into understanding how these structures work and how they differ.

First of all, you should be aware that they both implement the List interface, an abstract structure built to maintain the ordering of the elements inserted. The main difference is that LinkedList additionally implements the Deque interface, so developers can use it as a standard FIFO-like structure.

The internals of the two collections differ a lot. While ArrayList is based on an auto-resizable array, LinkedList uses pointers to the next and previous elements, building a chain of elements to grant access to data. This means that choosing the correct structure depends on the use case, as the performance may vary greatly depending on this.

One of the best senior Java developer interview questions I’ve received in my years as a software developer was to implement an ArrayList and a LinkedList from scratch, using only standard Java primitives and no Java fancy collections. The best way to prepare for this question is to decompile the JDK code and see what's inside with your own eyes.

You can be sure that JDK has the best implementation for the Java language. Don’t focus only on what already-made structure is the best one for a specific task. Algorithms and data structures are the base of our job, so be prepared to dig deep into those.

I’ll uncover one of my favorite questions to ask during interviews, especially with experienced candidates who’ve probably used SOAP in legacy projects.

It’s possible to compare these two web service technologies from different angles. The theoretical differences, such as “SOAP is a protocol and REST is not,” while certainly interesting, do not have a lot of value when it comes to checking the real experience of a candidate. Something that is usually not mentioned during comparisons and that can help detect if the candidate has real experience with both, is the use of Web Service Definition Language (WSDL) files.

WSDL files are usually used to generate communication STUBs in Java. Is there any tool or technology that helps us do the same with REST endpoints? The answer is yes, and it’s called OpenAPI. Documenting web services is one of the most important things to do when providing functionality. Make sure you know how to document your APIs with both Rest and SOAP endpoints!

I still remember the early years of programming as a nightmare, when we used SVN in a team of 10 people. Using Git improved the game, but we all needed some experience with it. In the beginning, the lack of knowledge made it seem worse.

When it’s not possible to merge two branches because of conflicts, developers have two options: merging or rebasing. A rebase may be needed when reserving a clean Git history is important. Rebasing means to move the base of a branch on top of the leaf of another. Instead of having branches intersect multiple times, you can have a clean Git history, as long as everyone follows the golden rule of rebasing: never rebase a public branch.

Stashing is a powerful tool to put aside code that you just wrote, without pushing it to any remote tracked branch. While it’s possible to create multiple stashes at once by giving them different names, it’s usually better to not have more than one stash, as things can become complex to restore. Is there any difference between creating a local git branch and a git stash? Finding an answer can be a great exercise for candidates.

The testing pyramid is a concept that allows us to verify several levels of a candidate’s knowledge. Being able to identify all the layers (unit testing, integration testing, UI testing) should be enough for a junior developer, but for more experienced candidates, it’s better to make sure they have also implemented some of those using different tools or technologies.

Next to this pyramid, it is usually possible to place a second smaller structure composed of component, load or performance tests. Don’t forget to mention those as well to score extra points in your technical interview.

This is a tricky question, as the Set is by default an unordered structure. So the answer is simply no unless we use an additional data structure.

Starting from this question, it’s possible to:

1. Investigate the candidate's knowledge of Java collections. TreeSet, LinkedHashSet, and List are only some of the possible solutions.
2. Proceed further with HashSet's internal checks. Why do you think Sets are unordered? Why is it called a HASH set?
   

Exception hierarchy is must-have knowledge when it comes to using frameworks like Spring or Spring Boot. The vast majority of Java libraries define and document as precisely as possible an exception hierarchy for the various use cases solved.

This abstraction is useful in several ways: first, it’s possible to catch exceptions at various levels of the hierarchy, and second, it’s possible to further extend the family of exceptions with peculiar and ad-hoc use cases.

A further related question to ask regards the concept of “fault barriers,” which I encourage every senior Java developer to understand if they aren’t already familiar with the construct.

Typically, performance issues are reported by testers or users sometime after a feature has been shipped to production. Identifying the root cause of the issue can be difficult, so this is a good interview question for experienced candidates.

The first step in identifying and resolving a performance issue is measuring the actual performance of the behavior. Only then can an optimization make any sense, otherwise the enhancement cannot be measured.

Identification of the precise piece of the business logic to optimize may occur manually by inserting logs measuring time, or by using profiling tools that automatically decouple the various pieces of the flow measuring time spent in the execution.

When asked this senior Java developer interview question, experienced candidates may also want to describe one of the hardest performance issues they have faced, or trivial issues that can be easily avoided by adopting a series of good practices and keeping an eye on performance during the whole development lifecycle.

The candidate’s first reaction to this question should be, “Does it make sense to have huge data on Redis?” A distributed cache is built primarily to enhance the performance of a distributed microservice application. Together with the physical limit of the RAM available for the Redis host, there is a software limit on a single item of 512MB. To store a huge data load, we should be able to split it into chunks and retrieve results, for example by using the HGETALL command. Compression before storing the data might also be an option.

Generally speaking, Redis was not built to achieve this. Retrieving vast chunks of data has been indicated as one of the worst practices. A way better solution could be to store the data object in a standard NoSQL database.

The goal of this interview question is to check the previous experience of senior Java developer candidates, with a focus on how they propose new solutions instead of sticking to the plan.

Aspect-oriented programming (AOP) is a powerful feature implemented in the Spring framework. It enables developers to define transversal layers to the business logic of an application. Its most common use cases are logging, authorization, and caching.

The most common pitfall that the candidate should be aware of is the probable performance drop when using AOP, as it uses reflection under the hood, and Java reflection isn’t free (direct call to methods is way faster). This can make business logic a little difficult to read to someone who’s skilled in this way of programming.

The GET method in HTTP should be used only to retrieve resources from a web server, without altering the state of the application in any way. An exception to this is when we have caching. In this case, a slight modification to the state of the application might be tolerable.

Limitations of GET usually regard the fact that the method cannot theoretically have a request body, so every parameter should be included in the URL, and the URL has a limited length (~2K characters). In practice, it is possible to send a body with the GET method even if this is not a good practice and should be avoided.

With 2K characters available, we are certain to have all the input needed to retrieve a resource from a web server.

To get ready for your showdown, browse through our library of technical interview questions and take a look at the ultimate guide to technical interview questions shared by EPAM Anywhere’s technical interviewers. You might also want to practice your skills with some Java portfolio projects to showcase your technical proficiency.