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 Exceptions
<div class="ans">
<ol>
<li>Use exceptions for exceptional situations and not for ordinary control flow.</li>
<li>Use checked exceptions for conditions from which the caller can reasonably be expected to recover. Checked exceptions force the programmer to deal with exceptional conditions, greatly enhancing reliability.</li>

<li>Runtime exceptions should be used to indicate programming errors only.</li>
<li>Don't subclass <code class="clazz">Error</code> to create new subtypes. The general convention is that errors are reserved for use by the JVM to indicate resource deficiencies, invariant failures, or other conditions that make it impossible to continue execution. Given this convention, it’s best not to implement any new <code class="clazz">Error</code> subclasses. Therefore, all of the unchecked throwables needed should subclass <code class="clazz">RuntimeException</code>.</li>

<li>Favor the use of standard exceptions rather than creating new ones to make code easier to comprehend and familiar.

<table>
<tr><th>Exception Name</th><th>Used For</th></tr>
<tr><td><code class="clazz">IllegalArgumentException</code></td><td>Throw this exception when a method is invoked with an argument whose value is inappropriate or not allowed.</td></tr>
<tr><td><code class="clazz">IllegalStateException</code></td><td>Throw this exception if the invocation is illegal because of the state the object is currently in. For instance if an object is being used before being initialized.</td></tr>
<tr><td><code class="clazz">NullPointerException</code></td><td>Throw this exception if a parameter passed in has value <code class="clazz">null</code>. The convention is to throw NullPointerException instead of IllegalArgumentException in such cases.</td></tr>
<tr><td><code class="clazz">IndexOutOfBoundsException</code></td><td>Throw this exception if an out-of-range value is passed in for a parameter that acts as an index in an array or list.</td></tr>
<tr><td><code class="clazz">ConcurrentModificationException</code></td><td>Throw this exception if an object designed for use by a single thread or with external synchronization detects that it is being modified by more than one thread at the same time.</td></tr>
<tr><td><code class="clazz">UnsupportedOperation</code></td><td>Throw this exception if an object does not support an attempted operation. For instance if a subtype doesn't implement for an abstract method of a supertype, it may throw this exception.</td></tr>
</table>
</li>


<li>Lower level exceptions shouldn't be propagated to higher levels. Higher layers should catch lower-level exceptions and instead throw exceptions that are appropriate in terms of the higher-level abstraction. This idiom is known as exception translation. For instance, consider the snippet below where the method catches an exception <code class="clazz">NoSuchElementException</code> but throws an <code class="clazz">IndexOutOfBoundsException</code> exception which is more appropriate for client invoking the method <code class="mthd">getElementAtIndex()</code>.


```java
 public E getElementAtIndex(int index) {
 ListIterator<E> i = listIterator(index);
 try {
 return i.next();
 } catch(NoSuchElementException e) {
 throw new IndexOutOfBoundsException("Index: " + index);
 }
}
```

</li>
<li>Use exception chaining to wrap lower level exceptions to make them available when debugging. Wrapped exception can be retrieved using <code class="mthd">Throwable.getCause()</code>.


```java
// Exception Chaining
 try {
 // ... try body
} catch (LowerLevelException cause) { 
 // Wrap the lower level exception and throw
 // a higher level exception
 throw new HigherLevelException(cause);
}
```

</li>

<li>Always declare checked exceptions individually, and document precisely the conditions under which each one is thrown using the Javadoc <code class="clazz">@throws</code> tag.
## Bad Practice


```java
 void methodThrowsCheckedExceptions(int i) throws Exception {

 if (i == 1) {
 throw new IOException("");
 } else {
 throw new CloneNotSupportedException();
 }
 }
```



## Better Practice


```java
 void methodThrowsCheckedExceptions(int i) throws IOException, CloneNotSupportedException {

 if (i == 1) {
 throw new IOException("");
 } else {
 throw new CloneNotSupportedException();
 }
 }
```

</li>

<li>Detail message of an exception should be informative and contain values of fields or parameters that caused the failure. Avoid lengthy and superfluous prose descriptions.</li>

<li>Consider writing failure atomic code. If an object is still in a useable state or in the same state as before a failed operation, then the code causing the failure is said to be failure atomic. Generally, it is desirable to have failure atomic code especially in case of checked exceptions from which client can be expected to recover. Following are some of the ways to achieve failure atomicity:
<ul>
<li>Using immutable objects buys us failure atomicity for free.</li>

<li>Parameter validations and preconditions check before starting an operation can find failure before objects are modified.</li>
<li>Order operations in such a way that the ones that can fail are ordered before the operations that modify the object.</li>
<li>Implement roll back to bring an object that encounters failure back to the state it was in before the failed operation took place. This approach is especially used when writing to permanent storage such as disks.</li>
<li>Operate on a copy of an object and replace the contents of the object with the copy once the operation is successfuly completed.</li>
</ul>
However, failure atomicity may not always be feasible as it can be costly to implement.
</li>
<li>Don't ignore exceptions. An empty catch block defeats the purpose of exceptions, which is to force you to handle exceptional conditions. Ignoring an exception is analogous to turning off a fire alarm. At the very least, an empty catch block should contain appropriate comments explaining why the developer is choosing to ignore the exception.</li>
</ol>
</div>

