DEV Community: Tapas Pal

Interview Q & A Non-technical

Tapas Pal — Mon, 01 Jun 2026 23:05:20 +0000

Q1. How do you handle disagreements during design discussions?
Answer:
I focus on technical facts, business requirements, and measurable outcomes rather than personal preferences. I encourage open discussion, present pros and cons of each approach, and support decisions with data, architecture principles, and operational considerations. If needed, I build a proof of concept to validate assumptions before making a final recommendation.

Q2.Have you participated in system design reviews?
Answer:
Yes. I regularly participate in design reviews where we discuss service boundaries, API contracts, database design, security requirements, deployment strategies, scalability concerns, and integration patterns. My role is to identify risks, suggest improvements, and ensure the design aligns with architectural standards and best practices.

Q3. How do you actively participate in architectural and design discussions?
I actively participate by understanding both the business requirements and technical constraints before proposing solutions. During design discussions, I evaluate different approaches, identify trade-offs, consider scalability, security, performance, maintainability, and operational impacts. I collaborate with architects, product owners, QA teams, and other developers to ensure the proposed solution aligns with the existing architecture and long-term business goals

Q4. Can you give an example of an architectural decision you influenced?
In a previous project, a service was making multiple synchronous calls to downstream systems, causing high latency and occasional timeouts. During architecture discussions, I proposed moving to an event-driven approach using Kafka for non-critical processing. We analyzed the trade-offs, updated the design, and implemented asynchronous communication. This reduced API response times significantly and improved system resilience during peak traffic.

(STAR Format)

Situation:
Our order-processing system was experiencing performance issues during peak traffic.

Task:
We needed to improve response times without redesigning the entire platform.

Action:
I analyzed the architecture and identified that synchronous communication with downstream services was causing bottlenecks. Since Kafka was already part of the ecosystem, I proposed an event-driven approach where requests were published to Kafka and processed asynchronously. I documented trade-offs, reviewed the design with architects and stakeholders, and led the implementation.

Result:
API response times decreased from several seconds to under 500 milliseconds, throughput increased significantly, and the solution was implemented without major architectural changes.
-----------------------------------------------------------------

What is Kanban in Agile?

Kanban is an Agile methodology focused on visualizing work, limiting work in progress (WIP), and continuously improving the flow of work.
Unlike Scrum, Kanban does not require fixed-length sprints. Work items are pulled through the system continuously.

When Kanban is Preferred
Kanban works well for:

Support Teams
Production Issues
Bug Fixes
Urgent Requests

Work arrives unpredictably.
-----------------------------------------------------------------

Conduct code reviews and ensure adherence to best practices and coding standards
Interviewers want to know:

How you perform code reviews
What you look for
How you provide feedback
How you maintain coding standards
How you mentor developers

How do you conduct code reviews and ensure adherence to best practices and coding standards?
I treat code reviews as an opportunity to improve code quality, maintainability, security, and team knowledge sharing. During reviews, I focus on correctness, readability, performance, security, test coverage, adherence to coding standards, and alignment with the overall architecture. I provide constructive feedback, explain the reasoning behind my suggestions, and encourage discussions rather than simply approving or rejecting changes. I also ensure that the code follows SOLID principles, clean code practices, and established team guidelines.

What Do You Look For During Code Reviews?

Code Correctness
Readability
SOLID Principles
Performance
Exception Handling
Security
Test Coverage

What coding standards do you enforce?

Meaningful naming conventions
Constructor injection
SOLID principles
Clean Code practices
Proper exception handling
Logging standards
Unit test coverage
Security best practices
Consistent formatting
Avoidance of code duplication

What would you do if a developer disagrees with your review comments?
I would discuss the concern openly and focus on the technical reasoning rather than personal preferences. If there are multiple valid approaches, I would evaluate them based on maintainability, performance, consistency, and team standards. If necessary, I would involve the team or architect to reach a consensus.

--------------------------------------------------------------
Work collaboratively with other teams to ensure seamless integration of software components

How you collaborate across teams
Communication skills
Integration experience
Handling dependencies
Working in Agile environments
Leadership and stakeholder management

I work closely with product owners, architects, QA teams, DevOps engineers, and other development teams from the early stages of a project. I participate in design discussions, define clear API contracts, identify dependencies, and ensure integration requirements are understood by all parties. I also use regular communication channels such as Agile ceremonies, technical workshops, and integration testing sessions to proactively address issues before deployment.

2. Can you give an example of a cross-team integration project?
Sample Answer (STAR)
We were developing an order processing platform that required integration between the Order, Payment, and Customer services owned by different teams.

Task
Ensure all services integrated correctly and met business requirements.

Action
I coordinated API contract discussions, documented integration requirements, defined error-handling strategies, and worked with QA teams to create end-to-end test scenarios. We also established regular integration checkpoints during development.

Result
The integration was completed successfully with minimal defects, and the solution was deployed without impacting existing services.

3. How do you manage dependencies between teams?
I identify dependencies early during backlog refinement, sprint planning, or PI planning sessions. I work with other teams to agree on delivery timelines, API contracts, and testing strategies. I also track dependencies throughout the sprint and communicate any risks or delays proactively to avoid surprises late in the delivery cycle.

4. What do you do when another team's API is not ready?
Strong Answer
I try to avoid blocking development by using mocks, stubs, or contract-based development. For example, if the API specification is available, we can create mock services using tools such as WireMock and continue development while waiting for the actual implementation.

Example:

Order Service
      |
Mock Payment Service

This reduces dependency-related delays.
5. How do you ensure API integrations are successful?
Answer
I focus on:

Clear API contracts
OpenAPI/Swagger documentation
Contract testing
Error handling
Versioning strategy
Integration testing

Example:

Order Service
      |
REST API Contract
      |
Payment Service

Both teams agree on request and response formats before development begins.

6. Have you participated in Three Amigos sessions?
Yes. I regularly participate in Three Amigos sessions involving Product Owners, Developers, and QA engineers. These discussions help clarify requirements, identify edge cases, define acceptance criteria, and ensure that integration requirements are understood before development begins.

7. How do you handle integration issues discovered late in testing?
First, I work with the relevant teams to quickly identify the root cause. Then I assess the impact, communicate the issue to stakeholders, and agree on a resolution plan. I also review why the issue was not detected earlier and improve testing, contract validation, or communication processes to prevent similar problems in the future.

What's the difference IoC and Dependency Injection?

Tapas Pal — Sat, 30 May 2026 10:01:31 +0000

Inversion of Control (IoC) and Dependency Injection (DI) are related concepts, but they are not the same thing.

Question. Is Dependency Injection the same as Inversion of Control?
Answer: No. IoC is a principle, while DI is one way to implement that principle.

1. What is Inversion of Control (IoC)?
Normally, an object creates and manages its own dependencies.
Without IoC

public class OrderService {

    private PaymentService paymentService;

    public OrderService() {
        paymentService = new PaymentService();
    }
    public void placeOrder() {
        paymentService.processPayment();
    }
}

What happens here?
paymentService = new PaymentService();
OrderService is responsible for:

Creating the dependency
Managing the dependency
Using the dependency

The control is inside OrderService
Problem
Suppose tomorrow you want:
CreditCardPaymentService instead of PaymentService
You must modify: OrderService
This creates tight coupling.

IoC Concept

With IoC: Object creation responsibility is moved outside the class.
Instead of: OrderService creates PaymentService
we do:

Someone else creates PaymentService
Someone else gives it to OrderService

Control is inverted.
That's why it is called: Inversion of Control

Real-Life Example

Imagine a restaurant.
Without IoC - You go into the kitchen and cook your own food.

Customer --> Kitchen --> Cooks food

Customer controls everything.
With IoC - You sit at the table.

Waiter brings food.

Customer <-- Waiter <-- Kitchen

Customer doesn't control food preparation.
Control has been inverted.

2. What is Dependency Injection (DI)?

Dependency Injection is a technique used to achieve IoC.
Instead of creating dependencies yourself:

