Опишите, что вы делали: описывали структуру или хранение в базе данных
Что проверяют
Глубину участия. Интервьюер хочет понять, проектировали ли вы схему и отвечали за неё, или писали запросы и сущности поверх готовой модели. Оба ответа нормальны, врать бессмысленно: разница вылезает на первом же уточнении про типы и индексы.
Как отвечать
Скажите прямо, где были вы: спроектировал схему с нуля, добавлял таблицы и миграции в существующую, или только писал запросы. Дальше покажите мышление.
Сущности и связи, естественный ключ против суррогатного, где нормализовали, а где сознательно продублировали данные ради чтения. Типы колонок: время с зоной вместо времени без неё, numeric для денег вместо чисел с плавающей точкой, перечисления через справочную таблицу или тип. Ограничения: not null, уникальные индексы, внешние ключи, проверочные условия. Индексы под конкретные запросы, а не на всякий случай, и что показывает план запроса.
Обязательно про эксплуатацию: миграции через Flyway или Liquibase, как добавляли колонку без простоя, как выкатывали переименование в два шага, как бэкофилили большую таблицу порциями.
Где спотыкаются
Приносят результат в процентах из ниоткуда: запросы стали быстрее на треть. Если нечем подтвердить, как мерили и что было до, цифра работает против вас. Честнее сказать качественно: по плану ушёл последовательный скан, появился поиск по индексу.
Второе: заявляют проектирование, но не могут назвать типы колонок и состав индексов. Именно туда уходит разговор, и общие слова про нормализацию его не спасают.
Третье: описывают только аннотации Hibernate, не понимая, какой DDL из них получится. Отсюда связи с жадной загрузкой, отсутствующие индексы на внешних ключах и классический N+1, который находят уже в проде.