Приходилось ли профилировать SQL-запросы и анализировать их выполнение
Что проверяют
Умеете ли вы найти медленный запрос и прочитать план, а не менять код наугад. И понимаете ли, что в Java-приложении виноват чаще не сам SQL, а то, как его порождает ORM: сотня мелких запросов вместо одного заметна только в логе, потому что каждый по отдельности выглядит быстрым.
Как отвечать
Разложите на шаги. Сначала найти виновника: pg_stat_statements, лог медленных запросов, метрики мониторинга, включённое логирование SQL и времени выполнения на стороне Hibernate. Потом посмотреть план: explain (analyze, buffers) в Postgres, explain analyze в MySQL. В плане важны три вещи: расходится ли оценка числа строк с фактом, какой выбран способ доступа, и не уходит ли сортировка на диск.
Дальше по причинам: нет подходящего индекса, условие неселективно, функция над колонкой мешает использовать индекс, поиск по подстроке с ведущим шаблоном, устаревшая статистика.
Добавьте то, что отличает Java-кандидата: проблема лишних запросов на ленивых связях и лечение через join fetch или граф сущностей, пакетные вставки, выборка проекции вместо всей сущности, размер выборки у курсора. Скажите и про пул соединений: ожидание свободного соединения выглядит в метриках ровно как медленный запрос, хотя база в это время свободна.
Где спотыкаются
Называют красивую цифру ускорения, но не могут описать узкое место. Первый же уточняющий вопрос про план разваливает такой рассказ, и вместо плюса кандидат получает минус к доверию ко всему остальному.
Второе: смотрят план без фактического выполнения и верят оценкам. Оценка строится на статистике, а она устаревает, и после её обновления план нередко оказывается совсем другим.
Третье: вешают индекс на каждую колонку из условия. Индексы замедляют запись, занимают место и конкурируют между собой, а под сложное условие обычно нужен один составной, причём порядок колонок в нём решает всё.