new PaymentService()

someone injects them.
Example

public class OrderService {

    private PaymentService paymentService;

    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
    public void placeOrder() {
        paymentService.processPayment();
    }
}

Now:

OrderService orderService =
        new OrderService(new PaymentService());

Dependency is injected from outside.
This is Dependency Injection.

IoC vs DI

Spring Boot Example
Let's see what Spring does internally.
Step 1: Component

@Service
public class PaymentService {

    public void processPayment() {
        System.out.println("Payment Processed");
    }
}

Step 2: Dependent Class

@Service
public class OrderService {

    private final PaymentService paymentService;

    public OrderService(PaymentService paymentService) {
        this.paymentService = paymentService;
    }
    public void placeOrder() {
        paymentService.processPayment();
    }
}

Notice: new PaymentService()
does not exist.

Step 3: Spring Starts
When application starts:

@SpringBootApplication
public class Application {
}

Spring scans:

@Service
@Component
@Repository
@Controller

classes. Spring finds:
PaymentService
OrderService

Step 4: Spring Creates Beans
Internally:

PaymentService paymentService =
        new PaymentService();

Bean created.

Stored in IoC Container.

Spring Container
      |
      +--> PaymentService Bean

Step 5: Spring Finds Dependency

Spring sees:

public OrderService(PaymentService paymentService)

It understands: OrderService needs PaymentService

Step 6: Spring Injects Dependency

Internally:

OrderService orderService =
        new OrderService(paymentService);

Spring passes the object.

This is Dependency Injection.

Internal Flow Diagram

Application Starts
       |
       V
Component Scan
       |
       V
Find PaymentService
       |
       V
Create PaymentService Bean
       |
       V
Find OrderService
       |
       V
OrderService requires PaymentService
       |
       V
Inject PaymentService Bean
       |
       V
Create OrderService Bean
       |
       V
Store in IoC Container

What is the IoC Container?

Spring's IoC Container is essentially a registry that manages objects (beans).

Simplified view:

ApplicationContext
       |
       +--> PaymentService
       |
       +--> OrderService
       |
       +--> UserService

The container:

Creates objects
Injects dependencies
Manages lifecycle
Destroys objects Types of Dependency Injection

1. Constructor Injection (Recommended)

public OrderService(PaymentService paymentService) {
    this.paymentService = paymentService;
}

Advantages:

Immutable dependencies
Easy testing
Spring recommendation

2. Setter Injection

@Service
public class OrderService {

    private PaymentService paymentService;

    @Autowired
    public void setPaymentService(
            PaymentService paymentService) {
        this.paymentService = paymentService;
    }
}

3. Field Injection
@Autowired private PaymentService paymentService;
Works, but generally discouraged because it makes testing harder.

Inversion of Control (IoC) is a design principle where the control of creating and managing objects is transferred from application code to a container or framework.

Dependency Injection (DI) is a technique used to implement IoC by supplying dependencies from outside rather than creating them inside the class.

Example:

Without DI:

PaymentService paymentService =  new PaymentService();

With DI:

public OrderService(PaymentService paymentService) {
    this.paymentService = paymentService;
}

In Spring Boot, the IoC container (ApplicationContext) creates beans and injects dependencies automatically using constructor injection, thereby implementing IoC through Dependency Injection.

How Spring does JWT verification based on RS256

Tapas Pal — Thu, 21 May 2026 05:14:36 +0000

RS256 JWT flow between two microservices, then how Spring actually validates it internally.

how Spring Security internally validates that JWT step by step.

Here's what the actual code looks like in the Inventory Service (spring-boot-starter-oauth2-resource-server):
application.yml — tell Spring where to fetch the public key:


spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          jwk-set-uri: http://auth-service/oauth2/jwks

SecurityConfig.java — configure the filter chain:


@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
          .authorizeHttpRequests(auth -> auth
           .requestMatchers("/api/inventory/reserve").hasRole("ORDER_SVC")
              .anyRequest().authenticated()
          )
          .oauth2ResourceServer(oauth2 -> oauth2
              .jwt(jwt -> jwt.jwtAuthenticationConverter(jwtAuthConverter()))
          );
        return http.build();
    }

    @Bean
    public JwtAuthenticationConverter jwtAuthConverter() {
        JwtGrantedAuthoritiesConverter converter = new JwtGrantedAuthoritiesConverter();
        converter.setAuthoritiesClaimName("roles");      // map "roles" claim → GrantedAuthority
        converter.setAuthorityPrefix("ROLE_");
        JwtAuthenticationConverter jwtConverter = new JwtAuthenticationConverter();
        jwtConverter.setJwtGrantedAuthoritiesConverter(converter);
        return jwtConverter;
    }
}

InventoryController.java — the endpoint is now protected:


@RestController
@RequestMapping("/api/inventory")
public class InventoryController {

    @PostMapping("/reserve")
    @PreAuthorize("hasRole('ORDER_SVC')")
    public ResponseEntity<String> reserveStock(
            @RequestBody ReserveRequest req,
            @AuthenticationPrincipal Jwt jwt) {   // inject the parsed JWT

        String callerService = jwt.getSubject();  // "order-service"
        // proceed with reservation...
        return ResponseEntity.ok("Reserved for " + callerService);
    }
}

What does BearerTokenAuthenticationFilter do exactly in Spring Security?

What BearerTokenAuthenticationFilter does
It is a OncePerRequestFilter — guaranteed to run exactly once per request, sitting early in Spring Security's filter chain. Its entire job is to bridge the raw HTTP world (a string in a header) to Spring Security's authentication world (a typed Authentication object in the SecurityContext).

Step 1 — Token extraction via DefaultBearerTokenResolver
It reads the Authorization header and strips Bearer from the front. It also optionally checks request parameters (access_token=...) if you configure allowFormEncodedBodyParameter or allowUriQueryParameter. If no token is found at all, it just calls chain.doFilter() — the request passes through unauthenticated, and a later filter or your controller will enforce access.

Step 2 — Wraps the raw token in BearerTokenAuthenticationToken
This is a lightweight container that holds the raw JWT string and is marked as not yet authenticated (isAuthenticated() = false). Think of it as the question — "here's a token, can you validate it?"

Step 3 — Hands off to AuthenticationManager
The filter calls authenticationManager.authenticate(token). The manager routes this to JwtAuthenticationProvider, which calls NimbusJwtDecoder to do the actual RS256 verification, expiry check, issuer check, etc.

Step 4a — On success: populates SecurityContextHolder
If authentication succeeds, the provider returns a fully populated JwtAuthenticationToken (which is authenticated, carries the parsed claims, and has GrantedAuthority objects derived from your roles). The filter stores this in SecurityContextHolder.getContext().setAuthentication(...), then calls chain.doFilter() — the request proceeds to your controller, where @PreAuthorize and @AuthenticationPrincipal work because the context is populated.

Step 4b — On failure: delegates to AuthenticationEntryPoint
If the provider throws JwtValidationException (bad signature, expired, wrong issuer), the filter catches it, clears the SecurityContext (important — prevents stale auth from leaking), and calls authenticationEntryPoint.commence(...), which writes a 401 Unauthorized response with a WWW-Authenticate: Bearer error="invalid_token" header.

Key things it does NOT do
It does not do authorization — that's AuthorizationFilter further down the chain.
It doesn't decode the JWT itself — that's NimbusJwtDecoder.
It doesn't map claims to roles — that's JwtAuthenticationConverter.

The filter's job is purely: extract → wrap → delegate → store or reject.

Difference Between StackOverflowError and OutOfMemoryError in Java

Tapas Pal — Wed, 20 May 2026 05:19:17 +0000

StackOverflowError occurs when stack memory is exhausted due to
excessive method calls, typically caused by infinite or very deep
recursion. OutOfMemoryError occurs when the JVM cannot allocate
more memory, usually because heap memory is exhausted by excessive
object creation or memory leaks

Java memory mainly has:

