Используете ли нативные SQL-запросы или ORM
Что проверяют
Умеете ли вы выбирать инструмент под задачу и не прячетесь ли за ORM от знания SQL. Правильный ответ почти всегда «и то, и другое, вот по каким признакам».
Как отвечать
Скажите, что оба нужны, и разложите по случаям.
ORM выигрывает там, где работа идёт с объектами и типовыми операциями: создание, чтение по идентификатору, обновление, простые выборки со связями. Экономит шаблонный код, даёт единый способ работы с транзакциями, помогает не забыть про блокировки и версии.
Нативный SQL берут, когда:
- запрос сложный: оконные функции, общие табличные выражения, рекурсия, агрегаты с несколькими уровнями группировки;
- нужен точный контроль плана и подсказок базы;
- идёт массовая операция: обновление или вставка тысяч строк одним запросом вместо потока отдельных;
- нужен отчёт, где сущности вообще не нужны, а нужен плоский набор полей.
Дальше покажите знание граблей ORM, это ценится больше всего: проблема N+1 запросов и её лечение через join fetch и @EntityGraph; ленивая загрузка вне транзакции; пакетная вставка, которая без настройки шлёт по запросу на строку; кеш первого уровня, который растёт в длинной транзакции; Page с дорогим подсчётным запросом.
Хорошая практическая формула: типовая работа с сущностями через ORM, отчёты и массовые операции через SQL, и в любом случае умение прочитать план запроса через EXPLAIN.
Где спотыкаются
Отвечают «только ORM» и не могут объяснить, какой SQL он сгенерировал.
Пишут всё на нативных запросах, теряя транзакционную обвязку и получая ручное отображение строк в объекты.
Не знают про N+1, хотя это главная причина медленных страниц в проектах на ORM.