Отличный запрос 👍 Ниже — **краткий, но очень ценный блок: что ИМЕННО учитывать на SQL-собеседовании**, помимо правильного синтаксиса. Это то, на чём **реально валят кандидатов**, даже если запрос написан верно. --- # 🧠 PostgreSQL — что учитывать на собеседовании (очень важно) ## 🔹 1. Проговаривай ход мысли (ВСЕГДА) Интервьюеру важнее **как ты думаешь**, а не скорость печати. ❌ Плохо: > *(молча пишет запрос)* ✅ Хорошо: > «Сначала отфильтруем данные, потом сгруппируем, после этого применим агрегат…» --- ## 🔹 2. Всегда уточняй формулировку задачи Перед написанием запроса: * нужно ли учитывать `NULL`? * нужны ли дубликаты? * нужны ли пользователи **без** записей? * важна ли производительность? Пример: > «Нужно показывать пользователей без заказов или только с заказами?» --- ## 🔹 3. NULL — главный источник ошибок Интервьюеры **почти всегда ждут**, что ты упомянешь это. Помни: ```sql = NULL -- ❌ IS NULL -- ✅ COUNT(col) -- не считает NULL ``` Хорошая фраза: > «Если поле может быть NULL, это нужно обработать через COALESCE» --- ## 🔹 4. WHERE vs HAVING — классическая ловушка Если есть агрегаты: * `WHERE` → до `GROUP BY` * `HAVING` → после Интервьюер ждёт, что ты **осознанно выберешь**. --- ## 🔹 5. JOIN: ON ≠ WHERE Очень частый вопрос. ```sql LEFT JOIN orders o ON ... WHERE o.id IS NOT NULL ``` 👉 превращает `LEFT JOIN` в `INNER JOIN` Хорошая фраза: > «Фильтрацию, влияющую на JOIN, нужно делать в ON» --- ## 🔹 6. EXISTS vs IN — нужно хотя бы упомянуть Не обязательно писать идеально оптимально, но: > «Для проверки наличия я бы предпочёл EXISTS, он лучше масштабируется» Это **плюс к оценке**. --- ## 🔹 7. GROUP BY: что можно писать, а что нельзя Нельзя: ```sql SELECT name, COUNT(*) FROM users GROUP BY city; ``` Можно: * агрегаты * поля из `GROUP BY` Фраза: > «Все неагрегированные поля должны быть в GROUP BY» --- ## 🔹 8. Оконные функции — покажи, что понимаешь разницу Важно **словами**: > «GROUP BY схлопывает строки, а оконные функции оставляют их» Если ты это сказал — ты уже **выше среднего уровня**. --- ## 🔹 9. Производительность — без фанатизма Не нужно: * придумывать индексы без запроса * оптимизировать микросекунды Но нужно: > «На больших таблицах здесь может быть Seq Scan, я бы проверил EXPLAIN» --- ## 🔹 10. CTE — не панацея Многие ошибаются, думая что `WITH` всегда ускоряет. Правильно: > «CTE улучшает читаемость, но в PostgreSQL может быть оптимизационным барьером» --- ## 🔹 11. UNION vs UNION ALL — всегда выбор осознанный Фраза: > «Если дубликаты допустимы, лучше UNION ALL — он быстрее» --- ## 🔹 12. RETURNING — приятный бонус Если используешь PostgreSQL: > «Я бы использовал RETURNING, чтобы сразу получить вставленные данные» Показывает знание **специфики СУБД**. --- ## 🔹 13. Ошибки — это нормально Если запутался: > «Я сейчас исправлю, логика такая-то…» ❌ Плохо — молчать ✅ Хорошо — думать вслух --- ## 🔹 14. Лучше простой правильный запрос, чем “умный” ❗ Интервьюер **не ждёт идеального SQL**. Он ждёт: * корректность * читаемость * понимание --- ## 🔹 15. Золотая формула ответа На любой SQL-вопрос: > **Что нужно получить → Как → Почему так** Если ты это соблюдаешь — ты выглядишь **уверенно и профессионально**. --- # 🎯 Итог Если ты: * проговариваешь мысли * учитываешь NULL * понимаешь JOIN / GROUP BY / оконные функции * не паникуешь ➡️ **ты уже конкурентоспособен на middle-уровень**. --- Если хочешь, следующим шагом могу: * 🔥 провести **симуляцию SQL-собеседования** * 🔥 дать **типичные вопросы интервьюеров + правильные формулировки** * 🔥 разобрать **частые фейлы кандидатов** * 🔥 подготовить **чеклист “что сказать вслух”** Скажи, **какой формат дальше** и **на какой уровень** 🚀