Question 1

How does ConcurrentHashMap achieve thread safety?

Accepted Answer

Since Java 8 there are no segments. It locks one bin at a time — a CAS to install the first node in an empty bin, and synchronized on the bin's head node otherwise — while reads never lock at all. The catch is that per-key atomicity does not make your sequence of calls atomic.

Question 2

equals() vs ==, and why hashCode() matters

Accepted Answer

Equal objects must return the same hash code. Unequal objects are free to collide — that is legal and normal, not a bug. Break the first rule and hash-based collections lose your data silently.

Question 3

volatile vs synchronized

Accepted Answer

volatile guarantees visibility and ordering: a write is seen by any later read, and operations are not reordered across it. It never guarantees atomicity, so volatile count++ still loses updates — it is three operations, and volatile makes each of them visible without making the trio indivisible.

Question 4

Checked vs unchecked exceptions

Accepted Answer

Checked exceptions are enforced by the compiler; unchecked ones are not. The interesting question is not the definition but why every major Java framework since 2004 has moved to unchecked exceptions — and lambdas finished the argument in Java 8.

Question 5

You are building a payment gateway where thousands of transactions run in parallel. How would you ensure thread-safe balance updates?

Accepted Answer

volatile guarantees visibility and ordering: a write is seen by any later read, and operations are not reordered across it. It never guarantees atomicity, so volatile count++ still loses updates — it is three operations, and volatile makes each of them visible without making the trio indivisible.

Question 6

Spring AOP, with real production examples

Accepted Answer

Spring builds a proxy around your bean — a JDK dynamic proxy if it has an interface, a generated subclass otherwise — and the advice lives in the proxy, not in your class. Every limit follows: self-invoked, private, final and static methods never cross the proxy, so an annotation on them does nothing and nothing warns you.

Question 7

How do circular dependencies happen, and how are they resolved?

Accepted Answer

Constructor injection makes the dependency list part of the type, so a bean cannot be built wrong, its fields can be final, and a cycle fails immediately. Field injection wires in a second phase after construction, which is why it hides both a missing dependency and a circular one until something calls the method.

Question 8

get() vs load()

Accepted Answer

LAZY loads on first access, EAGER loads with the parent — and the defaults are not the same on both sides: @ManyToOne and @OneToOne default to EAGER, collections default to LAZY. Touching a lazy association after the session closes is LazyInitializationException, and Spring Boot's open-in-view setting hides that by keeping the session alive through rendering.

Question 9

Optimistic vs pessimistic locking

Accepted Answer

Four levels, defined by which anomalies they allow rather than by how they are built: read uncommitted permits dirty reads, read committed permits non-repeatable reads, repeatable read permits phantoms, serializable permits none. The table is about reads — the anomaly that actually loses money, the lost update, is not in it, and your database's default is probably weaker than you assume.

Question 10

What is dirty checking?

Accepted Answer

The persistence context keeps a snapshot of every entity it loads and compares it against the live object at flush time, issuing an UPDATE for anything that differs. Mutating a fetched entity is therefore a write, whether or not you called save. It also means the session holds a second copy of everything you load, and by default updates every column rather than the one you changed.

Question 11

Multiple users update the same product stock simultaneously. How would you prevent inconsistent data?

Accepted Answer

Four levels, defined by which anomalies they allow rather than by how they are built: read uncommitted permits dirty reads, read committed permits non-repeatable reads, repeatable read permits phantoms, serializable permits none. The table is about reads — the anomaly that actually loses money, the lost update, is not in it, and your database's default is probably weaker than you assume.

Question 12

Design a rate limiter.

Accepted Answer

Token bucket when bursts are acceptable, sliding window when the limit must be exact. Fixed window is the cheapest and lets through twice the limit at every window boundary. The single-machine algorithm is the easy half — the real question is where the counter lives once you have more than one instance.

Question 13

Design a user authentication system.

Accepted Answer

With a deliberately slow, salted hash — bcrypt, scrypt or Argon2, or PBKDF2 if you cannot add a dependency. SHA-256 is wrong precisely because it is fast: speed is the attacker's budget, and a database leak turns into account takeover at whatever rate your hash allows.

SDE-2 Java backend: the questions and the scenarios

Core Java

Spring Boot

Hibernate and JPA

System design

What this list is worth