1. Stack Memory
2. Heap Memory

JVM Memory
│
├── Stack Memory
│      ├── Method calls
│      ├── Local variables
│      └── Function frames
│
└── Heap Memory
       ├── Objects
       ├── Arrays
       └── Instance data

1. StackOverflowError

What Is It?
stack memory becomes full

Most Common Cause?
Infinite recursion

public class Main {
    static void test() {
        test();
    }
    public static void main(String[] args) {
        test();
    }
}

Final Error

Exception in thread "main"
java.lang.StackOverflowError

Stack Frames Growing and eventually stack full.

TOP
│
├── test()
├── test()
├── test()
├── test()
├── test()
│
BOTTOM

Every method call creates:

stack frame
local variables
return address

Too many frames → overflow.

Common Causes of StackOverflowError

2. OutOfMemoryError

What Is It? Occurs when?
JVM cannot allocate more memory

usually in: heap memory

Most Common Cause : Too many objects

import java.util.ArrayList;
import java.util.List;
public class Main {
    public static void main(String[] args) {
        List<int[]> list = new ArrayList<>();
        while(true) {
            list.add(new int[1000000]);
        }
    }
}

What Happens Internally?
Each loop:

creates huge array
stores in heap
references retained in list

Garbage collector cannot free memory.
Eventually: heap full

Final Error

java.lang.OutOfMemoryError:
Java heap space

Heap Growing and no space left.

Heap
│
├── Object
├── Object
├── Object
├── Object
├── Object
├── Object
│
FULL

Common Causes of OutOfMemoryError

StackOverflowError

Usually easier to debug.
Stack trace clearly shows recursion.

OutOfMemoryError
Can be very difficult:

memory leaks
object retention
cache problems
GC tuning

often require:

heap dumps
profilers
memory analyzers

Important JVM Parameters
Stack Size -Xss

Example: java -Xss2m Main
Increase stack size.

Heap Size -Xmx

Example: java -Xmx2g Main
Increase heap size.

Can StackOverflowError Cause OutOfMemoryError?

Indirectly yes sometimes.
Huge recursion may:

create many objects
trigger memory exhaustion

But normally they are distinct problems.

Why Are These Errors and Not Exceptions?

Because:

serious JVM resource exhaustion
application usually cannot safely recover

Both extend:

java.lang.Error

not: Exception

Can We Catch Them?

Technically yes:

catch(StackOverflowError e)

catch(OutOfMemoryError e)

BUT usually: bad practice

Application state may already be unstable.

Checked Exceptions in Java Q &A Advantages and disadvantages

Tapas Pal — Sun, 17 May 2026 06:12:01 +0000

Checked exceptions provide compile-time enforcement and are useful
for recoverable conditions such as IO or network failures, ensuring
callers consciously handle exceptional situations. However, they
often introduce excessive boilerplate, tight coupling across
layers, and poor compatibility with modern functional programming
styles, which is why many modern frameworks prefer unchecked
exceptions for cleaner API design.

Why Java has checked exceptions?
Are checked exceptions good or bad?
Why many modern frameworks avoid them?
When should we use checked exceptions?

To answer well, you need balanced understanding.

What Is a Checked Exception?
A checked exception is an exception that:
must be handled or declared at compile time
Compiler forces handling.

Examples Checked Exception

IOException
SQLException
FileNotFoundException
ParseException

Example

FileReader file = new FileReader("abc.txt");

Compiler error unless:
try-catch
OR:
throws IOException used.

Why Java Introduced Checked Exceptions?
Main idea: force developers to think about recoverable failures

Example:

file may not exist
DB connection may fail
network may timeout

Java designers wanted: explicit error handling

ADVANTAGES OF CHECKED EXCEPTIONS
1. Compile-Time Safety

BIGGEST advantage. Compiler forces handling.

Example

public void readFile() throws IOException { }

Caller MUST: catch or rethrow
Benefit Reduces:
ignored critical failures

Without Checked Exceptions Developer may completely forget error handling.
2. Better API Documentation
Method signature clearly communicates: what can go wrong
Example

public void save()  throws SQLException

Immediately tells caller:
DB failure possible

3. Encourages Recovery Logic
Checked exceptions usually represent:
recoverable situations
Example:
retry network call
ask user for another file
reconnect DB

Example

try {
    readFile();
} catch(IOException e) {
    System.out.println( "Please provide valid file"=);
}

Application can continue.

4. Prevents Silent Failures

Forces conscious handling.
Good for:
banking
healthcare
critical enterprise systems

Example:
Ignoring payment gateway failure can be dangerous.
Checked exceptions force handling.

5. Improves Code Contracts

Method contract becomes explicit.
Example

transferMoney() throws InsufficientBalanceException

Clear business-level expectation.

DISADVANTAGES OF CHECKED EXCEPTIONS

Now the important part.

Most experienced developers criticize checked exceptions heavily.

1. Boilerplate Code Explosion

BIGGEST complaint.

Example

try { 
readFile();
} catch(IOException e) {
    throw new RuntimeException(e);
}

Repeated everywhere.
Creates: ceremonial code
Especially Bad In Layered Architectures

Suppose:

Repository layer
Service layer
Controller layer

Checked exception propagates through ALL layers.
Example
throws IOException
throws IOException
throws IOException

Very noisy.
2. Exception Leakage Across Layers

Low-level implementation details leak upward.
Service layer now knows: SQLException
This tightly couples:
business logic
database technology Bad design.

Better Design
Service layer should expose:
BusinessException
not DB exceptions.

3. Developers Often Ignore Proper Handling

Because compiler forces handling,
developers sometimes write:

catch(Exception e) { }
OR:
e.printStackTrace();

Bad practice.

So Checked Exceptions Sometimes Create:
fake handling
instead of meaningful handling.

4. Bad Fit for Functional Programming
Streams/lambdas work poorly with checked exceptions.

list.stream() .map(this::readFile)

If readFile() throws checked exception:

compilation issues
ugly wrappers required
Example Ugly Wrapper

try {
    return readFile();
} catch(IOException e) {
    throw new RuntimeException(e);
}

Very common frustration.

5. Frameworks Prefer Unchecked Exceptions

Modern frameworks:
Spring
Hibernate
Reactor

mostly use: RuntimeException

Why? Cleaner APIs.

Example
Spring converts:
SQLException into: DataAccessException unchecked exception.

6. Reduces API Evolution Flexibility

Suppose API initially: throws IOException
Later you add: SQLException
ALL callers break.
Huge maintenance issue.

7. Deep Call Stack Pollution
Example

Controller
   ↓
Service
   ↓
Repository
   ↓
FileReader

Every layer forced to:
catch or rethrow

Leads to:
throws pollution

Why Runtime Exceptions Became More Popular?

Because:

cleaner APIs
less boilerplate
better framework integration
functional programming friendliness

But Does That Mean Checked Exceptions Are Bad?

NO.
They are useful when:

caller can realistically recover
failure expected and meaningful

Good Use Cases for Checked Exceptions
Scenario Good?
File operations ✅
Network calls ✅
User input parsing ✅
Retryable operations ✅

Bad Use Cases
Scenario Bad?
Programming bugs ❌
NullPointerException ❌
Validation programming errors ❌

These should be:
unchecked exceptions

Golden Design Principle
Use checked exceptions for:
recoverable conditions

Use unchecked exceptions for:
programming errors

Why IOException Is Checked But NullPointerException Is Not?

Because:

missing file may be recoverable
programming bug usually not recoverable

Why Spring Uses Runtime Exceptions?

Spring philosophy:
developer productivity over forced handling and:
centralized exception handling

AOP
transaction rollback

work better with unchecked exceptions.
Important Real-World Observation
Most modern enterprise applications:
use checked exceptions very minimally
convert low-level checked exceptions into runtime exceptions
Example

catch(SQLException e) {
    throw new DataAccessException(e);
}

Cleaner service APIs.
Important Senior-Level Insight

Checked exceptions work best when:

