Занимался ли проектированием баз данных

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

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

Как отвечать

Возьмите один проект и пройдите по решениям, которые принимали:

• сущности и связи: какие таблицы, где один-ко-многим, где многие-ко-многим через связующую таблицу;
• нормализация: обычно до третьей нормальной формы, и отдельно, где сознательно денормализовали ради чтения (счётчик, снимок цены в заказе);
• ключи и типы: bigint identity или UUID и почему, numeric для денег, timestamptz для времени, jsonb там, где структура правда плавает;
• ограничения: NOT NULL, UNIQUE, CHECK, внешние ключи с осознанным ON DELETE. Целостность держит база, а не только валидация в Pydantic;
• индексы: от реальных запросов, включая индексы на внешние ключи, которые PostgreSQL сам не создаёт;
• миграции: Alembic с SQLAlchemy 2.0 (Mapped, mapped_column) или makemigrations в Django. Автогенерацию Alembic проверяют глазами, а на большой таблице индекс создают через CREATE INDEX CONCURRENTLY.

Покажите и связь с кодом: как избегали N+1 через selectinload в SQLAlchemy или select_related и prefetch_related в Django.

Цифры приводите только свои и такие, которые сможете объяснить: объём таблиц, время запроса до и после индекса. Если сами схему не проектировали, скажите прямо: работали с готовой, писали миграции, добавляли индексы. Затем предложите разобрать, как спроектировали бы схему под их задачу.

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

Пересказывают нормальные формы без своего примера или приносят проценты из шаблона. На вопросе «как вы это измеряли?» такой ответ разваливается.

Выдают за проектирование описание моделей в ORM, не зная, какой SQL и какие индексы из них получились.

Хранят деньги во float, время без часового пояса, а целостность проверяют только в коде. Первая же гонка или ручная правка в базе оставляет мусор.