Java Interview Questions from a Top Company: EY (Based on My Personal Experience)

AI image

Preparing for Java interviews at leading consulting and technology-driven organizations like EY (Ernst & Young) requires much more than memorizing syntax. Modern interviews focus heavily on concurrency, JVM internals, database optimization, distributed systems, and practical problem-solving skills.

In this article, I’ll share some of the important interview topics and questions that I encountered during my interview preparation and discussions with engineers. These questions are highly relevant for senior Java developers, backend engineers, and architects.

1. ThreadLocal

1.1 What is ThreadLocal?

ThreadLocal is a utility class in Java that provides thread-local variables. Each thread has its own independent copy of a variable, which means data stored in one thread is completely isolated from other threads.

Its primary purpose is:

• Thread-level data isolation
• Avoiding synchronization overhead
• Maintaining user context, transaction context, or request information

Examples:

• User session information
• Database connections
• Request tracing IDs
• Security contexts

Unlike global variables, ThreadLocal creates a global variable only for the current thread.

1.2 How Does ThreadLocal Work Internally?

Internally, ThreadLocal relies on an inner data structure called ThreadLocalMap.

Each Thread object contains:

Thread.threadLocals

This field references a ThreadLocalMap, which stores:

Entry {
    WeakReference<ThreadLocal<?>> key;
    Object value;
}

Important Points

• Key → Weak Reference (ThreadLocal)
• Value → Strong Reference (actual data)

Because the key is a weak reference, it can be garbage collected. However, the value remains strongly referenced inside the map, which can potentially cause memory leaks, especially in thread pools.

Example

public void set(T value) {
    Thread t = Thread.currentThread();
    ThreadLocalMap map = getMap(t);

if (map != null)
        map.set(this, value);
    else
        createMap(t, value);
}

Best Practice

Always call:

threadLocal.remove();

especially when using:

• Thread pools
• ExecutorService
• Web servers
• Asynchronous processing

Failing to remove ThreadLocal values may result in:

• Memory leaks
• Data corruption
• User context leakage across requests

2. Synchronization and Locking

2.1 Difference Between synchronized and ReentrantLock

Lock Escalation in synchronized

Java performs lock optimization automatically:

Biased Lock
     ↓
Lightweight Lock
     ↓
Heavyweight Lock

Biased Lock

Optimized for single-thread access.

Lightweight Lock

Uses CAS and spinning.

Heavyweight Lock

Involves OS-level mutexes and thread blocking.

2.2 How Does volatile Guarantee Visibility and Ordering?

Visibility

When a variable is declared as volatile:

volatile int count;

Any modification is immediately flushed to main memory.

Other threads read directly from main memory instead of CPU cache.

Ordering

The JVM inserts memory barriers:

• Load Barrier
• Store Barrier

This prevents:

• Instruction reordering
• CPU optimizations that violate happens-before relationships

Does volatile Guarantee Atomicity?

No.

This operation is not atomic:

count++;

It consists of:

1. Read
2. Increment
3. Write

Multiple threads can still interfere with one another.

For atomic operations, use:

• AtomicInteger
• LongAdder
• synchronized
• ReentrantLock

2.3 How Can Java Avoid Deadlocks?

1. Lock Ordering

Always acquire locks in the same order.

Lock A → Lock B

Never:

Thread1 : A → B
Thread2 : B → A

2. Lock Timeout

lock.tryLock(5, TimeUnit.SECONDS)

Avoid waiting indefinitely.

3. Deadlock Detection

Use:

jstack
jconsole
visualvm

to detect blocked threads.

3. Multithreading and Thread Pools

3.1 Thread Lifecycle

Java threads generally move through these states:

1. New
2. Runnable
3. Running
4. Blocked / Waiting / Timed Waiting
5. Terminated

A typical lifecycle looks like:

New
 ↓
Runnable
 ↓
Running
 ↓
Blocked/Waiting
 ↓
Terminated

3.2 How Do You Get a Return Value from a Thread?

The preferred approach is:

Callable + FutureTask

Callable<String> task = () -> "Hello EY";

FutureTask<String> future =
        new FutureTask<>(task);
new Thread(future).start();
String result = future.get();

The Callable interface allows:

• Returning values
• Throwing checked exceptions

3.3 Why Use Thread Pools?

Creating threads is expensive.

Thread pools help:

Reduce Resource Consumption

Avoid repeated creation and destruction of threads.

Improve Response Time

Threads are pre-created and immediately available.

Improve System Stability

Control the number of concurrent threads.

Important ThreadPoolExecutor Parameters

ThreadPoolExecutor(
corePoolSize,
maximumPoolSize,
keepAliveTime,
TimeUnit,
BlockingQueue,
ThreadFactory,
RejectedExecutionHandler)

Core Parameters

• Core Thread Count
• Maximum Thread Count
• Keep Alive Time
• Task Queue
• Thread Factory
• Rejection Policy

4. Concurrency Fundamentals

Parallel vs Serial vs Concurrent

Serial

Tasks execute one after another.

A → B → C

Concurrent

Tasks appear to run simultaneously but share CPU time.

A ↔ B ↔ C

Parallel

Tasks truly execute at the same time on multiple cores.

A || B || C

5. Understanding AQS (AbstractQueuedSynchronizer)

AQS is the core synchronization framework in Java.

Classes built on AQS:

