Вопросы собеса в Яндекс на аналитика 2026: 25+ реальных + разбор

Яндекс — самый длинный и техничный собес среди РФ-компаний для аналитика. 4-5 раундов, в каждом по 1-2 часа, итого 6-8 часов чистого общения растянутые на 2-3 недели. По данным Levels.fyi РФ 2026: G14 — 190K ₽/мес, G15 — 289K, G16 — 423K, G17 — 530K, G18 — 633K+. Чтобы пройти на G16+ нужно знать конкретно эти 25+ вопросов.

Я разобрал реальные вопросы с собесов в Яндекс Поиск / Маркет / Лавка / Cloud / Practicum / Музыка (по моему опыту 8 собесов 2024-2026 + публичные источники Habr/Хабр Карьера/Levels.fyi).

Грейды аналитика в Яндексе (G14-G18)

→ Подробнее о грейдах в РФ-компаниях

5 раундов собеседования в Яндекс — что в каждом

В Yandex Маркет / Поиск могут быть дополнительные раунды (data engineering вопросы, statistics deep-dive). В Яндекс Cloud — system design.

8 SQL-вопросов с собеса в Яндекс (раунд 2)

Дано: events(user_id, event_ts, action). Найди топ-5 пользователей по числу действий в марте.

✅ Сильный ответ за 60 сек:

SELECT user_id, COUNT(*) AS actions
FROM events
WHERE event_ts >= '2026-03-01' AND event_ts < '2026-04-01'
GROUP BY user_id
ORDER BY actions DESC
LIMIT 5;

Уточнения которые senior ждёт:

• «Если у двух юзеров одинаковое число действий — нужен тай-брейкер?»
• «На больших данных COUNT(*) дешевле чем COUNT(user_id)?»
• «Если events партиционирована по дате — partition pruning должен ускорить»

❌ Слабый: молча написать query без уточнений.

→ 521 SQL-задача в тренажёре с авто-проверкой

Найди процент пользователей которые совершили действие N+1 после действия N.

✅ Сильный ответ:

WITH ranked AS (
  SELECT user_id, action, event_ts,
         LEAD(action) OVER (PARTITION BY user_id ORDER BY event_ts) AS next_action
  FROM events
)
SELECT
  100.0 * COUNT(DISTINCT CASE WHEN action = 'view' AND next_action = 'click' THEN user_id END)
  / NULLIF(COUNT(DISTINCT CASE WHEN action = 'view' THEN user_id END), 0) AS view_to_click_pct
FROM ranked;

Уточнения senior:

• «Нужна window в течение какого таймфрейма? (через час, день, или любой по времени)»
• «Если юзер совершил view → view → click — считать?»
• «NULLIF — защита от деления на 0»

→ Когортный анализ retention в SQL

Найди пары пользователей которые в один день покупали один и тот же товар.

✅ Сильный ответ:

SELECT a.user_id AS user1, b.user_id AS user2,
       a.product_id, DATE(a.purchase_ts) AS day
FROM purchases a
JOIN purchases b
  ON a.product_id = b.product_id
  AND DATE(a.purchase_ts) = DATE(b.purchase_ts)
  AND a.user_id < b.user_id  -- избегаем дублей (A,B) и (B,A)

Уточнения senior:

• «Self-join даст fanout если у юзера было 3 покупки этого товара в день — нужно DISTINCT?»
• «Что если хотим только разных юзеров? user_id <> b.user_id (но a < b чище)»

→ Полный гайд по JOIN

Объясни разницу между ROWS и RANGE в window frame.

✅ Сильный ответ:

«ROWS — окно по физическим строкам. «3 строки до текущей» = именно 3 предыдущие записи.

RANGE — окно по значениям колонки ORDER BY. «3 единицы до текущей» = все строки где value между current-3 и current.

Пример: ORDER BY date.

• ROWS BETWEEN 6 PRECEDING AND CURRENT ROW = последние 7 строк (могут быть с пропусками дат)
• RANGE BETWEEN INTERVAL '6 days' PRECEDING AND CURRENT ROW = строки за последние 7 дней (учитывает gaps)»

Senior follow-up: «А что такое GROUPS?» — это менее известная третья опция: окно по группам одинаковых ORDER BY значений (PostgreSQL 11+).

→ ROWS vs RANGE vs GROUPS — глубокое погружение

