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">
 # General Best Practices
<div class="ans">
<ol>
<li>Strive to minimize the scope of a local variable The best way for minimizing the scope of a local variable is to declare it where it is first used.
## Bad Practice


```java
 // Variable not used immediately but declared
 Random random = new Random(System.currentTimeMillis());

 for (int i = 0; i < 10; i++) {
 // ... for body
 }

 for (int i = 0; i < 10; i++) {
 // ... for body
 }

 // ... more processing
 // .
 // .
 // .
 // ...

 if (random.nextBoolean()) {
 // ... if body
 }
```



## Better Practice


```java
 for (int i = 0; i < 10; i++) {
 // ... for body
 }

 for (int i = 0; i < 10; i++) {
 // ... for body
 }

 // ... more processing
 // .
 // .
 // .
 // ...
 
 // Variable declared closer to where it gets used
 Random random = new Random(System.currentTimeMillis());
 if (random.nextBoolean()) {
 // ... if body
 }

```

</li>

<li>Initialize every local variable when it is being declared. If you don’t yet have enough information to initialize a variable sensibly, postpone declaring it. One exception to this rule can be a <code class="clazz">try-catch</code> statements. If a variable is initialized by a method that throws a checked exception, it must be initialized inside a try block. If the value must be used outside of the try block, then it must be declared before the try block, where it cannot yet be initialized with a sensible value.


```java
 // Initializing to null because the object
 // gets initialized inside the try-catch block
 BufferedReader bufferedReader = null;

 try {
 bufferedReader = new BufferedReader(new FileReader("path_to_file"));
 } catch (IOException ioe) {

 } finally {
 // variable is used outside the try block 
 if (bufferedReader != null)
 bufferedReader.close();
 }
```

</li>


<li>Methods should be kept small and focused. A method should implement a single block of functionality.</li>
<li>For-each loops should be preferred to for loops when iterating over collections. If a custom type consists of a group of elements, consider having it implement <code class="intf">Iterable</code> interface.</li>

<li>Don't reinvent the wheel. Utilize existing libraries for needed functionality. At the very least, familiarize yourself with the <code class="abtc">java.lang</code>, <code class="abtc">java.util</code> and to a lesser extent <code class="abtc">java.io</code></li>

<li>Don't use <code class="clazz">float</code> and <code class="clazz">double</code> types where exact results are required. These types are designed primarily for scientific and engineering calculations. They perform binary floating-point arithmetic, which was carefully designed to furnish accurate approximations quickly over a broad range of magnitudes. The float and double types are particularly a bad choice for monetary calculations because it is impossible to represent 0.1 (or any other negative power of ten) as a float or double exactly. Use <code class="clazz">BigDecimal</code>, <code class="clazz">int</code>, or <code class="clazz">long</code> instead.</li>

<li>Applying <code class="clazz">==</code> operator on boxed primitives is almost always wrong. When your program compares two boxed primitives with the <code class="clazz">==</code> operator, it does an identity comparison, when you really want is a comparision of the values they two objects hold.</li>

<li>Trying to autobox a <code class="clazz">null</code> object results in a <code class="clazz">NullPointerException</code>


```java
 // The following lines will throw
 // a NullPointerException
 Long nullLong = null;
 long primLong = nullLong;
```


</li>


<li>Mixing primitive types and their corresponding object types can result in unintended boxing/unboxing operations causing decreased performance. Consider the snippet below:


```java
 public static void main(String[] args) {
 Long sum = 0L;
 
 for (long i = 0; i < Integer.MAX_VALUE; i++) {
 // i is boxed to Long each time for the
 // below 
 sum += i;
 }
 
 System.out.println(sum);
 }

```


The program compiles without error or warning, and the variable is repeatedly boxed and unboxed, causing performance degradation. When a program boxes primitive values, it can result in costly and unnecessary object creations.</li>

<li>Resist the temptation to represent objects as strings when appropriate data types exist or can be written. For example don't use a string literal "true" to represent a boolean value.
## Bad Practice


```java
 // Don't do this, instead use a boolean
 String value = "true";
```


</li>

<li>Use <code class="clazz">StringBuilder</code> to concatenate strings. Using the string concatenation operator repeatedly to concatenate strings will cause string objects to be copied repeatedly because strings are immutable. Don't mistkae the <code class="clazz">+</code> when applied to two strings as appending the second string to the first, instead both are copied into a third new string object.
## Bad Practice


```java
 String naturalNums = "";

 for (int i = 0; i < Integer.MAX_VALUE; i++) {
 // Don't concatenate using the + operator
 // instead use StringBuilder object
 naturalNums += " " + i;
 }
```


</li>

<li> Favor the use of interfaces rather than classes to refer to objects. If appropriate interface types exist, then parameters, return values, variables, and fields should all be declared using interface types. This allows decoupling code from implementation. The only time we really need to refer to an object’s class is when new-ing up an object. Implementation classes can be switched out much more easily with this approach. Though, it is entirely appropriate to refer to an object by a class rather than an interface if no appropriate interface exists or if you want to use a member field or method specific to the implementing class. In some scenarios where it may make sense to refer to objects using the base or abstract classes.


```java
 // Don't do this
 HashSet<String> set = new HashSet<>();
 
 // Preferrable
 Set<String> set = new HashSet<>();
```


</li>


<li>Don't use native methods merely for performance gains. Applications using native methods are no longer immune to memory corruption errors and are harder to debug. Because native languages are platform dependent, applications using native methods are far less portable. Additionally, there is a fixed cost associated with going into and out of native code, so native methods can decrease performance if the method performs trivial work.</li>

<li>Reflective code can be costly in terms of performance, verbose and loses compile time type safety and exception checking.</li>


