Собеседование в Яндексе — это не один разговор с 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 и автодополнения. Язык программирования, как правило, можно выбрать самому.
На алгоритмическом интервью оценивают не только правильность решения, но и ход мышления. Очень важно проговаривать логику вслух, уточнять граничные условия до начала написания кода и объяснять временную и пространственную сложность решения.
Хорошая базовая схема ответа на алгоритмической секции выглядит так:
- Коротко переформулировать задачу своими словами.
- Уточнить ограничения: размер входных данных, допустимые значения, формат ответа, нужно ли оптимальное решение.
- Озвучить наивный подход и объяснить его сложность.
- Перейти к более эффективному решению и объяснить, почему оно лучше.
- Писать код частями, проговаривая логику.
- Проверить решение на обычных и граничных примерах.
- В конце явно назвать 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 в Яндексе — это не тест на идеальную схему, а проверка архитектурного мышления. Почти любую задачу на проектирование удобно раскладывать по одной и той же логике.
- Сначала уточнить требования. Сколько пользователей, какая нагрузка, какая допустимая задержка, нужны ли транзакции, насколько критична потеря данных.
- Дать оценочные цифры. Даже грубые расчёты помогают понять порядок нагрузки и выбрать реалистичные компоненты.
- Нарисовать high-level архитектуру. Например: API → Load Balancer → Application Servers → Cache → DB.
- Провалиться в узкие места. Где 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 месяца?
- По каким критериям оценивают успешность в этой роли?
- Как устроено взаимодействие с соседними командами?
- Какие основные технические или продуктовые вызовы есть у команды сейчас?
Похожие гайды по собеседованиям
Если вы готовитесь сразу к нескольким компаниям, полезно посмотреть и другие материалы:
- Как пройти собеседование в Сбербанк: полный разбор, примеры вопросов и ответы
- Как пройти собеседование в Т-Банк (Тинькофф)
- Как пройти собеседование в банк: полный гайд с вопросами, ответами и кейсами
- 100 вопросов и ответов для аналитика на собеседовании
- Топ-10 универсальных вопросов на любом собеседовании: полный разбор
- Актуальные вакансии для разработчиков в iGaming
- Вакансии аналитиков в iGaming-индустрии
Часто задаваемые вопросы
Чаще всего процесс состоит из пяти этапов: HR-скрининг, алгоритмическое интервью, System Design для middle+ и senior, встреча с командой и финальное интервью.
Важно не только решить задачу, но и думать вслух, уточнять условия, объяснять сложность решения и уметь обсуждать альтернативные подходы.
Обычно да — для middle и senior позиций. Для стажёров и junior-кандидатов этот этап часто либо отсутствует, либо заметно упрощён.
Обычно в аналитических интервью проверяют SQL, продуктовые кейсы, статистику, A/B-тесты и умение интерпретировать метрики, а не только писать запросы.
Да, большинство этапов обычно проходит удалённо. Очный формат чаще встречается на финальных стадиях отдельных senior-позиций.
Чаще всего кандидаты вредят себе молчанием во время решения задач, отсутствием уточняющих вопросов, слабым пониманием сложности алгоритма и преувеличением своей роли в проектах.
Да, повторная подача обычно возможна через некоторое время. Конкретный срок зависит от роли и команды, но паузу лучше использовать для адресной подготовки по слабым местам.
На некоторых позициях — да. Это зависит от команды и уровня роли. Иногда стандартные интервью дополняются практической секцией или отдельным заданием.