10 Java developer interview questions and answers

Java software engineers

For Java and other software engineers, the technical interview is a crucial step in the hiring process. Typically, candidates go through initial steps such as profile pre-screening and general interviews before facing Java-specific technical questions. These steps evaluate core skills, previous experience, and interest in specific technologies and projects.

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

In addition to technical questions, candidates are often asked to complete a practical task — typically designed to be solved within 15–20 minutes — to demonstrate their hands-on skills with frameworks and tools.

The full technical interview usually lasts up to 1.5 hours and also includes an evaluation of problem-solving abilities 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.

1. What are the differences between interfaces and classes?

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 may say 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 and further versions?

Java 8 introduced default methods to interfaces, and from Java 9 onward, interfaces also support private instance and static 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.

2. What problems might you face within multi-inheritance?

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.

3. Why do we need default methods, and can they override an object method?

Another question that may be asked about Java is: Why was the concept of default methods included in the language? The answer has its roots in the concept of backward compatibility in Java 8. The ability to enable default methods in the interface allowed Java to 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 cover fundamentals and increase in complexity as the interview progresses.

4. How can you find duplicates in a relational database by using SQL?

If a relational database contains non-unique data, and it is not possible to implement constraints, an interviewer may ask a candidate how to identify duplicates 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.  Simply renaming or adding a column can cause compatibility issues, since the renamed column won't be accessible to the older version of the application.  A good answer: if you want to rename something, add a new column and keep the old one for several versions in a row before deleting 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.

5. How would you design tables to store the inheritance structure?

You might also be asked to design tables to store the inheritance structure, like a person as a student and professor. Some 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.

6. What are the pros and cons of microservices?

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 monolithic architecture.

The pros to mention:

• Microservices architecture is highly scalable and flexible.
• It is easy to understand.
• It helps to avoid fault isolation.
• With proper design and orchestration, recovery is quick.
• It offers faster deployment if CD is well-set and fine-tuned.

The cons to mention:

• 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.
• Deployment can be challenging if the team is not quite mature in terms of DevOps practices and can't set up the CD process properly.

7. What are the common patterns related to microservices?

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.

8. What is the role of var in Java, and in which situations would you choose to use it?

When asked about var in Java, many candidates respond that it is a new type or some special construct. That is not entirely correct. Introduced in Java 10, var is not a type but a form of syntactic sugar for local variable type inference. In other words, the compiler determines the type of the variable based on its initializer expression.

A typical use of var is to reduce boilerplate in verbose declarations. It can also improve readability when the type is clear from the context. The most common scenarios include:

• Working with generic-heavy code
• Writing stream pipelines or builder patterns
• Using enhanced for-loops
• Simplifying try-with-resources statements

On the other hand, the main drawback of var is the loss of clarity. Overusing it can make the code less self-documenting, especially when the initializer does not clearly reveal the variable’s type. For example, var data = process(); tells the reader little about what data actually is.

It is also important to note that the feature is limited in scope: var works only for local variables with initializers, in for-each loops, and in try-with-resources. It cannot be used for method parameters, return types, fields, or uninitialized variables.

When answering this question in an interview, it is crucial to demonstrate not only theoretical knowledge of how and where to use var, but also to provide practical examples from personal experience. This shows that the candidate understands both the benefits and the potential pitfalls of the feature.

9. What is a record in Java, and how is it used?

When candidates are asked about records in Java, many will respond that they are simply “shortcuts for data classes.” While this captures part of the idea, the concept deserves a more precise explanation. Introduced as a preview feature in Java 14 and finalized in Java 16, a record is a special kind of class designed to represent immutable data carriers with minimal boilerplate.

By declaring a record, the compiler automatically generates a canonical constructor, implementations of equals(), hashCode(), and toString(), as well as accessor methods for each component. In practice, this means a record declaration is equivalent to writing a full class with fields, a constructor, getters, and value-based equals/hashCode.

Records are typically used to model simple domain data such as DTOs, messages in event-driven systems, or the results of service calls. Their main advantages are:

• The elimination of boilerplate code.
• Value semantics that compare objects by state rather than identity.
• The ability to make code more concise and expressive.

However, they also have some limitations:

• They cannot extend other classes because they implicitly extend java.lang.Record.
• They are always final and cannot be subclassed.
• All fields must be declared in the record header, meaning additional instance fields cannot be introduced later.

At this point, an interviewer might delve deeper, asking whether records fully immutable.

The answer requires distinguishing between two concepts of immutability:

• A fully immutable object is one where all fields are immutable and none can change state after construction, like a string.
• An effectively immutable object, on the other hand, has fields that cannot be reassigned, but the objects referenced by those fields might still be mutable.

Records guarantee that their fields are final and cannot be reassigned, but they do not enforce immutability of the referenced objects.

For example, a record holding a list can still have its contents modified after construction. This means records are effectively immutable by default, not necessarily fully immutable, and to achieve full immutability, developers must take additional steps, such as using immutable types for fields or creating defensive copies inside the constructor.

10. A practical Java coding task

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.

Summary

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 the questions Java engineers can be asked in a technical interview.