8 Java developer interview questions and answers

The following guide is based on the roundtable with the participation of EPAM’s Alexander Shvarz, Software Engineering Team Leader; Roman Gordiienko, Solution Architect II; Tair Mustafaiev, Solution Architect I; and Arkadii Suslo, Software Engineering Manager.

For Java and other software engineers, one of the core parts of the interview process at EPAM Anywhere is the technical interview. Before diving into the depths of Java interview questions, our candidates complete:

• Profile pre-screening, which includes application review and online tests with algorithmic and logical tasks designed to test certain core skills required for the position.
• General interview, which is typically a video intro call with a talent acquisition specialist. Candidates have an opportunity to introduce themselves, share details about their previous experience, tasks, the technologies and kind of project they're most interested in working with.

Based on this information, the interviewer selects questions for the technical interview. You may be asked Java concurrency interview questions, Java multithreading interview questions, and Java collections interview questions, among other topics.

Along with the questions, the interviewer will want to learn more about your experience with frameworks and tools — both in theory and by providing a practical task for you to resolve, which will take you no longer than 15-20 minutes. In total, a technical interview for Java software engineers takes up to 1.5 hours.

You should also know that another area the interviewer will cover during the conversation is an assessment of your problem-solving and other key soft skills.

Below, we'll take a closer look at real-life interview questions that you may come across at companies hiring Java developers.

For starters, you might be asked to describe the differences between interfaces and classes. While this question may sound trivial, candidates don't always get to its core. Many respond that an interface has a contract or a method signature, while a class allows you to make the implementation of these methods. They suggest that this is the difference: interfaces don't contain implementation, while classes, at least partially, do. If that is the response, the interviewer may ask: Is that true for Java 8?

Java 8 includes a new feature — default methods. So an interface can now include not only a contract, but also some kind of implementation. This blurs the distinction between these two Java structures. In response, candidates often say that a difference still remains because we can extend only one abstract class but we can implement many interfaces. This leads to our next point.

Candidates discussing the differences between an interface and a class frequently say that one has multi-implementation opportunities, while the other doesn't. In practical terms, this is not so much a difference, as it is a consequence, or a manifestation of an underlying difference between the concepts. That key difference relates to… state.

The bottom line is that the key conceptual difference between interfaces and classes is that a class (even an abstract one) has a state, while an interface doesn’t. Here you can see this difference:

OOPs interface vs. abstract class

Once this question is covered, the interviewer may lead core Java interview questions towards the diamond problem.

Originally, in Java we didn't have multi-inheritance so we didn’t face the diamond problem. With the emergence of default methods, the diamond problem may arise. Candidates may be asked what will happen if we have two unrelated interfaces that have a default method with the same signature and different implementation, and we want to implement these two interfaces in a class. Then, they will be asked how to solve this problem.

If a candidate has a good understanding of how Java works, they will understand that the problem will arise at the compilation level, and will return a compilation error. One solution is to override this method in the class. Another option is to use composition: if you have one class that implements one interface, you can try to represent it as an inner class inside of another class.

The next question that may arise concerns default methods in Java and is: why was this concept included in Java? The answer has its roots in the concept of backward compatibility in Java 8. The ability to enable default methods in the interface is the feature that helped Java maintain backward compatibility.

If the candidate discussion reaches this point, the last question that can be posed is whether default methods of the interface can override some methods of the Object class, and why not.

If we create a default method with the same signature as, for example, equals in the Object class, then we'll change the class's behavior, which is inherited from another class. This violates the basic principle that distinguishes interfaces and classes.

These theoretical questions are designed to cover the fundamentals and are asked in order of their complexity. Hence, an interviewer will move step by step from basic to complicated Java senior interview questions.

If a relational database already contains non-unique data, and there's no way to implement constraints, the interviewer may ask a candidate to suggest a way to find duplicates by using SQL.

At the service level, there's a task to address this. Specifically, the interviewer may suggest the following additional conditions: there's a task to add one column (e.g. the city population size) and rename another (e.g. the specific province where this city is located).

At this point, the interviewer is evaluating the candidate’s ability to work with the database in a backward-compatible way. A candidate lacking experience in the migration of databases and schemes is likely to simply rename or add a column. Doing so will cause issues with compatibility, since the renamed column won't be accessible to the older version of the application. The candidate will be asked to come up with a recovery plan. An expected answer here: if you want to rename something, add a new column and keep the old one for several versions in a row, after which you can delete it.

Similarly, if we add a new column, we don't delete these updates if we need to roll back to the previous version, since we need to return to the later version of the application at some point.

