Грейд в аналитике не апгрейд SQL. Если “следующий уровень” у вас начинается с оконных функций — выводам уже нельзя доверять.

Типичная сцена: человек быстро пишет сложные запросы, тащит красивый дашборд, и команда уверена, что это mid/senior. А потом выясняется, что метрика “плывёт”, эксперимент не читается, качество данных не контролируется, решения принимаются по шуму. Цена — недели разработки и уверенность в неправильном направлении.

Почему так происходит: сильный SQL отвечает на вопрос “как посчитать”. Грейд отвечает на вопрос “что считать, зачем, насколько этому можно верить и как это изменит решение”. На уровне mid/senior центром тяжести становятся не запросы, а артефакты и ответственность: постановка измерения, дизайн проверки гипотезы, управление качеством, коммуникация, последствия ошибок.

Минимальный стандарт, который обычно отличает mid/senior от “просто сильного исполнителя”:

1. Метрика оформлена как контракт: что входит, что не входит, какие срезы обязательны, где точка истины, какие известные ограничения.
2. Эксперименты не “запускаются”, а проектируются: единица рандомизации, guardrails, критерии остановки, риски перетекания, влияние сезонности и новизны.
3. Решение отделено от отчёта: заранее понятно, какое действие будет при каждом исходе и какой уровень неопределённости допустим.
4. Data quality — это процесс, а не жалоба: проверки на входе, мониторинг с алертами, разбор инцидентов, воспроизводимость расчётов.
5. Коммуникация со стейкхолдерами про смысл и риски: где сигнал, где шум, что можно обещать, что нельзя, и почему.

В правильной практике senior узнаваем по тому, что после него остаются не “сложные запросы”, а устойчивые измерения, повторяемые эксперименты и решения, которые можно защитить перед бизнесом и инженерами. Исключение одно: если роль чисто “репортинг по ТЗ”, тогда да, SQL может быть главным — но это обычно не про рост уровня, а про узкий контур задач.