<li>
Package names should be hierarchical with the components separated by periods. </li>

</ol>
</div>

<div>
 # General Best Practices
<div>
<ol>
<li>Strive to minimize the scope of a local variable The best way for minimizing the scope of a local variable is to declare it where it is first used.
## Bad Practice


```java
 // Variable not used immediately but declared
 Random random = new Random(System.currentTimeMillis());

 for (int i = 0; i < 10; i++) {
 // ... for body
 }

 for (int i = 0; i < 10; i++) {
 // ... for body
 }

 // ... more processing
 // .
 // .
 // .
 // ...

 if (random.nextBoolean()) {
 // ... if body
 }
```



## Better Practice


```java
 for (int i = 0; i < 10; i++) {
 // ... for body
 }

 for (int i = 0; i < 10; i++) {
 // ... for body
 }

 // ... more processing
 // .
 // .
 // .
 // ...
 
 // Variable declared closer to where it gets used
 Random random = new Random(System.currentTimeMillis());
 if (random.nextBoolean()) {
 // ... if body
 }

```

</li>

<li>Initialize every local variable when it is being declared. If you don’t yet have enough information to initialize a variable sensibly, postpone declaring it. One exception to this rule can be a <code>try-catch</code> statements. If a variable is initialized by a method that throws a checked exception, it must be initialized inside a try block. If the value must be used outside of the try block, then it must be declared before the try block, where it cannot yet be initialized with a sensible value.


```java
 // Initializing to null because the object
 // gets initialized inside the try-catch block
 BufferedReader bufferedReader = null;

 try {
 bufferedReader = new BufferedReader(new FileReader("path_to_file"));
 } catch (IOException ioe) {

 } finally {
 // variable is used outside the try block 
 if (bufferedReader != null)
 bufferedReader.close();
 }
```

</li>


<li>Methods should be kept small and focused. A method should implement a single block of functionality.</li>
<li>For-each loops should be preferred to for loops when iterating over collections. If a custom type consists of a group of elements, consider having it implement <code>Iterable</code> interface.</li>

<li>Don't reinvent the wheel. Utilize existing libraries for needed functionality. At the very least, familiarize yourself with the <code>java.lang</code>, <code>java.util</code> and to a lesser extent <code>java.io</code></li>

<li>Don't use <code>float</code> and <code>double</code> types where exact results are required. These types are designed primarily for scientific and engineering calculations. They perform binary floating-point arithmetic, which was carefully designed to furnish accurate approximations quickly over a broad range of magnitudes. The float and double types are particularly a bad choice for monetary calculations because it is impossible to represent 0.1 (or any other negative power of ten) as a float or double exactly. Use <code>BigDecimal</code>, <code>int</code>, or <code>long</code> instead.</li>

<li>Applying <code>==</code> operator on boxed primitives is almost always wrong. When your program compares two boxed primitives with the <code>==</code> operator, it does an identity comparison, when you really want is a comparision of the values they two objects hold.</li>

<li>Trying to autobox a <code>null</code> object results in a <code>NullPointerException</code>


```java
 // The following lines will throw
 // a NullPointerException
 Long nullLong = null;
 long primLong = nullLong;
```


</li>


<li>Mixing primitive types and their corresponding object types can result in unintended boxing/unboxing operations causing decreased performance. Consider the snippet below:


```java
 public static void main(String[] args) {
 Long sum = 0L;
 
 for (long i = 0; i < Integer.MAX_VALUE; i++) {
 // i is boxed to Long each time for the
 // below 
 sum += i;
 }
 
 System.out.println(sum);
 }

```


The program compiles without error or warning, and the variable is repeatedly boxed and unboxed, causing performance degradation. When a program boxes primitive values, it can result in costly and unnecessary object creations.</li>

<li>Resist the temptation to represent objects as strings when appropriate data types exist or can be written. For example don't use a string literal "true" to represent a boolean value.
## Bad Practice


```java
 // Don't do this, instead use a boolean
 String value = "true";
```


</li>

<li>Use <code>StringBuilder</code> to concatenate strings. Using the string concatenation operator repeatedly to concatenate strings will cause string objects to be copied repeatedly because strings are immutable. Don't mistkae the <code>+</code> when applied to two strings as appending the second string to the first, instead both are copied into a third new string object.
## Bad Practice


```java
 String naturalNums = "";

 for (int i = 0; i < Integer.MAX_VALUE; i++) {
 // Don't concatenate using the + operator
 // instead use StringBuilder object
 naturalNums += " " + i;
 }
```


</li>

<li> Favor the use of interfaces rather than classes to refer to objects. If appropriate interface types exist, then parameters, return values, variables, and fields should all be declared using interface types. This allows decoupling code from implementation. The only time we really need to refer to an object’s class is when new-ing up an object. Implementation classes can be switched out much more easily with this approach. Though, it is entirely appropriate to refer to an object by a class rather than an interface if no appropriate interface exists or if you want to use a member field or method specific to the implementing class. In some scenarios where it may make sense to refer to objects using the base or abstract classes.


```java
 // Don't do this
 HashSet<String> set = new HashSet<>();
 
 // Preferrable
 Set<String> set = new HashSet<>();
```


</li>


<li>Don't use native methods merely for performance gains. Applications using native methods are no longer immune to memory corruption errors and are harder to debug. Because native languages are platform dependent, applications using native methods are far less portable. Additionally, there is a fixed cost associated with going into and out of native code, so native methods can decrease performance if the method performs trivial work.</li>

<li>Reflective code can be costly in terms of performance, verbose and loses compile time type safety and exception checking.</li>


<li>
Package names should be hierarchical with the components separated by periods. </li>

</ol>
</div>

This lesson discusses best practices for various aspects of Java Programming

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

General Best Practices

General Best Practices