Сколько лет опыта работы с PostgreSQL

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

Это калибровка перед основной частью. Само число никого не интересует: следом идут уточняющие вопросы, и разрыв между «пять лет» и ответом про план запроса виден сразу. Для C#-разработчика проверяют ещё и стык языка с базой, то есть как вы живёте с EF Core и Npgsql, а не только знание SQL.

Как отвечать

Назовите число честно и сразу сузьте до того, что делали руками. Удобно разложить по трём слоям.

Доступ из кода: EF Core поверх Npgsql, источник данных и пул на его стороне, Dapper или сырые запросы для горячих мест, миграции и их накат на проде.

SQL и производительность: чтение EXPLAIN (ANALYZE, BUFFERS), выбор индекса, составные и частичные индексы, GIN для jsonb и полнотекстового поиска, понимание, почему COUNT по большой таблице небыстрый.

Поведение под нагрузкой: уровни изоляции, SELECT FOR UPDATE, дедлоки и порядок захвата, autovacuum и раздувание таблиц, таймауты команд.

Если опыта мало, так и скажите с привязкой к делу: полтора года, из них год на проекте, где я разбирал планы и переделывал индексы. Это звучит сильнее округлённой пятёрки. Полезно назвать отличия от привычного многим MS SQL: MVCC вместо блокировки читателей, timestamptz и часовые пояса, регистрозависимость идентификаторов в кавычках, IDENTITY вместо автоинкремента.

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

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

Считают годы календарём, а не задачами. Пять лет через ORM без единого прочитанного плана это не пять лет опыта с PostgreSQL, и лучше сказать об этом раньше собеседника.

Не знают ловушек связки. Маппинг DateTime по его виду в timestamptz, запросы вида N плюс один из ленивых навигаций, забытый AsNoTracking на чтении, нетранслируемое выражение в фильтре, которое в свежих версиях EF Core падает исключением, а не выполняется молча в памяти.