failure is expected
caller has meaningful recovery strategy

Otherwise they create:

boilerplate
coupling
noisy APIs

Q. Can overridden method throw broader checked exception?
NO.

Example

class A {
    void test() throws IOException {}
}
//INVALID
class B extends A {
    void test() throws Exception {}
}

Compile error.

Q. Can overridden method throw narrower checked exception?
YES.
Example

void test() throws FileNotFoundException

Allowed.
Q. Can checked exception be ignored?

Only if:
caught
or declared
Compiler enforces it.

What Is the N+1 Problem in Hibernate/JPA? How to resolve it? Interview Q&A

Tapas Pal — Sun, 17 May 2026 05:24:59 +0000

The N+1 problem happens when:

Hibernate executes 1 query to fetch parent records
+
N additional queries to fetch child records

This causes:

too many database calls
performance degradation
slow APIs

The Hibernate N+1 problem occurs when Hibernate executes one query
to fetch parent entities and then executes additional queries for
each associated child entity due to lazy loading. This leads to
excessive database round trips and performance degradation. The
most common solution is using JOIN FETCH, EntityGraph, batch
fetching, or DTO projections to load related data efficiently in
fewer queries.

Simple Real-World Example

Suppose: 100 customers each customer has N orders
You want: all customers with their orders
But Hibernate executes:
1 query for customers 100 separate queries for orders

Total: 101 queries
This is: N+1 problem

1. Customer Entity

package com.example.entity;
import jakarta.persistence.*;
import lombok.*;
import java.util.List;

@Entity
@Table(name = "customers")
@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@ToString(exclude = "orders")
public class Customer {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;

    @OneToMany(
            mappedBy = "customer",
            fetch = FetchType.LAZY,
            cascade = CascadeType.ALL
    )
    private List<Order> orders;
}

2. Order Entity

package com.example.entity;
import jakarta.persistence.*;
import lombok.*;

@Entity
@Table(name = "orders")
@Getter
@Setter
@NoArgsConstructor
@AllArgsConstructor
@ToString(exclude = "customer")
public class Order {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String item;

    @ManyToOne(fetch = FetchType.LAZY)
    @JoinColumn(name = "customer_id")
    private Customer customer;
}

Important Thing FetchType.LAZY

means:

orders NOT loaded immediately
loaded only when accessed

The Problematic Code

List<Customer> customers = customerRepository.findAll();

for(Customer c : customers) {
    System.out.println(c.getOrders().size());
}

Looks harmless. BUT internally dangerous.
What Happens Internally?
Query 1 : Hibernate fetches customers:

SELECT * FROM customer;

Suppose 100 customers returned.

Then Loop Starts Iteration 1 c.getOrders()
Triggers:

SELECT * FROM orders WHERE customer_id = 1;

Iteration 2

SELECT * FROM orders WHERE customer_id = 2;

Final Total 1 + N queries

If: 100 customers then: 101 queries

Visual Representation
Initial Query
SELECT customers
returns:

C1 C2 C3 C4 C5
Then Lazy Loading
C1 → SELECT orders C2 → SELECT orders C3 → SELECT orders C4 → SELECT orders C5 → SELECT orders

Many DB round trips. Why Is This Bad?
Database calls are expensive.
Problems:

network latency
DB CPU usage
connection pool pressure
slow response times

How To Detect N+1 Problem Enable SQL logging.

Spring Boot
spring.jpa.show-sql=true

If you see: repeated similar queries
then likely N+1 issue.

Solution 1. FETCH JOIN

package com.example.repository;

import com.example.entity.Customer;
import org.springframework.data.jpa.repository.*;
import org.springframework.stereotype.Repository;
import java.util.List;

@Repository
public interface CustomerRepository
        extends JpaRepository<Customer, Long> {
    @Query("""
           SELECT DISTINCT c
           FROM Customer c
           JOIN FETCH c.orders
           """)
    List<Customer> findAllCustomersWithOrders();
}

What Happens Now? Hibernate executes ONE query:

SELECT c.*, o.*
FROM customer c
JOIN orders o
ON c.id = o.customer_id;

Result Instead of: 101 queries Only: 1 query

Huge improvement.
Visual

Before
1 customer query + 100 order queries
After FETCH JOIN 1 combined query

2. EntityGraph

@EntityGraph(attributePaths = "orders")
List<Customer> findAll();

Tells Hibernate: load orders together
Advantage : Cleaner than custom JPQL sometimes.

3. Batch Fetching - Hibernate optimization.
Example
spring.jpa.properties.hibernate.default_batch_fetch_size=20
What Happens? Instead of: 100 queries Hibernate batches:

SELECT * FROM orders
WHERE customer_id IN (1,2,3...20)

Much fewer queries.

4. DTO Projection - Best for read-heavy APIs.

Example

@Query("""
       SELECT new com.dto.CustomerDTO(
              c.name,
              o.item)
       FROM Customer c
       JOIN c.orders o
       """)

Avoids entity graph entirely. Very efficient.
** Service Class**

package com.example.service;
import com.example.entity.Customer;
import com.example.repository.CustomerRepository;
import lombok.RequiredArgsConstructor;
import org.springframework.stereotype.Service;
import java.util.List;

@Service
@RequiredArgsConstructor
public class CustomerService {

    private final CustomerRepository customerRepository;
    public void printCustomers() {
        List<Customer> customers =
                customerRepository
                        .findAllCustomersWithOrders();

        for(Customer c : customers) {
            System.out.println(c.getName());
            System.out.println(c.getOrders().size()
            );
        }
    }
}

Interview Question

Q1. Why Not Use EAGER Fetching?

Many thinks: FetchType.EAGER
solves N+1 but NOT always true.

Why?
EAGER can STILL produce N+1.
And may:

load unnecessary data
create huge joins
hurt performance
Example Suppose:
Customer
Orders
Payments
Addresses

EAGER loading everything creates:
Cartesian product explosion
massive memory usage
Best Practice Prefer:
LAZY + FETCH JOIN when needed

Q2. Why LAZY Exists If It Causes N+1?

Because:
loading everything always is worse
sometimes child data not needed

LAZY improves:
memory usage
startup cost
flexibility

Problem occurs only when: iterative lazy access happens

Another Dangerous Situation
Nested N+1.
Example
Customer → Orders → Items
Now queries become:
1 + N + N*M
Can explode massively.

Important Hibernate Internals

N+1 happens because:

Hibernate proxy objects
lazy initialization
session-triggered fetch
Lazy Loading Mechanism

Hibernate initially creates:proxy objects

Actual SQL executed only when accessed.
Example c.getOrders()
This line triggers DB query.

Best Solutions Comparison
Solution Best For
FETCH JOIN Most common
EntityGraph Clean JPA
Batch Fetching Large collections
DTO Projection APIs/reporting

Q3. Does N+1 happen only in OneToMany?

NO. Can happen in:

ManyToOne
OneToOne
nested associations

Find First Non Repeating Character - Java Program With Time and Space Complexity

Tapas Pal — Wed, 13 May 2026 04:49:30 +0000

Problem Statement
Given a string: "swiss"
Find the first character that appears only once.
Expected Output : w
Because:
s repeats
w appears once and comes first

Solution:
Best Approach (Using LinkedHashMap)
We will use: LinkedHashMap
Why? Because:

Stores frequency count
Maintains insertion order

Approach-1 : Frequency Array (int[256])