У тебя таблица 500M строк по событиям. Простой COUNT(DISTINCT user_id) висит 5 минут. Что делаешь?

✅ Сильный ответ:

«Несколько подходов:

• HLL (HyperLogLog) — приближённый count с погрешностью 1-2%, работает за O(1) memory. В Яндексе обычно ClickHouse → uniq() или uniqExact().
• Materialized view — заранее считаем DAU по партициям, на runtime читаем из MV
• Sampling — если бизнес ОК на 1% погрешности, считаем на 10% юзеров и умножаем
• Partitioning + parallel — раздаём COUNT(DISTINCT) по партициям, потом union

В Яндекс Маркете на ClickHouse — точно uniq() или uniqCombined().»

→ ClickHouse практический гайд

Что такое sargable / non-sargable WHERE?

✅ Сильный ответ:

«Sargable = WHERE может использовать индекс. Non-sargable = не может.

Примеры non-sargable:

• WHERE LOWER(email) = 'x@y.com' — функция на колонке
• WHERE date_column + 1 < '2026-01-01' — арифметика
• WHERE column LIKE '%test' — leading wildcard

Sargable equivalents:

• WHERE email = LOWER('x@y.com') — функция на значении (а не на колонке)
• WHERE date_column < '2025-12-31' — перенесли арифметику в правую часть

В PostgreSQL — можно создать functional index CREATE INDEX ON users (LOWER(email)) чтобы первый вариант стал sargable.»

→ SQL антипаттерны — 10 ошибок

Recursive CTE — приведи пример из реальной задачи.

✅ Сильный ответ:

«Иерархия категорий в маркетплейсе. Таблица categories(id, parent_id, name). Нужно для каждой подкатегории найти всю цепочку до корня.

WITH RECURSIVE category_path AS (
  SELECT id, parent_id, name, name AS path, 1 AS depth
  FROM categories
  WHERE parent_id IS NULL  -- корневые

  UNION ALL

  SELECT c.id, c.parent_id, c.name,
         cp.path || ' > ' || c.name AS path,
         cp.depth + 1
  FROM categories c
  JOIN category_path cp ON c.parent_id = cp.id
)
SELECT * FROM category_path;

Возвращает: «Электроника > Телефоны > Apple > iPhone 17».»

→ Recursive CTE — гайд с примерами

Гэпы и островы (gaps and islands) — что это, пример?

✅ Сильный ответ:

«Классическая задача: найти непрерывные серии в данных.

Пример: events(user_id, login_date). Найти longest login streak для каждого юзера.

WITH streaks AS (
  SELECT user_id, login_date,
         login_date - INTERVAL '1 day' * ROW_NUMBER() OVER (PARTITION BY user_id ORDER BY login_date) AS streak_group
  FROM logins
)
SELECT user_id, streak_group, COUNT(*) AS streak_length, MIN(login_date), MAX(login_date)
FROM streaks
GROUP BY user_id, streak_group
ORDER BY streak_length DESC;

Трюк: вычитаешь ROW_NUMBER() из даты — для непрерывных серий разность константна, для разрывов — меняется.»

5 Python-вопросов с собеса в Яндекс (раунд 3)

У тебя DataFrame 50M строк, нужно посчитать DAU по неделям. RAM ограничен.

✅ Сильный ответ:

«Несколько вариантов:

• chunksize в read_csv + manual aggregation:

result = {}
for chunk in pd.read_csv('events.csv', chunksize=500_000, parse_dates=['ts']):
    chunk['week'] = chunk['ts'].dt.to_period('W')
    agg = chunk.groupby('week')['user_id'].nunique()
    for week, n in agg.items():
        result[week] = max(result.get(week, 0), n)  # упрощение

• DuckDB — SELECT date_trunc('week', ts), COUNT(DISTINCT user_id) FROM 'events.csv' GROUP BY 1 — без загрузки в память

• Polars lazy — pl.scan_csv(...).groupby_dynamic('ts', every='1w').agg(pl.col('user_id').n_unique())»

→ Polars vs Pandas — что когда

Реши классическую задачу: для каждого user_id найди топ-3 категории по сумме покупок.

✅ Сильный ответ:

result = (df
    .groupby(['user_id', 'category'])['amount'].sum()
    .reset_index()
    .sort_values(['user_id', 'amount'], ascending=[True, False])
    .groupby('user_id')
    .head(3))

Уточнения senior:

