Перейти к содержимому
850 вакансий · 30+ компаний
Образование 5 мин чтения

Вопросы на собеседовании в Яндекс: 50+ примеров с ответами (2026)

Вопросы на собеседовании в Яндекс: 50+ примеров с ответами (2026)

Собеседование в Яндексе — это не один разговор с HR, а многоэтапный отбор, где на каждом шаге проверяют разное: мотивацию, алгоритмическое мышление, архитектурный подход, умение работать в команде и объяснять решения. Процесс может занять от нескольких недель до пары месяцев, поэтому лучше заранее понимать всю воронку целиком, а не готовиться к каждому этапу вслепую.

Ниже — полный разбор процесса найма в Яндекс: этапы, реальные задачи для разработчиков, типовые вопросы для аналитиков, QA и менеджеров, подготовка по неделям, частые ошибки и FAQ.

Важно: конкретный набор этапов зависит от роли, уровня, бизнес-юнита и команды. Для одних вакансий процесс может быть короче, для других — включать дополнительные технические секции, тестовые задания или несколько интервью подряд.

Как устроен процесс отбора в Яндексе: 5 этапов

Яндекс использует достаточно стандартизированную воронку найма для многих позиций. В среднем процесс занимает от 3 до 8 недель, в зависимости от команды, сезона, срочности найма и количества кандидатов.

ЭтапФорматДлительностьЧто оценивают
HR-скринингЗвонок / видео20–30 минутМотивация, базовый опыт, ожидания по зарплате
Техническое интервью — алгоритмыВидео + общий редактор кода60–90 минутРешение 1–2 задач, объяснение сложности, читаемость кода
Техническое интервью — System DesignВидео60–90 минутАрхитектурное мышление, знание компонентов, умение расставлять приоритеты
Встреча с командойВидео / очно45–60 минутКультурное соответствие, коммуникация, поведенческие компетенции
Финальное интервьюВидео / очно30–60 минутИтоговое решение, оффер, переговоры об условиях

На части вакансий отдельные этапы могут объединяться или, наоборот, разбиваться на несколько секций. Например, System Design чаще встречается у middle- и senior-кандидатов, а для стажёров и junior-ролей процесс обычно короче.

Этап 1 — HR-скрининг

HR обычно выходит на связь в течение 3–7 рабочих дней после отклика. Это может быть звонок или сообщение в мессенджере. На этом этапе не проверяют глубоко техническую часть — важнее чётко ответить на три вещи: почему Яндекс, какой опыт у вас релевантен роли и какие у вас ожидания по зарплате и формату работы.

Если отказ происходит здесь, это чаще всего связано не со «слабостью кандидата», а с тем, что профиль не совпал с базовыми требованиями вакансии, стеком команды или уровнем позиции.

Этап 2 — алгоритмическое интервью

Это один из самых важных этапов для разработчиков. Кандидат и интервьюер работают в общем онлайн-редакторе, обычно без привычного IDE и автодополнения. Язык программирования, как правило, можно выбрать самому.

На алгоритмическом интервью оценивают не только правильность решения, но и ход мышления. Очень важно проговаривать логику вслух, уточнять граничные условия до начала написания кода и объяснять временную и пространственную сложность решения.

Хорошая базовая схема ответа на алгоритмической секции выглядит так:

  1. Коротко переформулировать задачу своими словами.
  2. Уточнить ограничения: размер входных данных, допустимые значения, формат ответа, нужно ли оптимальное решение.
  3. Озвучить наивный подход и объяснить его сложность.
  4. Перейти к более эффективному решению и объяснить, почему оно лучше.
  5. Писать код частями, проговаривая логику.
  6. Проверить решение на обычных и граничных примерах.
  7. В конце явно назвать time complexity и space complexity.

Этап 3 — System Design

Этот этап обычно обязателен для middle- и senior-позиций. Интервьюер предлагает спроектировать систему вроде URL-shortener, чатов, рекомендательной ленты или похожего высоконагруженного сервиса.

Здесь не ждут «идеальной архитектуры из учебника». Ключевое — умеете ли вы задавать правильные уточняющие вопросы, видеть узкие места, обсуждать компромиссы и приоритизировать решения.

