Писали ли вы код с использованием JDBC напрямую

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

Знаете ли вы, что происходит под ORM, или ваш максимум это аннотации над сущностью. Вопрос помечен как разговор об опыте, но по ответу сразу виден уровень: кто работал с JDBC руками, тот понимает соединения, транзакции и курсоры, а не только методы репозитория.

Как отвечать

Скажите, где это было и зачем: служебные и миграционные утилиты, пакетная загрузка, отчёты со сложным SQL, который в ORM выглядит хуже, чем в чистом виде. Дальше опорные вещи:

• соединения берутся из пула, DriverManager прямо в коде сервиса годится для примера, в приложении используется DataSource;
• PreparedStatement вместо склейки строк: это и защита от внедрения SQL, и переиспользование плана запроса;
• try-with-resources на соединение, выражение и результат: незакрытое соединение не возвращается в пул, и приложение встаёт на исчерпании пула;
• транзакция явная: setAutoCommit(false), commit в конце, rollback в обработчике, уровень изоляции выбран осознанно;
• пакетные операции через addBatch и executeBatch вместо вставки построчно;
• SQLException разбирается по коду состояния, а не гасится печатью стека.

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

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

Отвечают «нет, у нас Hibernate» и закрывают тему. Ждут не факта, а понимания: что такое пул, когда открывается транзакция, что делает ленивая загрузка в момент, когда сессия уже закрыта.

Второе: печатают стек вместо обработки. В проде такой обработчик означает молча потерянные данные: транзакция не откачена, а вызывающий код считает операцию успешной и идёт дальше.

Третье: собирают запрос конкатенацией с параметром, пришедшим от пользователя. Это классическое внедрение SQL, и на собеседовании такой фрагмент показывают в коде специально, чтобы посмотреть, заметите ли вы его.