• «Что если у юзера менее 3 категорий?» → .head(3) вернёт сколько есть
• «Что если хотим только тех у кого ≥3?» → фильтр после
• «На больших данных — groupby().apply() медленнее, лучше .head() после sort»

Объясни transform vs apply в pandas.

✅ Сильный ответ:

«transform — возвращает DataFrame с той же длиной, value broadcasting на каждую строку группы. Удобно для добавления групповой статистики как новой колонки.

df['user_avg'] = df.groupby('user_id')['amount'].transform('mean')
# каждая строка получает mean своего юзера

apply — возвращает что угодно (Series, DataFrame, scalar), может менять структуру.

df.groupby('user_id').apply(lambda g: g.nlargest(3, 'amount'))
# вернёт DataFrame другой длины

Performance: transform на сильно векторизованных операциях (mean, sum, count) — быстро. apply почти всегда медленнее (Python loop под капотом).»

Реализуй sliding window: для каждой строки посчитай среднее за последние 7 дней.

✅ Сильный ответ:

df = df.sort_values('date').set_index('date')
df['ma7'] = df['amount'].rolling('7D', min_periods=1).mean()

Уточнения:

• rolling('7D') — по времени (не по строкам), нужно DatetimeIndex
• min_periods=1 — чтобы первые дни не были NaN
• Если нужно по группам: df.groupby('user_id').apply(lambda g: g['amount'].rolling('7D').mean()) (но это apply — медленно). Лучше через groupby + rolling chain.

→ Окна и время в pandas — 10 функций

У тебя 2 DataFrame: events (user, ts) и payments (user, ts). Для каждого event найди ближайший payment ПОСЛЕ event.

✅ Сильный ответ:

import pandas as pd

events = events.sort_values('ts')
payments = payments.sort_values('ts')

merged = pd.merge_asof(
    events, payments,
    on='ts',
    by='user',
    direction='forward',  # ближайший после event
    tolerance=pd.Timedelta('30D')  # не дальше 30 дней
)

Senior follow-up: «Что делает merge_asof когда нет совпадения?» → возвращает NaN. «Сложность?» → O(n log n) после sort, vs O(n²) для cross join.

5 A/B-тестов вопросов (раунд 4, часть 1)

Объясни CUPED своими словами.

✅ Сильный ответ:

«CUPED (Controlled Pre-Experiment Data) — техника снижения variance в A/B-тестах за счёт использования pre-experiment данных.

Идея: если у юзера высокая baseline activity (до эксперимента), он будет высокая и после. Variance в этой baseline переменной можно «вычесть» из experiment data.

Формула: Y* = Y - θ × (X - mean(X)), где X — pre-experiment метрика того же юзера, θ = cov(Y,X) / var(X).

Эффект: variance reduction обычно 30-50% → нужный sample size меньше в 1.5-2 раза → тесты быстрее.

В Яндексе CUPED — базовый стандарт для A/B на платформе экспериментов.»

❌ Слабый: «CUPED это снижение variance, не помню как работает.»

→ A/B-тесты на Python + scipy

Что такое SRM, как проверять, что делать если есть?

✅ Сильный ответ:

«SRM (Sample Ratio Mismatch) — расхождение между ожидаемым и наблюдаемым распределением юзеров по группам A/B.

Например, разделил 50/50, получил 51/49 на 1M юзеров — статистически значимое отклонение (chi-square p-value < 0.001).

Причины: баг в рандомизации, бот-трафик в одной группе, потеря cookies, разный crawl-rate ботов на A vs B.

Проверка:

from scipy.stats import chisquare
observed = [n_treatment, n_control]
expected = [(sum(observed) * 0.5), (sum(observed) * 0.5)]
chi2, p = chisquare(observed, expected)
print(f"SRM detected: {p < 0.001}")

Если SRM есть: результат A/B нельзя доверять. Сначала ищешь root cause, чинишь, перезапускаешь. Senior никогда не отчитывается о результате A/B без SRM-чека.»

Как обработать peeking problem?

✅ Сильный ответ:

«Peeking — преждевременное подглядывание в результат A/B до накопления sample size. Каждый peek = микро-тест, FPR накапливается. При 5 peeks с α=5% реальная FPR ~14%, при 10 — ~30%.

Решения:

• Фиксированный sample size — спланировать заранее (MDE, power), не смотреть до достижения
• mSPRT (mixture sequential probability ratio test) — Microsoft, позволяет infinite peeking с правильной коррекцией
• Pocock / O'Brien-Fleming boundaries — фиксированные alpha-spending functions для interim анализа
• Bayesian A/B — нет проблемы peeking, можно смотреть постоянно (но другая методология)

В Яндексе на платформе обычно используют mSPRT или фиксированный sample size — оба валидны.»

→ Калькулятор sample size для A/B

Как дизайнишь A/B для новой фичи которую видит 0.5% юзеров?

✅ Сильный ответ:

«Проблема: если фичу видит только 0.5% юзеров, на стандартной 50/50 split нужно огромное N для статзначимости.

Решения:

• Ограничить выборку eligible юзерами — рандомизация только среди тех 0.5%, кто видит фичу. На них split 50/50.
• CUPED — снижение variance
• Stratified sampling — стратифицировать по сегментам где фича релевантна, балансировать
• Quasi-experimental методы — DiD (difference-in-differences), synthetic control если рандомизация невозможна
• Long-run — запустить на 12+ недель, медленнее достигнуть N

Senior follow-up: «Что если в эту 0.5% попадают power users которые покрывают 30% GMV?» → нужно guardrail на business metrics + careful interpretation.»

Объясни ratio-метрику и почему стандартный t-test для неё неправильный.

✅ Сильный ответ:

«Ratio-метрика = X / Y, где X и Y — две метрики (например click-through rate = clicks / views).

Проблема: среднее ratio ≠ ratio средних. Стандартный t-test предполагает что данные нормально распределены и независимы — для ratio это часто нарушается.

Решения:

• Delta method — линеаризация ratio через Тейлора, получение скорректированной variance
• Bootstrap — non-parametric оценка variance ratio через resampling
• User-level aggregation — считать ratio на уровне юзера, потом сравнивать средние user-level ratios

# Delta method для CTR = clicks/views
def delta_variance(clicks, views):
    mean_c, mean_v = clicks.mean(), views.mean()
    ratio = mean_c / mean_v
    var_c, var_v = clicks.var(), views.var()
    cov_cv = np.cov(clicks, views)[0, 1]
    var_ratio = (var_c - 2 * ratio * cov_cv + ratio**2 * var_v) / (mean_v**2 * len(clicks))
    return ratio, np.sqrt(var_ratio)

В Яндексе на платформе экспериментов это стандарт для CTR / conversion-rate метрик.»

5 продуктовых кейсов (раунд 4, часть 2)

DAU в Яндекс.Лавке упал на 15% за неделю. Что делаешь?

✅ Сильный ответ (фреймворк):

«1. Уточняю scope:

• Все юзеры или сегмент (iOS / Android / web)?
• Все регионы или Москва/Питер?
• Когда именно упало (graph точечно)?

2. Декомпозиция:

• DAU = new users + returning users. Что упало?
• DAU = sessions / sessions_per_user. Что упало?

3. Гипотезы по приоритету:

• Технический сбой → проверяю uptime, crash rate, API errors
• Внешнее событие → новости (карантин, конкурент, погода)
• Маркетинг → траты по каналам, CAC изменился?
• Продуктовое изменение → changelog за неделю
• Аномалия данных → ETL сломан, фильтр изменился

4. Action:

• Строю dashboard 'DAU by segment, channel, platform, day'
• Подтверждаю гипотезу или иду глубже
• Если найдено — фикс или escalation
• Если не найдено — расширяю анализ на 2-я причины

5. Followup: через 7 дней — обновление статуса, learning, что добавили в monitoring.»

❌ Слабый: «Я бы посмотрел графики и поискал причину.»

→ Метрики AARRR Pirate metrics

NSM для Яндекс.Маркет — какую выберешь?

✅ Сильный ответ:

«NSM для маркетплейса должна отражать долгосрочную ценность для юзера + бизнеса.

Кандидаты:

• GMV (gross merchandise value) — но может быть надут разовыми крупными покупками
• Active buyers per month — но не учитывает retention
• Successful transactions per active buyer per quarter — учитывает и engagement, и retention, и monetization

Я бы выбрал последний + guardrail метрики:

• Margin% (NSM не должна расти за счёт скидок убивающих unit economics)
• NPS (не должны жертвовать UX ради коротких продаж)
• Time to first delivery (operational quality)

В Яндекс.Маркете публично говорят про GMV + active buyers + AOV как basic triad. NSM конкретный — внутренняя метрика.»