Этап 4 — встреча с командой

Обычно это разговор с будущим менеджером и одним-двумя коллегами. Основа этапа — поведенческие вопросы и оценка того, как вы будете вписываться в команду. Здесь проверяют коммуникацию, отношение к обратной связи, реакцию на неопределённость и стиль взаимодействия.

Этап 5 — финальное интервью

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

Как отличается собеседование в Яндексе по уровням

Хотя общий каркас процесса похож, наполнение интервью заметно зависит от уровня кандидата.

УровеньНа что делают основной акцент
Стажёр / JuniorБазовые алгоритмы, структуры данных, аккуратность мышления, способность учиться и объяснять решение
MiddleАлгоритмы, практическое программирование, уверенное объяснение решений, базовый или упрощённый System Design
SeniorСложные архитектурные компромиссы, ownership, глубина технических решений, лидерство и влияние на команду
Manager / PMПродуктовое мышление, приоритизация, метрики, коммуникация со стейкхолдерами, работа в условиях неопределённости

Технические вопросы и задачи для разработчиков

На алгоритмических секциях в Яндексе регулярно встречаются задачи на массивы, строки, графы, кеши и базовые структуры данных. Ниже — несколько типовых примеров с решениями и кратким разбором.

Задача 1. Два числа с заданной суммой

Дан список целых чисел и число target. Нужно найти индексы двух элементов, сумма которых равна target. Гарантируется, что решение существует.

def two_sum(nums: list[int], target: int) -> list[int]:
    seen: dict[int, int] = {}
    for i, num in enumerate(nums):
        complement = target - num
        if complement in seen:
            return [seen[complement], i]
        seen[num] = i
    raise ValueError("No valid pair found")

Сложность — O(n) по времени и O(n) по памяти. Наивное решение через два вложенных цикла даёт O(n²), и обычно интервьюер ждёт, что кандидат сам перейдёт к хеш-таблице.

Задача 2. Максимальная подстрока без повторяющихся символов

Нужно вернуть длину самой длинной подстроки без повторяющихся символов.

def length_of_longest_substring(s: str) -> int:
    char_index: dict[str, int] = {}
    left = 0
    max_len = 0

    for right, char in enumerate(s):
        if char in char_index and char_index[char] >= left:
            left = char_index[char] + 1
        char_index[char] = right
        max_len = max(max_len, right - left + 1)

    return max_len

Здесь используется паттерн sliding window. Сложность — O(n) по времени. Частый follow-up от интервьюера: что изменится, если строка приходит как поток и не помещается целиком в память.

Задача 3. LRU Cache

Нужно реализовать LRU-кеш с методами get и put за O(1).

from collections import OrderedDict

class LRUCache:
    def __init__(self, capacity: int):
        if capacity <= 0:
            raise ValueError("Capacity must be positive")
        self.cache = OrderedDict()
        self.capacity = capacity

    def get(self, key: int) -> int:
        if key not in self.cache:
            return -1
        self.cache.move_to_end(key)
        return self.cache[key]

    def put(self, key: int, value: int) -> None:
        if key in self.cache:
            self.cache.move_to_end(key)
        self.cache[key] = value
        if len(self.cache) > self.capacity:
            self.cache.popitem(last=False)

На интервью интервьюер может отдельно попросить реализацию без OrderedDict — через двусвязный список и хеш-таблицу. К такому усложнению лучше быть готовым.

Задача 4. Количество островов

Дана матрица из символов ‘1’ и ‘0’. Нужно посчитать количество островов.

def num_islands(grid: list[list[str]]) -> int:
    if not grid or not grid[0]:
        return 0

    rows, cols = len(grid), len(grid[0])
    count = 0

    def dfs(r: int, c: int) -> None:
        if r < 0 or r >= rows or c < 0 or c >= cols or grid[r][c] != '1':
            return
        grid[r][c] = '0'
        for dr, dc in ((1, 0), (-1, 0), (0, 1), (0, -1)):
            dfs(r + dr, c + dc)

    for r in range(rows):
        for c in range(cols):
            if grid[r][c] == '1':
                dfs(r, c)
                count += 1

    return count