// Method to find the first non-repeating character
public class FirstNonRepeatingCharacter {
   public static Character firstNonRepeating(final String str) {
         // Check if string is null or empty
        // If yes, return null because no character exists
       if (str == null || str.isEmpty()){
            return null;
        }
        // Create frequency array of size 256
        // Each index represents an ASCII character
        // Example: freq['a'] stores count of 'a'
       int[] freq = new int[256];
       // Convert string into char array and iterate each character
       for(char ch : str.toCharArray()) {
           // Increment frequency count of character
           freq[ch]++;
       }
       // Iterate again to preserve original order
       // We need FIRST non-repeating character
       for(char ch : str.toCharArray()) {
          // Check if character frequency is exactly 1
          if(freq[ch] == 1) {
             // Return first unique character immediately
             return ch;
          }
       }
   // If no non-repeating character found
   return null;
   }
   public static void main(String[] args) {
        // Example 1
        // swiss
        // s -> 3
        // w -> 1
        // i -> 1
        // First non-repeating = w
        System.out.println(firstNonRepeating("swiss"));
        // Example 2
        // null input
        // returns null
        System.out.println(firstNonRepeating(null));
    }
}

Approach-2 : LinkedHashMap

public class FirstNonRepeatingCharacter {

    public static Character findFirstNonRepeating(final String str) {
        if (str == null || str.isEmpty()){
            return null;
        }
        // Step 1: Create LinkedHashMap to store character frequencies
        Map<Character, Integer> map = new LinkedHashMap<>();
        // Step 2: Count frequency of each character
        for(char ch : str.toCharArray()) {
        //If key exists → return value otherwise return default   
       //value 0, for first time of each character always map.getOrDefault(ch, 0) = 0
            map.put(ch, map.getOrDefault(ch, 0) + 1);
        }
        // Step 3: Find first character with frequency 1
        for(Map.Entry<Character, Integer> entry : map.entrySet()) {
            if(entry.getValue() == 1) {
                return entry.getKey();
            }
        }
        return null;
    }
   public static void main(String[] args) {
        System.out.println(firstNonRepeating("swiss"));
        System.out.println(firstNonRepeating(null));
    }
}

Approach-3 : Java Streams + groupingBy

public class FirstNonRepeatingCharacter {
    public static char firstNonRepeating(final String str) {
       if (str == null || str.isEmpty()){
            return null;
        }
       Map<Character, Long> map =
            str.chars()
             .mapToObj(c -> (char) c)
             .collect(Collectors.groupingBy(
                     c -> c,
                     LinkedHashMap::new,
                     Collectors.counting()
             ));

       return map.entrySet()
              .stream()
              .filter(e -> e.getValue() == 1)
              .map(Map.Entry::getKey)
              .findFirst()
              .orElse(null);
}
    public static void main(String[] args) {
        System.out.println(firstNonRepeating("swiss"));
        System.out.println(firstNonRepeating(null));
    }
}

Comparing 3 Approaches for First Non-Repeating Character

We will compare:

Frequency Array (int[256])
LinkedHashMap
Java Streams + groupingBy

We’ll analyze:

readability
performance
memory usage
Unicode support
interview suitability
production suitability
Problem Statement

Input: "swiss"
Frequency:
s -> 3
w -> 1
i -> 1

Output: w
Approach 1 — Frequency Array (int[256])
Code Logic
int[] freq = new int[256];
Store frequency using ASCII index.
Example: freq['s']
stores count of s. Visual Flow "swiss"
↓
freq['s'] = 3
freq['w'] = 1
freq['i'] = 1
Second loop:
s -> 3 ❌
w -> 1 ✅
Return: w
Time Complexity Two loops: O(n) + O(n)
Final: O(n)
Space Complexity int[256]
Fixed size, so: O(1) (constant space)
Advantages
✅ Fastest approach
✅ Lowest memory usage
✅ Very interview-friendly
✅ Excellent cache locality
✅ No object creation overhead
Disadvantages
❌ ASCII only
❌ Not Unicode-safe
❌ Less flexible
❌ Hardcoded size assumption
Important Unicode Problem
This breaks for:

Chinese
Japanese
Emoji
Unicode chars

Because Unicode exceeds 256.
Best Use Case Best for:

competitive programming
ASCII-only systems
performance-critical code

Approach 2 — LinkedHashMap
Code Logic
Map<Character, Integer> map = new LinkedHashMap<>();

Why LinkedHashMap? Preserves insertion order

Needed for: FIRST non-repeating character
Time Complexity Insertion: O(1) for each char.

Total: O(n) Space Complexity
Worst case: all unique characters
Map stores all. So: O(n)
Advantages
✅ Unicode-safe
✅ Easy to understand
✅ Flexible
✅ Maintains insertion order
✅ Production-friendly

Disadvantages
❌ More memory usage
❌ Object overhead
❌ HashMap node overhead
❌ Slightly slower than array

Internal Memory Cost Each entry stores:

Character object
Integer object
Node object
next pointer
hash

Much heavier than array.
Best Use Case
Best for:

enterprise applications
Unicode support
maintainable code
real production systems

Approach 3 — Streams + groupingBy
Code Logic str.chars()
Convert string to stream. Then: groupingBy(...)
creates frequency map.
Visual Flow
"swiss"
↓ chars()
115 119 105 115 115
↓ mapToObj()
[s,w,i,s,s]
↓ groupingBy()
{
s=3,
w=1,
i=1
}
↓ filter(value == 1)
w
Time Complexity Still: O(n)
BUT Important Hidden Cost

Streams introduce:
lambda calls
boxing/unboxing
stream pipeline overhead
temporary objects

So practical runtime is slower. Space Complexity

Internally creates:

Stream objects
Collectors
Lambda instances
LinkedHashMap

Worst case: O(n)
but with higher constant factors.
Advantages
✅ Elegant
✅ Functional style
✅ Modern Java
✅ Very expressive
✅ Concise

Disadvantages
❌ Slowest approach
❌ More garbage objects
❌ Higher memory overhead
❌ Harder debugging
❌ Less beginner-friendly

Performance Reality Even though all are: O(n)
Big difference exists in actual runtime.
Real Runtime Ranking **
Array > LinkedHashMap > Streams
**Memory Ranking Least memory → Highest memory
Array > LinkedHashMap > Streams
Readability Ranking
Most readable: LinkedHashMap
Most concise: Streams
Most low-level: Array

DRY RUN WITH APPROACH 2(LinkedHashMap) with input swiss
Step 1 — Null/Empty Check

if (str == null || str.isEmpty())

Input: "swiss"
Condition: false
Continue execution.
Step 2 — Create LinkedHashMap

Map<Character, Integer> map = new LinkedHashMap<>();

Initially: {} (empty map)
IMPORTANT
LinkedHashMap preserves insertion order. This is critical.
Step 3 — Convert String to char[]
str.toCharArray()
Result: [s, w, i, s, s]
FIRST LOOP — Count Frequencies
Iteration 1 char ch = 's'
Execute map.getOrDefault('s', 0)
's' not present.
Returns: 0 Then 0 + 1 becomes: 1
Put into map

map.put('s', 1)

Map Now
{
s=1
}
Visual Representation
Head
↓
[s=1]
Iteration 2
char ch = 'w'
Execute
map.getOrDefault('w', 0)
'w' absent.
Returns: 0
Put
map.put('w', 1)

Map Now
{
  s=1,
  w=1
}
Visual
Head
 ↓
[s=1] ⇄ [w=1]

Iteration 3
char ch = 'i'
Execute

map.getOrDefault('i', 0)

Returns: 0
Put

map.put('i', 1)
Map Now
{
  s=1,
  w=1,
  i=1
}

Visual
[s=1] ⇄ [w=1] ⇄ [i=1]
Iteration 4 char ch = 's'
Execute

map.getOrDefault('s', 0)

's' exists. Returns: 1
Increment
1 + 1 = 2
Update Map
map.put('s', 2)

Map Now
{
  s=2,
  w=1,
  i=1
}

IMPORTANT

Insertion order remains SAME.
's' does NOT move.
Visual
[s=2] ⇄ [w=1] ⇄ [i=1]
Iteration 5
char ch = 's'
Execute
map.getOrDefault('s', 0)
Returns: 2
Increment
2 + 1 = 3
Update
map.put('s', 3)

Final Map
{
  s=3,
  w=1,
  i=1
}

Final Internal Linked Order
Head
 ↓
