В каком контексте вы использовали Spring Data JPA

Что проверяют

Работали ли вы с JPA дальше репозиториев с автогенерируемыми методами. Следом почти всегда спрашивают про N+1 и транзакции, так что о них стоит сказать самому.

Как отвечать

Опишите задачу и как выглядел слой доступа к данным: сущности с @Entity, репозитории поверх JpaRepository, чем пользовались из возможностей:

• методы по имени: findByUserIdAndStatus, удобно, пока имя читается;
• @Query с JPQL или нативным SQL там, где выражение сложное;
• проекции и DTO: интерфейсные проекции или конструктор в запросе, чтобы не тянуть всю сущность ради двух полей;
• пагинация и сортировка через Pageable, с оговоркой, что count-запрос на больших таблицах стоит денег;
• Specification или Querydsl для динамических фильтров.

Дальше покажите понимание подводных камней, это и есть содержание ответа:

• N+1 запросов: ленивые связи внутри цикла. Лечится join fetch, @EntityGraph или отдельным запросом. Обнаруживается логом SQL и счётчиком запросов в тестах;
• транзакции: @Transactional на сервисе, а не на репозитории, понимание того, что внутри транзакции сущность управляемая и её изменения улетают в базу без явного save;
• ленивая загрузка вне транзакции: LazyInitializationException и почему открывать сессию на весь запрос это не решение;
• пакетные операции: saveAll без настройки батчей всё равно шлёт по запросу на строку;
• миграции схемы: Liquibase или Flyway, а ddl-auto только для локальной разработки.

Где спотыкаются

Не могут объяснить разницу между save для новой и для управляемой сущности.

Ставят FetchType.EAGER на все связи и получают тяжёлые запросы вместо N+1.

Считают JPA заменой знанию SQL. На собеседовании это выясняется первым же вопросом про план запроса.