A candidate might also be asked to design tables to store the inheritance structure, like a person as a student and professor. Some of the fields are the same, some differ. There are multiple ways to handle that, each having its pros and cons. In brief, you can either have one table with a discriminator, or multiple tables.

The interviewer may ask you to identify the general characteristics and basic principles embedded in microservices. Also, a candidate may be asked to share their previous experience with microservices, and their opinions about the pros and cons of this concept. The interviewer will want to know how well a candidate understands the importance of each advantage and disadvantage and how microservices differ from a monolithic architecture.

The pros to mention:

• Microservices architecture is highly scalable, in a flexible way.
• It is easy to understand.
• It helps to avoid fault isolation.
• It ensures fast recovery in case of the right design and use of orchestration.
• It offers faster deployment if CD is well-set and fine-tuned.

The cons to mention:

• There is complex communication between services (requiring an HTTP code, a queue, etc.).
• More services require more resources.
• Debugging and end-to-end testing are more complex in microservices.
• Deployment might be challenging if the team is not quite mature in terms of DevOps practices, and can't set up the CD process properly.

Another important area of knowledge regarding microservices is patterns. It's helpful if a candidate can go beyond API Gateway and Circuit Breaker and cover more patterns related to microservices architecture.

Patterns fall into different categories: decomposition patterns (decomposing monolith into microservices), patterns that enable integration between services, database-related patterns, patterns for transactions, observability of microservice states, and more.

Senior candidates are also expected to demonstrate at least a general understanding of logging, monitoring, and alerting. A few essential aspects include:

• Logging: tools, ELK and Splunk stacks, how logging aggregation works, and how it's implemented in general.
• Monitoring: here, the interviewer expects to hear about automation, capturing and measuring various metrics (e.g. latency requests, open tracing), possible bottlenecks, and ways to address them quickly and efficiently.
• Alerting: regarding this pattern, which relates to monitoring, it's important to talk about automation, tools, and how to implement alerting.

The goal here is to evaluate:

• Logic and way of thinking
• Complexity of suggested solutions
• Ability to make intuitive decisions
• Knowledge of data structures

Here's an example of a task:

• There is a Pojo class.
• It has two fields: value and length, as well as getters and setters.
• Getters and setters for the second field are commented.
• We need to use this entity as a key in the HashMap.
• Also, using it we need to save Integer Object.
• For Pojo we setValue "abc" and record it to the HashMap.
• Then, setLength and try to return it.

Question: what will be returned as a result?

This question is quite simple but extensive. Candidates of any seniority level will find something to offer as an answer.

Candidates frequently think that the answer to this task is "1". Their argument: hashcode equals is not overridden and will be used from the basic class, Object, which doesn't have mentioned fields. In response to this answer, the interviewer may ask: how can we change the Pojo class so that this code works for us on the client-side?

Most candidates suggest defining equals and hashcode. Once we have defined equals and hashcode, we will always get "null". Null will be returned just because we changed the Length and an Object is mutable.

Though it's not a difficult question, some candidates need to iterate over the code, go through all the points, calculate, and see that hashcode will get modified and we will not find an Object.

This leads to the problem of immutability, and the goal of identifying the ways to safely use Pojo. A candidate might suggest using finals at the beginning, because there is no access modifier.

When this class becomes immutable, the task can be slightly changed: Instead of the string value, let's insert a mutable Object, for example, Date or another mutable class. Then the questions are: what will happen now, how will this work, and is there any problem?

The candidate may suggest using either copying or cloning. If so, it might be a good idea to play around with cloning and exceptions as necessary. Cases are different and candidates may resolve this task differently as well.

This is how the interviewer may cover data structures using the example of HashMap, which is probably the most commonly used. If a candidate is open to talking about algorithmic problems, the interviewer may suggest taking a look at the nuances of HashMap.

In any case, any advanced Java interview questions within a practical task are designed to respond to a candidate's experience and interest. The interviewer's aim is not so much to spot knowledge gaps as it is to reveal areas that a candidate is interested in and evaluate the depth and breadth of their knowledge.

Interviewers say that a readiness to get to the code is one of the key skills to check. This helps to assess how a candidate may deal with an unknown problem or a new task moving forward.

Of course, many other interview questions that are equally important, including those about Spring, REST, Cloud, Java 8 features, Java concurrency and multithreading are not covered here.

Advanced Java interview questions may also touch upon:

• CI/CD
• Approach to estimations
• Teamwork
• Refactoring practices
• Testing approaches and culture

In addition, Java senior interview questions may go beyond technologies and tools in an effort to uncover how T-shaped the candidate is.

We hope this overview will help you get a better understanding of questions Java engineers can be asked in the technical interview. If you're exploring opportunities for Java engineers, check out our available openings below.