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

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

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

Как отвечать

Возьмите свой проект и пройдите по нему:

• контекст: домен, СУБД (в Go-командах чаще всего PostgreSQL), объём данных и нагрузка в реальных цифрах;
• модель: сущности, связи, ключи. Где держали третью нормальную форму, а где сознательно денормализовали ради чтения. Типы: bigint identity или uuid для ключей, numeric для денег, timestamptz для времени, jsonb для редких атрибутов без жёсткой схемы;
• целостность: внешние ключи, UNIQUE, CHECK, NOT NULL, то есть правила в базе, а не только в Go-коде;
• индексы: под какие запросы, составные с учётом порядка колонок, частичные. Как проверяли через EXPLAIN ANALYZE;
• слой в Go: pgx или database/sql, запросы руками или генерация через sqlc, пул соединений, транзакции с defer tx.Rollback(ctx) сразу после Begin, уровень изоляции и SELECT ... FOR UPDATE там, где нужны блокировки;
• миграции: goose или golang-migrate, изменения в несколько шагов: добавить колонку, заполнить пачками, переключить код, убрать старое.

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

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

Отвечают теорией про нормальные формы и ACID без единого примера из своего проекта. Вопрос про опыт, и теория без него звучит заученно.

Называют проценты ускорения без контекста: «стало быстрее на 40%» ничего не значит, пока не ясно, что и как мерили.

Забывают про жизнь схемы после первого релиза. Например, не знают, что CREATE INDEX без CONCURRENTLY блокирует запись в таблицу на всё время построения, а на большой таблице это минуты простоя.