Сложность — O(m × n). Этот вариант изменяет исходную матрицу. Если по условию входные данные нельзя модифицировать, нужно использовать отдельный массив visited или set с посещёнными координатами.

После базового решения интервьюер может спросить, как адаптировать подход, если вся матрица не помещается в память или если нужно обрабатывать данные кусками.

System Design: как отвечать на архитектурные вопросы

System Design в Яндексе — это не тест на идеальную схему, а проверка архитектурного мышления. Почти любую задачу на проектирование удобно раскладывать по одной и той же логике.

  1. Сначала уточнить требования. Сколько пользователей, какая нагрузка, какая допустимая задержка, нужны ли транзакции, насколько критична потеря данных.
  2. Дать оценочные цифры. Даже грубые расчёты помогают понять порядок нагрузки и выбрать реалистичные компоненты.
  3. Нарисовать high-level архитектуру. Например: API → Load Balancer → Application Servers → Cache → DB.
  4. Провалиться в узкие места. Где bottleneck, как масштабировать, как обеспечивать отказоустойчивость, нужен ли CDN, где кешировать.

Пример: если вам дают задачу спроектировать ленту новостей, хороший ответ обычно включает разные сценарии записи и чтения, кеширование, отдельный ML-слой ранжирования и обсуждение того, когда лучше использовать push-модель, а когда pull-модель.

В System Design интервьюер почти всегда оценивает не полноту списка технологий, а качество вопросов, компромиссов и аргументации. Лучше простая, но логичная архитектура, чем сложная схема без объяснений.

Что оценивают интервьюеры у разработчиков

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

  • уточняет ли кандидат граничные случаи до начала решения
  • проговаривает ли мысли вслух, а не уходит в молчание
  • может ли объяснить сложность решения
  • видит ли альтернативные подходы
  • замечает ли ошибки сам до подсказки интервьюера
  • умеет ли проверять решение на примерах и крайних кейсах

Вопросы на собеседовании для аналитиков данных в Яндексе

Интервью для аналитиков в Яндексе обычно состоит из двух основных частей: SQL и продуктовые кейсы. Часто добавляется блок по статистике, A/B-тестам и интерпретации метрик.

SQL — типичные задачи

Найдите пользователей, совершивших покупку каждый месяц квартала:

SELECT user_id
FROM orders
WHERE order_date >= '2024-01-01'
  AND order_date < '2024-04-01'
GROUP BY user_id
HAVING COUNT(DISTINCT DATE_TRUNC('month', order_date)) = 3;

Рассчитайте скользящее среднее выручки за последние 7 наблюдений:

SELECT
    order_date,
    revenue,
    AVG(revenue) OVER (
        ORDER BY order_date
        ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
    ) AS rolling_avg_7d
FROM daily_revenue
ORDER BY order_date;

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

SELECT department_id, salary
FROM (
    SELECT
        department_id,
        salary,
        DENSE_RANK() OVER (PARTITION BY department_id ORDER BY salary DESC) AS rnk
    FROM employees
) ranked
WHERE rnk = 2;

На SQL-секции важно не просто написать запрос, но и объяснить, почему вы выбрали именно этот подход. Например, в чём разница между DENSE_RANK, RANK и ROW_NUMBER и как они ведут себя на дубликатах.

Отдельный плюс — если вы замечаете нюансы формулировки. Например, запрос со скользящим средним выше считает среднее по 7 строкам. Если в данных есть пропуски по датам, это уже не совсем то же самое, что среднее по 7 календарным дням.

A/B-тесты и продуктовые метрики

Типичный вопрос выглядит так: «CTR упал на 10% за неделю. Что вы будете делать?» Хороший ответ начинается не с гипотезы, а с проверки качества данных: нет ли проблем с трекингом, не изменилась ли выборка, не было ли релиза или внешнего фактора. Затем идёт сегментация по платформам, гео, устройствам, каналам и только после этого — гипотезы и проверка причин.