[s=3] ⇄ [w=1] ⇄ [i=1]
SECOND LOOP — Find First Non-Repeating
Traverse entrySet()
for(Map.Entry<Character, Integer> entry : map.entrySet())

Traversal order:
s → w → i

because LinkedHashMap preserves insertion order.

Entry 1
s=3
Check
entry.getValue() == 1
Result: false
Continue.
Entry 2
w=1
Check
entry.getValue() == 1
Result: true
Return return 'w'
Final Output w

Generics in Java Interview Q&A

Tapas Pal — Tue, 12 May 2026 20:05:24 +0000

Java Generics is one of the MOST important Java concepts.
If you understand Generics properly:
collections become safer code becomes reusable compile-time bugs reduce dramatically
A generic type is a generic class or interface that is parameterized over types.

What Are Generics?
Generics allow classes, interfaces, and methods to work with:
different data types safely
without rewriting code.
The Diamond
In Java SE 7 and later, you can replace the type arguments required to invoke the constructor of a generic class with an empty set of type arguments (<>) as long as the compiler can determine, or infer, the type arguments from the context. This pair of angle brackets, <>, is informally called the diamond. For example, you can create an instance of Box with the following
statement:

Box<Integer> integerBox = new Box<>();

Generic Class

class Box<T> {
    T value;
    void set(T value) {
        this.value = value;
    }
    T get() {
        return value;
    }
}

Usage

Box<String> box =
        new Box<>();
box.set("Hello");
String s = box.get();

What Does Mean?
T means:Type parameter
Placeholder for actual type.
Common Generic Type Names
Symbol - Meaning
T - Type
E - Element
K - Key
V - Value
N - Number

Same class reused.

Box<Integer> intBox = new Box<>();
Box<String> strBox = new Box<>();

DISADVANTAGES OF GENERICS
Now let us discuss the IMPORTANT limitations.

1. Type Erasure
MOST IMPORTANT limitation.
Java removes generic type information at runtime.
Example

List<String> list = new ArrayList<>();

At runtime becomes: List
Generic type removed. Why?
Backward compatibility with old Java.
Consequences of Type Erasure
Cannot Do This

if(obj instanceof List<String>)

Compile-time error.

Cannot Create Generic Array

T[] arr = new T[10];

Not allowed. Why?
Because runtime type unknown.

2. Primitive Types Not Allowed
Cannot use: List<int>
Only objects allowed.
Correct List<Integer>
Uses wrapper classes.
Problem
Wrapper classes add:
memory overhead
boxing/unboxing cost
Example

List<Integer> list = new ArrayList<>();
list.add(10);

Actually becomes:
Integer.valueOf(10)
Auto-boxing.

3. Cannot Create Static Generic Fields
Invalid

class Test<T> {
    static T value;
}

Why?
A static field belongs to the class, but a generic type belongs to the object instance/type parameter.
These two concepts conflict.
First Understand Static Variables
Static variables are:shared across ALL objects
Only ONE copy exists.

How ConcurrentHashMap works Internally

Tapas Pal — Tue, 12 May 2026 19:35:30 +0000

HashMap is non-thread-safe and optimized for single-threaded performance, while ConcurrentHashMap is designed for concurrent access using fine-grained synchronization and CAS operations. HashMap is preferable for local non-shared data, whereas ConcurrentHashMap is ideal for shared mutable state in multi-threaded applications.

What is ConcurrentHashMap?

ConcurrentHashMap is a thread-safe version of HashMap designed for high concurrency.

HashMap Problem

Suppose two threads update a normal HashMap simultaneously:

Map<String, Integer> map = new HashMap<>();
Thread-1: map.put("A", 1);
Thread-2: map.put("B", 2);

Since HashMap is not thread-safe, data corruption or lost updates can occur.

How ConcurrentHashMap Solves It Java 7

Used Segment-based locking.

ConcurrentHashMap
 ├── Segment 0 (Lock)
 ├── Segment 1 (Lock)
 ├── Segment 2 (Lock)
 └── Segment 3 (Lock)

Only the segment being modified gets locked.

Java 8+ (Current Implementation)

Segments were removed.
Uses:

CAS (Compare-And-Swap)
Synchronized locking on individual buckets when needed
Volatile reads
Fine-grained locking

This significantly improves performance.
Internal Structure
Imagine:

ConcurrentHashMap<Integer, String> map = new ConcurrentHashMap<>();

Internally:

Index 0 -> Node
Index 1 -> Node
Index 2 -> Node
Index 3 -> Node
...

Each bucket contains a linked list or red-black tree.
Bucket 5
A -> B -> C

Detailed Example
Let's assume:

map.put(1, "Java");
map.put(17, "Spring");

Suppose both keys hash to Bucket 1.

Internal structure:

Bucket 1
1=Java -> 17=Spring

Scenario - Two threads execute simultaneously:

Thread-1:
map.put(33, "Kafka");

Thread-2:
map.put(49, "AWS");

Assume both keys also hash to Bucket 1.
Step 1: Calculate Bucket

Both threads compute:

index = hash(key) & (table.length - 1)

Result: Bucket 1
Both want to modify the same bucket.

Step 2: First Thread Acquires Lock

Thread-1 reaches Bucket 1 first.
Internally:

synchronized(firstNode) {
    // insert new node
}

Bucket:

1=Java -> 17=Spring

Thread-1 locks the first node.
LOCKED by Thread-1

Step 3: Thread-2 Arrives
Thread-2 also wants Bucket 1.

map.put(49, "AWS");

It tries to acquire the same bucket lock.
Bucket 1 locked --> Thread-2 waits.

Step 4: Thread-1 Updates
Thread-1 adds:

1=Java
   ↓
17=Spring
   ↓
33=Kafka

Lock released.

Step 5: Thread-2 Continues

Now Thread-2 acquires the bucket lock.
Current bucket:

1=Java
   ↓
17=Spring
   ↓
33=Kafka

Adds:

1=Java
   ↓
17=Spring
   ↓
33=Kafka
   ↓
49=AWS

Lock released.

Important Observation
Only Bucket 1 was locked.

Other buckets remain available.

Bucket 0 -> Free
Bucket 2 -> Free
Bucket 3 -> Free
Bucket 4 -> Free

If another thread writes to Bucket 4:

map.put(100, "Docker");

it proceeds without waiting.
This is why ConcurrentHashMap performs much better than Hashtable.

CAS Optimization

For an empty bucket:

map.put(10, "Java");

No lock is taken initially.
Instead it uses CAS:
compareAndSwap()

Pseudo-code:

if(bucket is empty) {
    CAS(null, newNode);
}

CAS is a CPU-level atomic operation.

This avoids locking completely for many operations.
Read Operations - Reads usually do not require locking.

map.get(10);

The thread:

Computes hash
Finds bucket
Traverses nodes
Returns value

No lock is acquired in most cases.
That's why reads are extremely fast.
---------------------------------------------------------------
What is the difference between segment-level locking and CAS-level locking?

For ConcurrentHashMap, the difference between segment-level locking (Java 7) and CAS + bucket-level locking (Java 8+) is a very common interview question.

1. Segment-Level Locking (Java 7)

In Java 7, the map was divided into multiple Segments.
Think of a segment as a mini hash table with its own lock.

ConcurrentHashMap

Segment 0 (Lock 0)
 ├─ Bucket 0
 ├─ Bucket 1
 └─ Bucket 2

Segment 1 (Lock 1)
 ├─ Bucket 3
 ├─ Bucket 4
 └─ Bucket 5

Segment 2 (Lock 2)
 ├─ Bucket 6
 ├─ Bucket 7
 └─ Bucket 8

Example

map.put("A", 1);  // Segment 0
map.put("B", 2);  // Segment 0
map.put("C", 3);  // Segment 1

Thread 1

map.put("A", 100);

Locks: Segment 0
Thread 2
map.put("B", 200);
Also needs:
Segment 0
It must wait even if "A" and "B" are in different buckets inside Segment 0.

Thread 1 --> LOCK Segment 0
Thread 2 --> WAITING