• ReentrantLock
• Semaphore
• CountDownLatch
• ReentrantReadWriteLock
• FutureTask

Internal Structure

AQS maintains:

state

A volatile integer.

CLH Queue

A doubly linked waiting queue of blocked threads.

How ReentrantLock Works

state = 0

No thread owns the lock.

Thread acquires lock:

state = 1

Re-enters:

state = 2

Releases:

state--

When:

state = 0

the lock becomes available.

6. MySQL Interview Questions

6.1 Should String Be Used as an Index?

Technically yes.

Practically, it is usually not recommended.

Why?

String indexes:

• Consume more space
• Increase maintenance cost
• Cause page splits
• Increase B+Tree height

Most systems prefer:

BIGINT AUTO_INCREMENT

instead of:

UUID

because sequential IDs maintain index locality.

6.2 What is an Index?

An index is a data structure designed for:

Fast Data Retrieval

When Should We Create Indexes?

• Frequently queried columns
• WHERE conditions
• JOIN columns
• ORDER BY columns
• GROUP BY columns

When Should We Avoid Indexes?

• Frequently updated columns
• Small tables
• Low-selectivity columns
• Computed expressions

6.3 Why Does an Index Become Invalid?

Common reasons:

Small Tables

Full table scan may be cheaper.

Function Usage

WHERE YEAR(create_time)=2026

Index becomes ineffective.

Range Queries

>
<
BETWEEN
LIKE '%abc'

Low Selectivity

Too many duplicate values reduce index usefulness.

6.4 How to Check Index Usage?

Explain Execution Plan

EXPLAIN
SELECT * FROM users;

View Indexes

SHOW INDEXES FROM users;

6.5 Composite Index and Leftmost Prefix Principle

Example:

INDEX(a,b,c,d)

Queries:

WHERE a=1

Uses index.

WHERE a=1 AND b=2

Uses index.

WHERE a=1 AND b=2 AND c>5

Stops after c.

d becomes unusable because range queries break index ordering.

6.6 Why Does MySQL Use B+ Trees?

B Tree

• Data stored in all nodes.
• More disk I/O.

B+ Tree

• Data stored only in leaf nodes.
• Internal nodes contain only keys.
• Leaf nodes are linked.

Advantages:

• Lower tree height
• Fewer disk reads
• Better range query performance
• Predictable query cost

This is why InnoDB chooses B+ Trees.

6.7 Covering Index

If all required columns exist inside the index:

SELECT name, age
FROM users
WHERE id=1;

No table lookup is required.

Benefits:

• Reduced I/O
• Faster execution
• Better cache utilization

6.8 MySQL Lock Types

Row Lock

• Shared Lock (S)
• Exclusive Lock (X)

Supported by InnoDB.

Table Lock

Locks the entire table.

Lower overhead but lower concurrency.

Global Lock

Entire database becomes read-only.

Typically used for:

• Full backups
• Data migration

7. Database Sharding

Generally considered when:

• Table size exceeds tens of millions of rows
• Query latency increases significantly

Vertical Sharding

Split tables by business domain.

Example:

User Table
Order Table
Payment Table

Horizontal Sharding

Split rows.

Example:

User_0
User_1
User_2

based on:

userId % 3

8. Transaction Fundamentals (ACID)

Atomicity

All succeed or all fail.

Consistency

Data remains valid before and after transactions.

Isolation

Concurrent transactions do not interfere.

Durability

Committed data is permanently stored.

9. MySQL Isolation Levels

Read Uncommitted

Allows dirty reads.

Read Committed

Prevents dirty reads.

Allows non-repeatable reads.

Repeatable Read (MySQL Default)

Prevents:

• Dirty reads
• Non-repeatable reads

May still experience phantom reads under certain scenarios.

Serializable

Highest isolation.

Transactions execute serially.

Highest consistency, lowest concurrency.

10. Redis Interview Questions

Cache Avalanche

Large numbers of keys expire simultaneously.

Solution

• Randomized TTL
• Cache preheating

Cache Penetration

Data does not exist in:

• Redis
• Database

Solution

• Bloom Filter
• Parameter validation
• Cache empty values

Cache Breakdown

Hot key expires.

Massive traffic directly hits the database.

Solution

• Never expire hot keys
• Mutex locks
• Logical expiration

11. Database and Redis Consistency

A commonly used approach:

Delayed Double Delete

Delete Cache
     ↓
Update Database
     ↓
Delete Cache Again

This minimizes stale data issues.

Large-scale systems may additionally use:

• MQ-based serialization
• Ordered queues
• Binlog synchronization
• CDC pipelines

12. Redis Data Structures and Their Use Cases

Final Thoughts

Interviews at companies like EY increasingly focus on practical engineering knowledge rather than theoretical definitions. Topics such as:

• Java Concurrency
• Thread Pools
• AQS Internals
• JVM
• MySQL Indexing
• Transactions
• Redis Architecture
• Database Sharding
• Distributed System Design

are fundamental for senior backend roles.

If you’re preparing for Java interviews in 2026, mastering these concepts with real-world scenarios and implementation details will significantly improve your chances of success.

Thank you for reading!

If you found this article useful, feel free to give it a clap 👏, share it with your friends, and follow for more deep dives into distributed systems, Spring Boot architecture, Kafka, Redis, and high-scale backend engineering.

😊 Your support is the biggest motivation to continue sharing technical insights.