Конверсия из корзины в покупку упала с 65% до 58%. Что проверяешь?

✅ Сильный ответ:

«Структура:

• Funnel decomposition: add-to-cart → checkout → payment → confirm. Где именно потеря?
• Сегментация: platform / region / payment_method / price_segment. Какой сегмент просел?
• Внешние факторы: новые правила доставки, изменение цен, конкурент промо

Конкретные гипотезы для маркетплейса:

• Платёжный шлюз: error rate вырос?
• UI: А/B по новому checkout?
• Цены: конкурент дал скидку 10%, наши клиенты сравнивают
• Категории: одна категория пропустила (например исчез поставщик)
• Доставка: сроки выросли в каком-то регионе

Action: разбить fall на 'product mix change' vs 'behavioural change' — если упала однородно по всем сегментам, проблема в платформе; если в одном — проблема локальная.»

→ Воронка конверсии в SQL

Как измеришь успех новой фичи в Яндекс.Музыке?

✅ Сильный ответ:

«3 уровня метрик:

1. Adoption (узкая воронка):

• % MAU кто увидел фичу
• % увидевших кто использовал

2. Engagement (для тех кто использует):

• Frequency: сколько раз в неделю
• Depth: сколько действий за сессию

3. Impact на core metrics (главное):

• Listening time per session (плюс или минус?)
• Retention 30-day (фича удерживает или distractor?)
• NPS на cohort'е фичи vs контроль

Тест: A/B 50/50, 4 недели, primary metric = listening time per active user, guardrail = retention + crash rate.

Senior follow-up: «Что если фича каннибализирует?» → measure cross-feature dependency через correlation analysis в pre/post.»

Как ты будешь измерять каннибализацию между Яндекс.Маркет и Яндекс.Лавка?

✅ Сильный ответ:

«Каннибализация — когда новый продукт ворует выручку из существующего, а не привлекает новую.

Подходы:

• Cross-cohort analysis — юзеры активные в обоих продуктах vs только в одном. Их LTV выше или ниже?
• DiD (difference-in-differences) — сравнить рост Маркет в регионе где Лавка появилась vs регион где Лавка не доступна
• Synthetic control — построить «фейковый» Маркет если бы Лавка не появилась, сравнить с реальным
• A/B на пользователях — для группы юзеров блокировать показ Лавка-фичи в Маркет, измерить общий impact

Метрики:

• Total GMV (Маркет + Лавка) per user — главный сигнал. Если суммарный GMV растёт — это не каннибализация, а expansion.
• Per-product GMV per user — если Маркет падает а Лавка растёт суммарно меньше → каннибализация»

2 behavioral вопроса (раунд 5)

Расскажи про самую сложную аналитическую задачу за последний год.

✅ Сильный ответ (STAR):

«Ситуация: в маркетплейсе X retention для категории «Электроника» упал на 12% за 2 месяца, причина непонятна — никаких очевидных событий (релиз / маркетинг / конкурент).

Задача: найти root cause за 2 недели, рекомендация для CEO-review.

Действие:

• Декомпозировал retention на new vs returning cohorts — упали оба, returning сильнее (-18%)
• Сегментировал returning по recency (1-30 / 30-90 / 90+ days) — больше всего просел 30-90 day сегмент
• Углубился: проверил funnel этого сегмента — нашёл что checkout success rate упал с 92% до 76%
• Проверил payment_method — выяснилось что СБП-оплата перестала работать в одной из категорий из-за бага в integration
• Эскалировал в DE-команду, баг исправили за 4 часа

Результат: retention восстановился за 6 недель до baseline. Сохранили оценочно ~$3M GMV в месяц. Learning — всегда декомпозировать retention на recency-cohorts, не только new vs returning.»

→ Behavioral interview + STAR-метод

Опиши конфликт с коллегой и как разрешил.

✅ Сильный ответ:

«Ситуация: PM из соседней команды пушил решение запустить A/B без guardrail на NPS, мотивация: «нужно срочно ускорить релиз». Я был против — без guardrail могли деградировать customer experience.

Задача: убедить PM добавить guardrail без эскалации к VP.

Действие:

