блог/карьера/собеседования/Java interview questions: everything software engineers need to know

Java interview questions: everything software engineers need to know

12 минутpublished 26 January 2022updated 26 September 2022
ImageImage

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

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:

  • Automated pre-screening, which includes online tests with algorithmic and logical tasks, coding assignments, and quizzes 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 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.

looking for a job?
We're inviting Software Developers, QA Engineers, DevOps Specialists, Business Analysts
view jobs
default vacancy image

Core Java interview questions: Interface vs. Class

Interviewer

Description

Seniority level

Alexander Shvarz 

Lead Software Engineer, EPAM

A block of theoretical questions on interfaces and classes in Java

Junior, Middle, Senior

The goal at this stage is to evaluate: 

  • OOP concept knowledge
  • Understanding of the difference between interfaces and classes
  • Multi-inheritance concept
  • Understanding of Java principles and logics
  • Knowledge of Java 8, its updates and advantages
  • Understanding of backward compatibility and its role

Now, which specific core Java interview questions on interfaces and classes might you hear?

Contract vs. implementation

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.

Multi-implementation vs. single extends

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

Interface

Abstract class

Supports multiple implementations

Doesn’t support multiple inheritance

Doesn’t contain Data Member

Contains Data Member

Doesn’t contain Constructors

Contains Constructors

Contains only incomplete member (signature of member)

Contains both incomplete (abstract) and complete member

Can’t have access modifiers; by default everything is assumed as public

Can contain access modifiers for the subs, functions, properties

Its member can’t be Static

Only Complete Member of abstract class can be Static

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

The diamond problem and default methods

Specifically, the interviewer may ask: what kinds of problems might we face within multi-inheritance? Candidates often know about the diamond problem and can cover this topic fairly well.

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.

Why do we need default methods and can they override an Object method?

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.

Data layer and relational databases

Interviewer

Description

Seniority level

Roman Gordiienko

Solution Architect I, EPAM

A block of theoretical and practical questions on data layer and relational databases

Junior, Middle, Senior

The goal here is to evaluate:

  • Knowledge of data storage design best practices
  • Hands-on relational databases experience
  • Experience with NoSQL
  • Understanding the versions and backward compatibility
  • Understanding the layering logic: what should be in application, and what we need at the database level

Relational databases

At the database level (if it's a relational database), this issue can be solved with constraints. If a 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.

Additional core Java interview questions related to this topic may touch on horizontal scaling of relational databases, associated issues, and ways to resolve them. Solutions include replication of several instances, Master-Master replication, or using NoSQL databases, which are much more advanced in terms of horizontal scaling.

Microservices architecture

Interviewer

Description

Seniority level


Tair Mustafaiev

Solution Architect I, EPAM

A block of theoretical questions about microservices

Senior

The goal here is to evaluate:

  • Understanding of microservices architecture principles
  • Awareness of the pros and cons of microservices
  • Knowledge of key patterns related to microservices

This block contains Java Senior interview questions.

The general concept, pros and cons

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.

Patterns

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.
ImageImage

A practical coding task

Interviewer

Description

Seniority level

Arkadii Suslo

Software Engineering Team Leader, EPAM

A practical coding task on data structures

Junior, Middle, Senior

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 questions Java engineers can be asked in the Technical Interview. If you're exploring opportunities for Java engineers, check out our available openings below.

ImageImage
мы будем рады делиться новыми постамиподпишись, чтобы получать технологические материалы, статьи по карьерному развитию и лайфстайл контент

Подписываясь, вы соглашаетесь на получение маркетинговых материалов от EPAM Anywhere и наших партнеров, а также принимаете Политику конфиденциальности. Вы можете отписаться в любое время.