The ultimate guide to Java interviews with 300+ real-world questions and answers. Get interview-ready in just a few hours with strategies developed by FAANG engineers.

It’s very common to have interviews testing your knowledge of a programming language you claim to be an expert in.

If you've got an interview coming up on Java soon and need to get up to speed, this is the ideal course for you. You'll refresh your memory on everything from the basics to more advanced functionality you’re likely to be asked about. Even if you're using Java every day, you may not have been exposed to parts of it in some time, so it's always useful to make sure you're updated.

This course features more than 300 of the most commonly asked core Java interview questions that you're likely to face as an experienced software engineer. You'll get to explore questions by topic, as well as see detailed answers for each one, and plenty of live code examples where relevant. Get started today.

The Java Interview Handbook: 300+ Interview Questions

<div class="card">
 # Notes on Interfaces vs Abstract Classes
<div class="ans">
<ol>
<li>Interface should be preferred over abstract classes for the following reasons:

<ul>
<li>Existing classes can easily implement new interfaces for added functionality, however existing classes that already extend super classes can't inherit from a new class since multiple inheritance is prohibited in Java.</li>
<li>Interfaces can be used for mixin types. A mixin is a type that a class can implement in addition to its "primary type" to declare that it provides some optional behavior. For example <code class="intf">Comparable</code> interface is a mixin. Such an interface is called a mixin because it allows the optional functionality to be "mixed in" to the type’s primary functionality.</li>
<li>Hierarchy in types can be avoided using interfaces especially when the classes we are designing don't fall into neat hierarchical structures.</li>
</ul>

<li>Combine interfaces and abstract classes to define skeletal structures that provide implementation for the interfaces. In the Collections Framework, we have <code class="clazz">AbstractList</code>, <code class="clazz">AbstractSet</code> etc follow this pattern. The convention is to name such classes as AbstractInterface.</li>

<li>Abstract classes may be suitable in scenarios where the type is expected to evolve in future. Generally, its much easier to evolve an abstract class than an interface. Once an interface has been released and widely adopted, it is nearly impossible to change it. Though, with default method being introduced in interfaces the pain is somewhat eased.</li>

<li>Don't use interfaces to export constants. When a class implements an interface, the interface serves as a type that can be used to refer to instances of the class. The purpose of an interface shouldn't be anything other than that. <code class="intf">java.io.ObjectStreamConstants</code> is one such bad interface and an anti-pattern.
</li>

<li>Use function objects for passing in strategies. An instance of a class that exports exactly one such method is effectively a pointer to that method. Such instances are known as function objects. Note that using an anonymous class in this way will create a new instance each time the call is executed. Primary use of function pointers is to implement the Strategy pattern. To implement this pattern in Java, declare an interface to represent the strategy and a class that implements this interface for each concrete strategy. When a concrete strategy is used only once, it is typically declared and instantiated as an anonymous class.</li>
</ol>
</div>

<div>
 # Notes on Interfaces vs Abstract Classes
<div>
<ol>
<li>Interface should be preferred over abstract classes for the following reasons:

<ul>
<li>Existing classes can easily implement new interfaces for added functionality, however existing classes that already extend super classes can't inherit from a new class since multiple inheritance is prohibited in Java.</li>
<li>Interfaces can be used for mixin types. A mixin is a type that a class can implement in addition to its "primary type" to declare that it provides some optional behavior. For example <code>Comparable</code> interface is a mixin. Such an interface is called a mixin because it allows the optional functionality to be "mixed in" to the type’s primary functionality.</li>
<li>Hierarchy in types can be avoided using interfaces especially when the classes we are designing don't fall into neat hierarchical structures.</li>
</ul>

<li>Combine interfaces and abstract classes to define skeletal structures that provide implementation for the interfaces. In the Collections Framework, we have <code>AbstractList</code>, <code>AbstractSet</code> etc follow this pattern. The convention is to name such classes as AbstractInterface.</li>

<li>Abstract classes may be suitable in scenarios where the type is expected to evolve in future. Generally, its much easier to evolve an abstract class than an interface. Once an interface has been released and widely adopted, it is nearly impossible to change it. Though, with default method being introduced in interfaces the pain is somewhat eased.</li>

<li>Don't use interfaces to export constants. When a class implements an interface, the interface serves as a type that can be used to refer to instances of the class. The purpose of an interface shouldn't be anything other than that. <code>java.io.ObjectStreamConstants</code> is one such bad interface and an anti-pattern.
</li>

<li>Use function objects for passing in strategies. An instance of a class that exports exactly one such method is effectively a pointer to that method. Such instances are known as function objects. Note that using an anonymous class in this way will create a new instance each time the call is executed. Primary use of function pointers is to implement the Strategy pattern. To implement this pattern in Java, declare an interface to represent the strategy and a class that implements this interface for each concrete strategy. When a concrete strategy is used only once, it is typically declared and instantiated as an anonymous class.</li>
</ol>
</div>

This lesson compares and constrasts interfaces and abstract classes.

Java Ecosystem

Methods

Classes

Interfaces

Inheritance

Lambda Expressions

Generics

Multi-Threading

Memory Management

Collections

Exceptions

Reflection

Serialization

Miscellaneous Topics

Java in Practice

Patterns

The End

Interfaces vs Abstract Classes

Notes on