Thread 3

map.put("C", 300);

Uses Segment 1.
Thread 3 --> LOCK Segment 1
Can run concurrently.

Limitation - A whole segment gets locked.

Even if there are 100 buckets inside that segment, only one writer can modify anything in that segment at a time.

2. CAS + Bucket-Level Locking (Java 8+)
Java 8 removed Segments completely.
Structure:

Bucket 0
Bucket 1
Bucket 2
Bucket 3
Bucket 4

Each bucket can be independently synchronized when needed.

Case 1: Empty Bucket

Suppose:

map.put("Java", "Spring");

Bucket 5 is empty. Instead of locking:

synchronized(...) {
   insert
}

ConcurrentHashMap uses CAS.
Pseudo-code:

if (bucket == null) {
    CAS(null, newNode);
}

What CAS Means
CAS = Compare And Swap

Expected value = null
New value = Node(Java)

CPU executes atomically:

If current value == null
    insert node
Else
    fail

No lock involved.
Example of CAS
Initial:

Bucket 5 = null
Thread 1
put("Java", value)

CAS:

null -> Node(Java)

Success.

Thread 2
At the same time:

put("Spring", value)

CAS checks:

Expected = null
Actual   = Node(Java)

Fails.
Thread 2 retries.
No lock was used.

Case 2: Bucket Already Has Data

Suppose: Bucket 5
Java -> Kafka

Now:

put("AWS", value)

Needs linked-list modification.
ConcurrentHashMap locks only that bucket.
Internally similar to:

synchronized(firstNode) {
    // update linked list
}

Comparison Example
Assume:

Segment 0
 ├ Bucket A
 ├ Bucket B
 └ Bucket C

Java 7

Thread 1: put(keyA)
locks: Segment 0

Thread 2: put(keyB)
also needs: Segment 0

Must wait.

Thread 1 ---> Running
Thread 2 ---> Waiting

Java 8

Thread 1: put(keyA)
locks only: Bucket A

Thread 2: put(keyB)
locks only: Bucket B

Both proceed simultaneously.

Thread 1 ---> Running
Thread 2 ---> Running

Much higher concurrency.

Mutable Key Problem in HashMap

Tapas Pal — Tue, 12 May 2026 17:55:52 +0000

Mutable Key Problem in HashMap
HashMap depends on hashCode() remaining stable
If the key changes after insertion:

hashCode changes
bucket location changes
HashMap cannot find the object anymore

First Understand One Critical Rule
HashMap Stores Entry Based On: hashCode() + equals()
Simple Mutable Key Example
Employee Class

class Employee {
    String name;
    Employee(String name) {
        this.name = name;
    }
    @Override
    public int hashCode() {
        return name.hashCode();
    }
    @Override
    public boolean equals(Object obj) {
        Employee e = (Employee) obj;
        return this.name.equals(e.name);
    }
}

Step 1 — Create Object

Employee emp = new Employee("John");

Current value:

name = "John"
Step 2 — Put into HashMap

Map<Employee, String> map = new HashMap<>();
map.put(emp, "Developer");

What Happens Internally?
A. HashMap Calls hashCode()
emp.hashCode()
Suppose:

"John".hashCode() = 2314539

B. Bucket Index Calculated

Formula:index = (n - 1) & hash
Suppose result: bucket = 5
Internal Structure

Bucket 5
   ↓
(Employee{name="John"}, "Developer")

Everything works correctly.

Step 3 — Retrieve Object

map.get(emp);

HashMap again calculates:
"John".hashCode()
Gets same bucket: bucket 5
Finds object successfully.
Output:Developer
NOW THE DANGEROUS PART
Step 4 — Modify Key Object
emp.name = "David";
Now object becomes: Employee{name="David"}
Important Thing The SAME object reference exists.
But: hashCode has changed
Step 5 — Try Retrieval Again
map.get(emp);
What Happens Internally Now?
A. HashMap Calls hashCode()
Now:"David".hashCode() = 65805908
Different hashCode.
B. New Bucket Calculated Now: bucket = 12
HashMap Searches Wrong Bucket HashMap now checks:Bucket 12
BUT object actually stored in:Bucket 5
BEFORE Mutation

Bucket 5
   ↓
(Employee{name="John"}, "Developer")

hashCode based on:John
AFTER Mutation Object becomes:Employee{name="David"} Now HashMap calculates: bucket 12
So retrieval searches: Bucket 12 → EMPTY
Final Result

System.out.println(map.get(emp));

Output: null
This is called:Hash-based collection corruption
Even Worse Scenario
Now try: map.containsKey(emp);
Output:false even though object exists inside map.
Another Dangerous Problem
Suppose: map.put(emp, "Manager");
Now HashMap inserts NEW entry.
Internal State Becomes

Bucket 5
   ↓
(Employee{name="David"}, "Developer")

Bucket 12
   ↓
(Employee{name="David"}, "Manager")

Same object reference appears logically duplicated.
Why Immutable Objects are Safe

Example: String key = "John"; as Strings are immutable.
Meaning:value never changes

hashCode stable
bucket stable So retrieval always works. Best Practice Always Use Immutable Keys Recommended: String Integer UUID Immutable custom objects For Custom class use instance variable as final How to Create Immutable Key Object

final class Employee {
    private final String name;
    Employee(String name) {
        this.name = name;
    }
    @Override
    public int hashCode() {
        return name.hashCode();
    }
    @Override
    public boolean equals(Object obj) {
        Employee e = (Employee) obj;
        return this.name.equals(e.name);
    }
}

Now object cannot change after insertion.Safe for HashMap.

Real Production Problems Caused

Mutable keys can cause:
Memory leaks Duplicate entries Data inconsistency Cache corruption Hard-to-debug production issues
Especially dangerous in:
caching systems distributed systems Hibernate microservices concurrent systems

Q1: Why does retrieval fail even though same object reference is used?
Answer: Because HashMap first locates bucket using hashCode(). Reference equality is irrelevant until bucket found.

Q2: Can equals() alone solve this?
Answer: No.
Because equals() is checked only AFTER correct bucket located.

Q3: Can mutable keys ever be safe?
*Answer: * Only if fields used in hashCode()/equals() never change.

Q4: Is there any advantages of using mutable key?
*Answer: * Mostly used for:
`- object graph traversal

serialization frameworks
proxy systems
JVM internals` "Mutable keys are only safe if the mutable state is excluded from equals() and hashCode(). In practice, immutable or effectively immutable keys are preferred because HashMap bucket placement depends on stable hash codes."

Using StringBuilder as a HashMap Key — Why It Is Dangerous
"StringBuilder is a poor HashMap key because it uses reference-based equals/hashCode from Object and is mutable. Even though mutating it does not change the bucket location, the logical identity of the key changes, leading to unpredictable behavior, failed lookups, duplicate logical keys, and corrupted business semantics."

Q. If I have to use a custom class as a key, what precaution I need to take it?
Using a Custom Class as a HashMap Key — Precautions You MUST Take
This is a very common experienced-level Java interview question.
If you use a custom object as a HashMap key, the MOST important rule is:
equals() and hashCode() must be implemented correctly and consistently.

Otherwise you get:

failed retrievals
duplicate keys
memory leaks
corrupted collections
unpredictable behavior Golden Rules for Custom Keys Rule 1 — Override BOTH equals() and hashCode() Never override only one. WRONG Example

class Employee {
    int id;
    @Override
    public boolean equals(Object obj) {
        return true;
    }
}

This breaks HashMap contract.
Correct Rule

If:
a.equals(b) == true
then:
a.hashCode() MUST equal b.hashCode()

Rule 2 — Use Immutable Fields for Equality

Fields used in:

`- equals()

hashCode()`

should NEVER change after insertion.
Best Practice Example

