Есть ли опыт работы с интерфейсом persistence?

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

Работали ли вы с JPA руками, а не только по туториалу. Формулировка размытая, поэтому интервьюер смотрит, уточните ли вы, о чём речь, а следом спрашивает про конкретную проблему в слое доступа к данным.

Как отвечать

Начните с уточнения: «Вы про Jakarta Persistence, то есть EntityManager и репозитории Spring Data?» Обычно имеют в виду это. Дальше каркас из трёх частей с вашими фактами:

• контекст: проект, база, стек. Например, Spring Boot 3, Hibernate 6, PostgreSQL;
• что делали: сущности с @Entity и связями, репозитории на JpaRepository, запросы через производные методы, @Query или Criteria API, транзакции через @Transactional;
• проблема и решение: здесь ответ и выигрывает. Своя история с цифрами: сколько запросов было, сколько стало, как нашли причину.

Покажите понимание механики: контекст персистентности, состояния сущности (transient, managed, detached, removed), dirty checking, из-за которого изменённая managed-сущность сохраняется без явного save. Типовые сюжеты: N+1 и его решение через JOIN FETCH или @EntityGraph, LazyInitializationException вне транзакции, пакетная вставка через hibernate.jdbc.batch_size, включённый по умолчанию spring.jpa.open-in-view.

Если опыта с JPA нет, так и скажите, но сразу покажите смежное: «В проде работал через JDBC и jOOQ, JPA знаю по учебному проекту, понимаю контекст персистентности и типовые ловушки Hibernate». Это сильнее выдуманного проекта.

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

Рассказывают шаблонную историю про «компанию X» без деталей. Первый же вопрос о том, как вы нашли медленный запрос, её разваливает.

Смешивают уровни: JPA это спецификация, Hibernate её реализация, Spring Data JPA надстройка над ними. Кто называет всё это одним словом, выдаёт поверхностный опыт.

Говорят, что работали с JPA, но не могут объяснить, почему поле сохранилось в базу без вызова save. Это вопрос про dirty checking, на нём и проверяют реальную практику.