Hibernate, JPA & Database Interview Prep

Database persistence is the backbone of every business application, and interviewers use JPA/Hibernate questions to test whether you understand what is happening beneath Spring Data's magic repository methods. The N+1 problem, LazyInitializationException, and @Transactional misuse are the three most cited production bugs in Java applications — freshers who understand them stand out immediately. Knowing the difference between JPA (specification) and Hibernate (implementation) also signals architecture awareness.

• ORM = maps Java class fields to database table columns; you work with objects, the ORM generates SQL
• JPA = the specification (javax/jakarta.persistence); Hibernate = the most popular JPA implementation
• EntityManager = the JPA interface for CRUD operations; Spring wraps this behind JpaRepository
• Persistence Context = a first-level cache that tracks entity state within a transaction
• Entity states = Transient (new, not tracked) → Persistent (tracked by context) → Detached (was tracked, tx ended) → Removed (marked for delete)
• @OneToMany / mappedBy = the mappedBy side is NOT the owner; the owning side holds the foreign key column
• LAZY = load related data only when accessed; EAGER = load immediately with the parent query
• N+1 problem = 1 query to load N parents, then N queries to load each parent's children — fetch join or @EntityGraph solves it
• @Transactional = wraps a method in a database transaction; REQUIRED propagation joins an existing tx or starts a new one

• jpa-basics-and-orm-concepts — drill: ORM benefit, entity states and what triggers each transition, EntityManager vs Spring Data repository
• entity-mapping-annotations — drill: @Entity + @Id is minimum, @GeneratedValue strategies (IDENTITY is most common for MySQL/PostgreSQL), @Column nullable/unique
• jpa-relationships — drill: @OneToMany with mappedBy on the non-owner side; @ManyToOne on the child is the owning side; cascade ALL vs specific types
• spring-data-repositories — drill: JpaRepository extends PagingAndSortingRepository extends CrudRepository; derived query naming rules
• jpql-and-derived-queries — drill: JPQL uses entity/field names not table/column names; Pageable for pagination
• transactions-basics — drill: @Transactional default propagation = REQUIRED; checked exceptions do NOT trigger rollback by default
• lazy-vs-eager-loading — drill: @OneToMany default = LAZY; @ManyToOne default = EAGER; LazyInitializationException = access after tx closed
• comparisons — drill: JPA vs Hibernate, JPQL vs SQL, LAZY vs EAGER with N+1 implications
• scenario-based — drill: fix LazyInitializationException (open session in view or @EntityGraph or DTO projection), N+1 fix

• "What is the difference between JPA and Hibernate?" → JPA is the specification; Hibernate is the implementation; Spring Boot auto-configures Hibernate as the JPA provider
• "What is the N+1 problem?" → Loading 100 orders then triggering 100 separate queries for each order's items — fix with JOIN FETCH or @EntityGraph
• "What is LazyInitializationException?" → Accessing a LAZY collection after the persistence context (transaction) is closed; fix: extend tx scope, use DTO projection, or @EntityGraph
• "Which side owns a @OneToMany relationship?" → The @ManyToOne side (child, holds the FK column) owns it; @OneToMany with mappedBy is the inverse side
• "What is @Transactional default propagation?" → REQUIRED — joins existing transaction if one exists, starts a new one if not

"In my Spring Boot projects I use Spring Data JPA with Hibernate as the JPA provider. I annotate entity classes with @Entity and @Id, map relationships with @OneToMany and @ManyToOne, and write queries using derived method names or @Query JPQL. I'm careful about LAZY vs EAGER loading — I keep collections LAZY and use @EntityGraph or JOIN FETCH when I need the related data in a specific query to avoid the N+1 problem. I annotate service methods with @Transactional to ensure that operations run atomically and roll back on failure."

SQL interview questions are unavoidable in any backend interview — joins (inner, outer, cross, self), subqueries vs joins, window functions, indexes (B-tree vs hash, when an index hurts), the EXPLAIN plan, transaction isolation levels, ACID, normalization, sharding, partitioning, replication, connection pooling, and migration tools (Flyway, Liquibase). This page covers cross-database SQL fundamentals plus the operational questions that decide a senior interview. For Postgres-specific deep dives (window functions, JSONB, MVCC, partitioning), use the dedicated PostgreSQL page; for MongoDB, see the MongoDB page; for Redis, see the Redis page.

Three lenses senior interviews probe:

• Query model — joins, subqueries, CTEs, window functions.
• Storage / index model — B-tree default, hash for equality, partial / covering indexes.
• Concurrency model — ACID + isolation levels (read-committed default in PG, repeatable-read default in MySQL InnoDB).

EXPLAIN is your evidence. Always read the plan, not the SQL.

The interview surface for this module breaks into these focus areas:

• Advanced sql features — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Backup recovery — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Comparisons — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Connection pooling — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Database migrations — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Indexes and performance — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Joins and subqueries — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Partitioning and sharding — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Query optimization — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Replication — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Sql fundamentals — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Transactions and acid — drill the named patterns, the failure modes, and the recommended Java / framework idiom.
• Scenario-based — applied questions tying multiple topics together. Drill these last, after the fundamentals are sharp.

• Index doesn't help when — WHERE func(col), leading wildcard LIKE '%x', mismatched types, low selectivity.
• N+1 at the SQL layer is solved with JOIN or `IN (subquery)` — or aggregation in DB, not app.
• Phantom reads / lost updates — name them with the isolation level that prevents each.
• Sharding is a reorg, not an optimisation; mention it when read replicas + indexes have run out.
• Connection pooling — HikariCP defaults are fine; size = connections × instances against DB max.

"I'd write the query, run `EXPLAIN ANALYZE`, look for on the hot path, fix it with , and only after the query is tight do I think about ."