final class Employee {
    private final int id;
    private final String name;
    Employee(int id, String name) {
        this.id = id;
        this.name = name;
    }
    @Override
    public boolean equals(Object obj) {
        if(this == obj)
            return true;
        if(obj == null || getClass() != obj.getClass())
            return false;
        Employee e = (Employee) obj;
        return id == e.id;
    }
    @Override
    public int hashCode() {
        return Integer.hashCode(id)}}

Why This Is Safe because:
id never changes hashCode stable bucket stable
HashMap works correctly forever.

Be Careful with Lombok
Dangerous Lombok Example

@Data
class Employee {
    int id;
    String name;
}

plaintext

@Data includes ALL fields.
If name changes:

hashCode changes
HashMap breaks Better @EqualsAndHashCode(of = "id")

Q. Why do we need to increase the size of the hash map and who determines when to increase it? Although we have hash collision, if we have hash collision, why do we need to increase the size?

Collisions can be handled, but too many collisions destroy performance.
Resizing exists to maintain:
near O(1) lookup/insertion performance
First Understand the Core Structure

A HashMap internally has:Array of buckets
Example:table[16]
Each bucket may contain:

empty
one node
linked list
tree
Visual Example Suppose capacity:16 Good Distribution

Bucket 0 → A
Bucket 1 → empty
Bucket 2 → B
Bucket 3 → C
Bucket 4 → empty
Bucket 5 → D

Very few collisions.Operations close to: O(1) Fast.
What Happens If Map Keeps Growing Without Resize?
Suppose:
still only 16 buckets but now 10,000 entries inserted Internal Structure Becomes Bucket 0 → A → B → C → D → E → F Bucket 1 → G → H → I → J Bucket 2 → K → L → M → N → O ...
Huge collision chains.Now Lookup Becomes Slow
Suppose searching: O(n)
instead of:O(1)
Important PointCollision handling does NOT eliminate performance degradation.
It only prevents data loss.

Why Resize Helps, Suppose capacity increases:
16 → 32 Now more buckets available.
Entries redistribute.
BEFORE Resize Bucket 5 ↓ A → B → C → D → E AFTER Resize Bucket 5 → A → C Bucket 21 → B → D → E
Collision chains smaller.
Performance improves.
Main Goal of Resizing
Reduce: collision density
This keeps:
lookup fast insertion fast deletion fast
Who Decides When Resize Happens?
HashMap uses:
load factor
Default Load Factor
0.75
Formula
threshold = capacity × loadFactor
Bucket Index Calculation
Java internally uses:
index = (n - 1) & hash
Where: n = array capacity
hash = processed hashCode
This is fixed.You cannot override it in normal HashMap.
The bucket calculation algorithm in Java HashMap is fixed internally and cannot be overridden. Java uses (capacity - 1) & hash for fast bucket computation. However, developers indirectly influence bucket placement through the quality of their hashCode() implementation.

How does HashMap work internally?

Tapas Pal — Mon, 11 May 2026 22:11:57 +0000

Day-1
1. How does HashMap work internally?
Answer:
High-Level Internal Structure
Internally, HashMap uses:
Array + LinkedList + Red-Black Tree (Java 8+)

Internal Data Structure

transient Node<K,V>[] table;

class Node<K, V> {
     int hash;
     K key;
     V value;
   Node<K, V> next;
}

This is an array of buckets.
Each bucket stores:
single node linked list tree nodes

Basic Working Flow
When you do:

map.put(key, value);

HashMap performs:

Calculate hashCode()
Calculate bucket index
Store value in bucket
Handle collision if needed

Step-by-Step Example

Map<Integer, String> map = new HashMap<>();
map.put(101, "John");
map.put(102, "David");
map.put(103, "Alex");

Now let us understand internally what happens.
Step 1: Create HashMap

Map<Integer, String> map = new HashMap<>();

Internally:
capacity = 16 loadFactor = 0.75 threshold = 12

Meaning:
resize after 12 elements
Internal Array

Initially: table[16]
Like:

All buckets empty initially.
Step 2: Insert First Entry

map.put(101, "John");
//
{
  int hash = 101;
  Key key = {101};
  String value = "John";
  Node next = null;
}

Internal Working
A. Calculate hashCode()
For Integer:

hash = key.hashCode()

For 101: hash = 101
B. Calculate Bucket Index
Formula:

index = (n - 1) & hash

Where: n = capacity = 16
So: 15 & 101
Binary:
15 = 00001111 101 = 01100101

Result: 5
So element stored in: bucket 5

Internal Structure

table[5] → Node(101, "John")

Step 3: Insert Another Entry
map.put(102, "David");
Hash: 102
Index: 15 & 102 = 6
Stored at: bucket 6

Current Structure
table[5] → (101, John) table[6] → (102, David)

What is a Node Internally?
Simplified internal class:

static class Node<K,V> {
    final int hash;
    final K key;
    V value;
    Node<K,V> next;
}

Collision Handling
Now suppose:

map.put(117, "Mike");

Why Collision Happens?
Index formula: 15 & 117 = 5
Same bucket as 101.

Now What Happens?
HashMap creates linked list.
table[5] ↓ (101, John) ↓ (117, Mike)
This is collision handling.
How Retrieval Works
Suppose:

map.get(117);

Step-by-Step Retrieval

Step 1: Calculate hash hash = 117 Step 2: Find bucket 15 & 117 = 5

Go to bucket 5.
Step 3: Traverse nodes
Bucket contains:

(101, John)
(117, Mike)

HashMap checks: equals()
until matching key found.
Returns: Mike
Why equals() is Important?
Hash collision possible.
So HashMap uses:
`1. hashCode()

equals()`

Both are mandatory.
Internal Put Logic (Simplified)

public V put(K key, V value) {
    int hash = hash(key);
    int index = (table.length - 1) & hash;
    Node<K,V> node = table[index];
    if(node == null) {
        table[index] = new Node<>(hash, key, value);
    } else {
        // collision handling
        // traverse linked list
        // compare using equals()
        // update or append
    }
}

Java 8 Optimization

Before Java 8:
collisions stored as linked list only
Problem: worst-case O(n)

Java 8 Improvement
If bucket size becomes: > 8
Linked list converts to: Red-Black Tree
called: Treeification
Now complexity becomes: O(log n)
instead of: O(n)
Visual Example
Before Treeify
Bucket 5:
A → B → C → D → E → F → G → H → I
Search slow.

After Treeify
          D
        /   \
       B     G
      / \   / \
     A  C  F  I

Faster searching.
Important Interview Point
Why Capacity Always Power of 2?
Because index calculation:

(n - 1) & hash

is faster than modulo:

hash % n

Load Factor Default: 0.75

Meaning: resize when 75% full

Rehashing
When threshold exceeded:

New bigger array created
Entries redistributed Example: 16 → 32

*Why Immutable Keys Recommended?
*
Suppose:

class Employee {

    String name;
}

If name changes:

hashCode changes
retrieval fails

Very dangerous.
That is why:

String
Integer
immutable objects

recommended as keys.

**Real Interview Example
**Bad Mutable Key

class Employee {
    String name;
    Employee(String name) {
        this.name = name;
    }
    @Override
    public int hashCode() {
        return name.hashCode();
    }
    @Override
    public boolean equals(Object obj) {
        Employee e = (Employee) obj;
        return this.name.equals(e.name);
    }
}

Problem

Employee e = new Employee("John");
map.put(e, "Developer");
e.name = "David";
map.get(e); // FAILS

Because:

bucket changed
object unreachable

Time Complexity
Operation Average Worst put O(1) O(n) get O(1) O(n) remove O(1) O(n)
Java 8 treeification improves worst case:

O(log n)

Internal Hash Function
Java improves hash distribution:

static final int hash(Object key) {
    int h;
    return (key == null)
            ? 0
            : (h = key.hashCode()) ^ (h >>> 16);
}

This avoids poor bucket distribution.
*Null Handling *
HashMap allows:

one null key
multiple null values

Null key always stored in: bucket 0
Important Differences Feature Thread-safe Null-allowed Performance HashMap No Yes. Faster Hashtable Yes No Slower