<div>
 # Notes on Exceptions
<div>
<ol>
<li>Use exceptions for exceptional situations and not for ordinary control flow.</li>
<li>Use checked exceptions for conditions from which the caller can reasonably be expected to recover. Checked exceptions force the programmer to deal with exceptional conditions, greatly enhancing reliability.</li>

<li>Runtime exceptions should be used to indicate programming errors only.</li>
<li>Don't subclass <code>Error</code> to create new subtypes. The general convention is that errors are reserved for use by the JVM to indicate resource deficiencies, invariant failures, or other conditions that make it impossible to continue execution. Given this convention, it’s best not to implement any new <code>Error</code> subclasses. Therefore, all of the unchecked throwables needed should subclass <code>RuntimeException</code>.</li>

<li>Favor the use of standard exceptions rather than creating new ones to make code easier to comprehend and familiar.

<table>
<tr><th>Exception Name</th><th>Used For</th></tr>
<tr><td><code>IllegalArgumentException</code></td><td>Throw this exception when a method is invoked with an argument whose value is inappropriate or not allowed.</td></tr>
<tr><td><code>IllegalStateException</code></td><td>Throw this exception if the invocation is illegal because of the state the object is currently in. For instance if an object is being used before being initialized.</td></tr>
<tr><td><code>NullPointerException</code></td><td>Throw this exception if a parameter passed in has value <code>null</code>. The convention is to throw NullPointerException instead of IllegalArgumentException in such cases.</td></tr>
<tr><td><code>IndexOutOfBoundsException</code></td><td>Throw this exception if an out-of-range value is passed in for a parameter that acts as an index in an array or list.</td></tr>
<tr><td><code>ConcurrentModificationException</code></td><td>Throw this exception if an object designed for use by a single thread or with external synchronization detects that it is being modified by more than one thread at the same time.</td></tr>
<tr><td><code>UnsupportedOperation</code></td><td>Throw this exception if an object does not support an attempted operation. For instance if a subtype doesn't implement for an abstract method of a supertype, it may throw this exception.</td></tr>
</table>
</li>


<li>Lower level exceptions shouldn't be propagated to higher levels. Higher layers should catch lower-level exceptions and instead throw exceptions that are appropriate in terms of the higher-level abstraction. This idiom is known as exception translation. For instance, consider the snippet below where the method catches an exception <code>NoSuchElementException</code> but throws an <code>IndexOutOfBoundsException</code> exception which is more appropriate for client invoking the method <code>getElementAtIndex()</code>.


```java
 public E getElementAtIndex(int index) {
 ListIterator<E> i = listIterator(index);
 try {
 return i.next();
 } catch(NoSuchElementException e) {
 throw new IndexOutOfBoundsException("Index: " + index);
 }
}
```

</li>
<li>Use exception chaining to wrap lower level exceptions to make them available when debugging. Wrapped exception can be retrieved using <code>Throwable.getCause()</code>.


```java
// Exception Chaining
 try {
 // ... try body
} catch (LowerLevelException cause) { 
 // Wrap the lower level exception and throw
 // a higher level exception
 throw new HigherLevelException(cause);
}
```

</li>

<li>Always declare checked exceptions individually, and document precisely the conditions under which each one is thrown using the Javadoc <code>@throws</code> tag.
## Bad Practice


```java
 void methodThrowsCheckedExceptions(int i) throws Exception {

 if (i == 1) {
 throw new IOException("");
 } else {
 throw new CloneNotSupportedException();
 }
 }
```



## Better Practice


```java
 void methodThrowsCheckedExceptions(int i) throws IOException, CloneNotSupportedException {

 if (i == 1) {
 throw new IOException("");
 } else {
 throw new CloneNotSupportedException();
 }
 }
```

</li>

<li>Detail message of an exception should be informative and contain values of fields or parameters that caused the failure. Avoid lengthy and superfluous prose descriptions.</li>

<li>Consider writing failure atomic code. If an object is still in a useable state or in the same state as before a failed operation, then the code causing the failure is said to be failure atomic. Generally, it is desirable to have failure atomic code especially in case of checked exceptions from which client can be expected to recover. Following are some of the ways to achieve failure atomicity:
<ul>
<li>Using immutable objects buys us failure atomicity for free.</li>

<li>Parameter validations and preconditions check before starting an operation can find failure before objects are modified.</li>
<li>Order operations in such a way that the ones that can fail are ordered before the operations that modify the object.</li>
<li>Implement roll back to bring an object that encounters failure back to the state it was in before the failed operation took place. This approach is especially used when writing to permanent storage such as disks.</li>
<li>Operate on a copy of an object and replace the contents of the object with the copy once the operation is successfuly completed.</li>
</ul>
However, failure atomicity may not always be feasible as it can be costly to implement.
</li>
<li>Don't ignore exceptions. An empty catch block defeats the purpose of exceptions, which is to force you to handle exceptional conditions. Ignoring an exception is analogous to turning off a fire alarm. At the very least, an empty catch block should contain appropriate comments explaining why the developer is choosing to ignore the exception.</li>
</ol>
</div>

This lesson lists issues to be cognizant of when working with Java exceptions.

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

Exceptions Handling

Notes on Exceptions