По A/B-тестированию могут спросить: как считать размер выборки, что такое p-value, почему недостаточно смотреть только на него, что делать с множественными проверками и можно ли запускать фичу, если тест дал p=0.04.

Продуктовые кейсы для аналитиков

Пример вопроса: «Как измерить успех новой фичи поиска в Яндекс.Маркете?»

Хорошая структура ответа: определить цель фичи, выбрать primary metric, обозначить guardrail metrics, описать дизайн эксперимента и объяснить, как именно вы будете интерпретировать результат. Сильный ответ почти всегда начинается с уточнения: что именно считается успехом — рост CTR, рост конверсии в покупку, повышение релевантности или снижение времени до целевого действия.

Вопросы для QA-инженеров

QA-секции в Яндексе обычно делятся на теорию тестирования и автотесты. Проверяют не только знание терминов, но и умение мыслить сценариями, видеть риски и писать внятные проверки.

Что спрашивают по теории тестирования

«Как бы вы протестировали поиск?» — здесь ждут не один-два примера, а системный разбор: позитивные сценарии, негативные, граничные случаи и нефункциональные проверки.

«В чём разница между regression и smoke?» — smoke проверяет, что система вообще жива после сборки, а regression — что ранее работавшая функциональность не сломалась после изменений.

«Что такое flaky test?» — это тест, который то проходит, то падает без изменений в коде. Хороший ответ должен включать не только определение, но и причины: гонки данных, зависимость от внешнего сервиса, нестабильные таймауты, слабую изоляцию тестов.

Какие проверки ждут от QA на собеседовании

  • эквивалентное разбиение и анализ граничных значений
  • позитивные, негативные и edge-case сценарии
  • state transition и сценарии со сменой статусов
  • разделение API, UI, integration и end-to-end проверок
  • приоритизация тест-кейсов при ограниченном времени
  • качество bug report: шаги, ожидаемый результат, фактический результат, окружение
  • понимание, что именно автоматизировать, а что лучше оставить на ручную проверку

Пример задачи на автотестирование

Напишите автотест для проверки авторизации через API:

import pytest
import requests

BASE_URL = "https://api.example.com"

def test_successful_login():
    payload = {"username": "testuser", "password": "correct_password"}
    response = requests.post(f"{BASE_URL}/auth/login", json=payload, timeout=5)
    assert response.status_code == 200
    assert "access_token" in response.json()

def test_invalid_password_returns_401():
    payload = {"username": "testuser", "password": "wrong_password"}
    response = requests.post(f"{BASE_URL}/auth/login", json=payload, timeout=5)
    assert response.status_code == 401
    assert response.json().get("error") == "Invalid credentials"

def test_missing_fields_returns_400():
    response = requests.post(f"{BASE_URL}/auth/login", json={}, timeout=5)
    assert response.status_code == 400

На собеседовании такой код могут попросить улучшить: добавить фикстуры, параметризацию, изоляцию тестовых данных, обработку окружений и объяснение, как запускать только нужный набор тестов.

Вопросы для менеджеров и PM

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

Поведенческие вопросы по STAR

Интервьюеры обычно ждут ответы по модели STAR: ситуация, задача, действие, результат. При этом они хотят слышать вашу личную роль, а не просто историю команды.

Пример вопроса: «Расскажите о ситуации, когда вам пришлось принять решение без достаточного количества данных».

Сильный ответ включает: контекст, ограничения, альтернативы, вашу логику выбора и измеримый итог. Слабый ответ обычно звучит как: «мы просто решили и всё получилось».

Другой типовой вопрос: «Что делать, если приоритеты команды расходятся с приоритетами стейкхолдера?» Здесь ждут рассказ не про упрямство, а про аргументацию, данные, коммуникацию и, если нужно, корректную эскалацию.

Кейсы на управление продуктом

«Как расставить приоритеты в бэклоге из 50 задач?» — хороший ответ обычно строится через RICE, ICE или похожую систему и включает объяснение, откуда берутся оценки и как часто приоритеты пересматриваются.

«Придумайте новую фичу для Яндекс.Такси» — здесь лучше идти по структуре: выбрать сегмент, обозначить боль, предложить решение, назвать метрики успеха и показать риски.

