Spring Data JPA removes the boilerplate of writing DAO classes. You declare a repository interface; at startup Spring generates a proxy implementation backed by JPA/Hibernate. You never write entityManager.persist(...) for basic CRUD.
{
Long id;
String email;
active;
}
<User, Long> {
Optional<User> ;
List<User> ;
}
Derived queries are readable for simple criteria but explode in length as conditions grow. When that happens, drop to an explicit @Query:
@Query("SELECT u FROM User u WHERE u.email = :email") // JPQL, not SQL
Optional<User> lookup(@Param("email") String email);
// Native SQL when you need DB-specific features:
@Query(value = "SELECT * FROM users WHERE active = true", nativeQuery = true)
List<User> findActiveNative();
Page<User> findByActiveTrue(Pageable pageable); // pass PageRequest.of(0, 20)
Interviewers probe whether you understand what is generated behind the interface. Strong signals: knowing derived-query keywords, choosing @Query when method names get unwieldy, using Pageable instead of loading whole tables, and being aware that lazy associations can trigger the N+1 problem — a topic they will often push into next.
A library of IT interview questions with detailed answers — from Junior to Senior.
Donate