Как дела с SQL

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

Это приглашение оценить себя, и оценку сразу проверят. Интервьюер слушает, называете ли вы конкретные вещи, а не «уверенно владею». Следом почти всегда дают живую задачу: написать запрос с JOIN и группировкой, прочитать EXPLAIN или объяснить уровни изоляции.

Как отвечать

Отвечайте на своих примерах и честно обозначьте границу знаний. Удобный каркас:

• что пишете руками: соединения, GROUP BY с HAVING, подзапросы и CTE, оконные функции (ROW_NUMBER, LAG, накопительные суммы), upsert через ON CONFLICT;
• производительность: читаете EXPLAIN ANALYZE, отличаете Seq Scan от Index Scan, знаете про составные и частичные индексы и понимаете, почему WHERE lower(email) = ... не берёт обычный индекс;
• транзакции: уровни изоляции (в PostgreSQL по умолчанию READ COMMITTED), SELECT ... FOR UPDATE, дедлоки и как их избегать единым порядком блокировок;
• Go-сторона: database/sql или pgx с pgxpool, sqlx или sqlc для генерации кода по запросам, GORM, если он был в проекте. Миграции через goose или golang-migrate;
• детали драйвера: QueryContext с таймаутом, обязательные defer rows.Close() и проверка rows.Err(), sql.ErrNoRows как отдельный случай, настройки пула SetMaxOpenConns и SetConnMaxLifetime.

Цифры и истории берите свои: какой запрос ускоряли, с какого времени до какого, чем мерили. Если опыта мало, скажите прямо: «писал CRUD и простые отчёты через pgx, оконные функции знаю по задачам, в проде не применял». Это лучше, чем громкое «отлично» и провал на первом LEFT JOIN.

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

Называют себя сильными в SQL, а знают только GORM. На просьбе написать запрос без ORM или объяснить, какой SQL сгенерировался и откуда в нём N+1, разговор заканчивается.

Собирают запрос через fmt.Sprintf с пользовательскими данными. Для Go-разработчика это красный флаг: параметры передаются плейсхолдерами, $1 в PostgreSQL и ? в MySQL.

Кладут условие на правую таблицу LEFT JOIN в WHERE и не замечают, что соединение превратилось во внутреннее. Такое условие нужно переносить в ON.