Как вы оцениваете свои знания по базам данных?

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

Насколько трезво вы себя оцениваете. Любая названная оценка тут же проверяется: сказали «хорошо», значит, дальше будут уровни изоляции, EXPLAIN и N+1 в ORM. Интервьюеру важно, чтобы самооценка совпала с ответами на эти вопросы.

Как отвечать

Вместо абстрактного «хорошо» или «7 из 10» разложите знания по слоям и для каждого назовите, что делали руками. Для Python-разработчика обычно так:

• SQL: JOIN, GROUP BY с HAVING, подзапросы, CTE, оконные функции вроде ROW_NUMBER();
• индексы и планы: B-tree и составные индексы, чтение EXPLAIN ANALYZE, отличие Seq Scan от Index Scan, почему функция над колонкой мешает индексу;
• транзакции: ACID, уровни изоляции и то, что в PostgreSQL по умолчанию READ COMMITTED, блокировки, SELECT ... FOR UPDATE;
• ORM: SQLAlchemy 2.0 или Django ORM, проблема N+1 и её решение через selectinload и joinedload или select_related и prefetch_related, умение посмотреть, какой SQL реально уходит в базу;
• эксплуатация: миграции через Alembic или Django migrations, пул соединений, бэкапы;
• нереляционное: Redis для кэша и очередей, MongoDB или ClickHouse, если был опыт.

Затем честно назовите границу, например: «репликацию и партиционирование настраивал DBA, идею я понимаю, но сам не делал». Это не минус, а сигнал, что вашим «знаю» можно верить без перепроверки. Подкрепите одним своим случаем: какой запрос тормозил, что показал план, что поменяли и насколько ускорилось по вашим замерам. Если опыта мало, скажите, где вы на уровне учебных задач, а где уже работали с живой базой.

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

Ставят себе высокую оценку и сыплются на первом вопросе про изоляцию или индексы. Завышение наказывается сильнее, чем скромная, но честная оценка.

Путают знание ORM со знанием базы: «пишу модели в Django» ничего не говорит о том, понимаете ли вы, какой SQL из них получается.

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