Проектировали ли структуру баз данных?

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

Проектировали ли вы схему сами или получали готовую от архитектора. За вопросом идут уточнения: почему такие ключи, где индексы, как жили с миграциями и что делали, когда данные перестали помещаться в задуманную модель.

Как отвечать

Пройдите путь от требований к таблицам, а не пересказывайте нормальные формы.

• Сущности и связи. Что хранится, где связь один ко многим, где многие ко многим, где нужна история изменений, а где достаточно текущего состояния.
• Ключи и типы. Естественный ключ против суррогатного, bigint против uuid (случайный uuid портит локальность вставки в btree), деньги в numeric, время в timestamptz.
• Целостность в базе, а не только в коде. Внешние ключи, not null, уникальные и частичные индексы. Приложений рядом с базой обычно больше одного.
• Индексы под запросы. Составной индекс строится под порядок условий, под сортировку с фильтром нужен свой. Лишний индекс замедляет запись.
• Миграции. Версионируются Flyway или Liquibase, накатываются отдельно от выкладки, поле на большой таблице добавляется без default и бэкофиллится пачками.

Для Java добавьте, как схема легла на JPA: где стоит ленивая загрузка, где пришлось уйти от сущностей к проекциям, где Hibernate давал N+1 и что с этим сделали.

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

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

Отдают схему Hibernate и держат на боевом контуре режим автообновления схемы. Такая схема необратима, не проходит ревью и молча расходится между стендами.

Приносят цифры из воздуха. Фраза о том, что производительность выросла на тридцать процентов, без замера до и после и без описания конкретного запроса вызывает ровно один вопрос, на котором история и рассыпается.