Сильный ответ для PM почти всегда включает не только идею, но и систему измерения результата. Например: conversion to order, repeat usage, cancellation rate, time to car assignment, retention, NPS или CSAT, а также guardrail-метрики, чтобы улучшение в одной зоне не ломало продукт в другой.

Поведенческие вопросы: универсальный блок

Независимо от роли, почти всегда полезно заранее подготовить 5–6 историй, которые можно адаптировать под разные вопросы.

Работа в команде и конфликты

«Расскажите о конфликте с коллегой» — плохой ответ: «конфликтов не было». Интервьюер обычно воспринимает это либо как неправду, либо как признак избегания сложных разговоров. Хороший ответ показывает, что конфликт был рабочим, вы не перевели его в личную плоскость и нашли конструктивное решение.

«Как вы даёте негативную обратную связь?» — часто ожидают подход в стиле SBI: ситуация, поведение, влияние. То есть говорить не «ты безответственный», а «на встрече во вторник мы не дождались данных, и из-за этого не успели принять решение до дедлайна».

Решение задач под давлением

«Расскажите о проекте, который провалился» — это вопрос не про провал как таковой, а про рефлексию. Интервьюер хочет увидеть, признаёте ли вы свою долю ответственности, умеете ли разбирать причины и менять подход после ошибок.

Подготовка к собеседованию в Яндекс: план по неделям

За 2–3 месяца: фундамент

Для разработчиков хороший ориентир — 80–100 задач на LeetCode, распределённых по темам: массивы, строки, деревья, графы, бинарный поиск, динамическое программирование. Основной фокус — Easy и Medium. Hard имеет смысл только после уверенного владения Medium.

Для аналитиков — 30–40 SQL-задач, повторение оконных функций, статистики, A/B-тестов и базовых продуктовых метрик.

Для QA — системное повторение теории тестирования, API, баз автоматизации, а также практика по разбору сценариев и рисков. Для менеджеров и PM — подготовка STAR-историй, продуктовых кейсов, фреймворков приоритизации и метрик.

За 2 недели: тренировка в формате интервью

Полезно решать задачи с таймером и обязательно проговаривать решения вслух. Для разработчиков очень помогают mock-интервью. Для System Design — разбор нескольких классических кейсов вроде URL shortener, Twitter feed, YouTube, Uber или WhatsApp.

Накануне: финальный чеклист

  • проверить камеру, микрофон и интернет
  • заранее открыть платформу и авторизоваться
  • освежить 10–15 типовых паттернов решений
  • подготовить 5–6 сильных историй по STAR
  • не добивать себя практикой до ночи — усталость на алгоритмах стоит слишком дорого

Типичные ошибки кандидатов

Молчание при решении задачи. Если вы молчите дольше пары минут, интервьюер не понимает, где вы застряли, и не может оценить ваше мышление.

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

Незнание сложности решения. Даже правильный код оценивается слабее, если кандидат не может объяснить time complexity и space complexity.

Преувеличение своей роли в проектах. В Яндексе обычно копают глубоко, и если в резюме написано «я разработал систему», интервьюер будет разбирать до деталей, пока не станет понятно, что именно сделали лично вы.

Игнорирование follow-up вопросов. Вопросы вроде «что будет при миллиарде элементов?» — это не ловушка, а нормальная проверка системного мышления.

Какие вопросы задать интервьюеру в Яндексе

В конце интервью полезно задать несколько содержательных вопросов. Это показывает зрелый подход и помогает самому кандидату понять, подходит ли ему команда.

  • Как выглядит типичный рабочий цикл команды?
  • Какие задачи будут у человека в первые 3 месяца?
  • По каким критериям оценивают успешность в этой роли?
  • Как устроено взаимодействие с соседними командами?
  • Какие основные технические или продуктовые вызовы есть у команды сейчас?

Похожие гайды по собеседованиям

Если вы готовитесь сразу к нескольким компаниям, полезно посмотреть и другие материалы:

Часто задаваемые вопросы

Понравилась статья? Поделитесь: Telegram