Расскажите про опыт работы с интерфейсами взаимодействия с базой данных и их плюсы и минусы

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

Понимаете ли вы, что между кодом и базой есть слои, и умеете ли выбирать между ними осознанно. Проверяют не любовь к Hibernate, а способность сказать, где ORM мешает, и объяснить, какой SQL в итоге уходит в базу.

Как отвечать

Пройдите по слоям снизу вверх:

• JDBC это базовый уровень: DataSource, PreparedStatement, пакетная вставка, ручное управление транзакцией. Полный контроль над SQL, но много однообразного кода и ручной маппинг строк;
• JdbcTemplate и JdbcClient из Spring убирают бойлерплейт, оставляя SQL вам;
• JPA и Hibernate дают маппинг, кэш первого уровня, грязную проверку и каскады. Кода меньше, зато появляется жизненный цикл сущностей и запросы, которых вы не писали;
• Spring Data JPA поверх этого генерирует репозитории по именам методов;
• jOOQ это типобезопасный SQL из Java, MyBatis это SQL отдельно от кода с маппингом результата;
• R2DBC нужен, когда реактивен весь стек, в обычном сервисе он только усложняет.

Обязательно упомяните пул соединений и то, что его размер это не «чем больше, тем лучше»: он упирается в возможности базы.

Вывод формулируйте так: сложная доменная модель с частой записью это ORM, отчёты и массовая обработка это прямой SQL, и оба подхода спокойно живут в одном проекте.

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

Записывают уязвимость к инъекциям в минусы JDBC. Уязвима склейка строк, а не интерфейс: параметризованный запрос закрывает вопрос, и ровно та же дыра прекрасно появляется в нативном запросе через ORM.

Второе: не видят N+1. Ленивая загрузка удобна ровно до первого цикла по коллекции, и лечится она join fetch, графом сущностей или пакетной выборкой, а не отключением лени у всего подряд.

Третье: путаются в транзакциях. Вызов аннотированного метода изнутри того же класса проходит мимо прокси, LazyInitializationException вылезает за границей транзакции, а рассказ про уровни изоляции сводится к перечислению названий без единого примера аномалии.