• Запросил 30-минутный 1-on-1 без чужих, объяснил риск на 3 примерах прошлых A/B где без guardrail сломали NPS
• Предложил compromise: запускаем A/B, добавляем NPS на dashboard, stopping criteria — если NPS падает >0.5 SD, останавливаем
• Это PM устраивало (срок не сдвигается, риск management'ится)

Результат: A/B запустили с guardrail, NPS не просел, фича вкатили в production. PM в финале сказал что это правильное решение. Я применяю этот подход во всех будущих A/B — guardrail обязателен.»

Red flags на собесе в Яндекс (не делай)

• Молчать долго — лучше попроси 30 секунд подумать вслух
• Решать без уточнений — Яндекс ценит диалог, не «гения который сразу пишет идеальный код»
• Игнорировать SRM / peeking на A/B — топ red flag для G16+
• Описывать решение без trade-offs — «есть способ X. альтернативы: Y (дороже), Z (медленнее)» — это сигнал senior thinking
• Перетягивать одеяло на behavioral («это всё я, команда не помогала») — Яндекс ценит team players
• Не упоминать конкретные цифры — «retention вырос» vs «retention вырос с 38% до 47% за 8 недель»
• Игнорировать business impact — техническое решение без связи с метрикой = слабая ответ

Как готовиться к собесу в Яндекс

Месяц 1: hard skills

• 100+ SQL задач (window-функции, top-N, gaps-islands) — наш SQL-тренажёр с 521 задачей
• 50+ Python задач на pandas (groupby, transform, merge_asof) — Python-тренажёр 532 задачи
• Прочесть статьи: Microsoft CUPED, exp-platform на peeking/SRM

Месяц 2: продуктовые кейсы + A/B

• Решать 1 кейс в день из /cases (453 кейса)
• Прочесть метрики AARRR
• Тренировать формулу декомпозиции

Неделя до собеса: behavioral + моки

• Подготовить 7 STAR-историй на главные темы
• 5+ AI мок-собесов на AI Hub (первый бесплатно)
• 1-2 paid мок с senior из индустрии если бюджет позволяет

→ Полный 30-дневный план

FAQ

Сколько готовиться к Яндексу с нуля?

6-9 месяцев если ты junior без опыта. 2-3 месяца если ты middle с опытом РФ-стартапа.

Сколько раундов после оффера?

В Яндексе оффер выдают сразу после финала. Иногда добавляют ещё 1 раунд для команды-нанимателя.

Что важнее на собесе — SQL или Python?

SQL критичнее для аналитика. Python проверяют на pandas-задачах но не на алгоритмах. Если плохо знаешь Python — можешь пройти на G14-G15, но не на G16+.

Какой грейд после внешнего собеса для middle с 3 годами опыта?

Чаще всего G15 (если опыт средний) или G16 (если опыт сильный). G14 — для junior без РФ-опыта. G17+ практически невозможно с внешнего собеса (нужны 1-2 года в Яндексе).

Какие компании в Яндексе самые сложные?

Поиск (Search Quality, ML-heavy), Маркет (большой scale, ClickHouse), Cloud (system design). Самые «простые» из Яндекса — Practicum, Музыка, Дзен.

Можно ли пересдавать если провалил?

Да, через 6-12 месяцев. Иногда дают сразу другой команде если HR видит fit.

Что насчёт оффера от других РФ-компаний после Яндекс-собеса?

Если прошёл Яндекс и получил оффер — очень легко получить оффер от Ozon/Avito/Tinkoff (они уважают Yandex bar). Если провалил Яндекс — это не значит что провалишь другие; они менее жёсткие.

Что дальше

• Тренируй на 521 SQL-задаче и 532 Python-задаче
• Пройди AI мок-собес — бесплатный первый сценарий
• Изучи 150+ вопросов собеса аналитика
• Топ-50 вопросов с разбором
• Behavioral interview + STAR
• Мок-собес: форматы и подготовка
• 30-дневный план подготовки
• Грейды аналитика Junior/Middle/Senior
• Зарплата аналитика 2026 РФ
• Подробнее о компании Яндекс → (грейды, темы, источники)

Сравнить Free и Pro → (1999 ₽/мес — безлимит мок-собесов + все задачи)

Источники

• Levels.fyi РФ 2026 (Yandex grades G14-G18, salary bands)
• Habr — статьи Яндекс-команд про hiring criteria (хабр Yandex / Yandex Practicum)
• exp-platform.com — Microsoft материалы по CUPED, peeking, SRM (адаптировано Яндексом)
• postgresql.org/docs/current — SQL features (window functions, recursive CTE)
• Yandex Practicum open lectures — методология подготовки к собесу 2026