Собеседование в Яндекс: как устроен отбор и что спрашивают на каждом этапе

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

Такая структура существует не для того, чтобы усложнить кандидату жизнь, а потому что один человек за одну встречу не успевает проверить и техническую квалификацию, и то, как кандидат работал в проектах, и совместимость с командой. Каждую секцию обычно ведёт отдельный интервьюер, и решение принимается по совокупности этапов, а не по одному сильному или слабому впечатлению. Это значит, что слабая секция не всегда фатальна, если остальные прошли уверенно, но и одна блестящая секция не заменяет остальные. Порядок этапов, их число и то, идут ли секции подряд в один день или растянуты на несколько недель, отличается между направлениями, поэтому уточняйте план у рекрутера сразу, как только он выходит на связь.

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

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

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

Скрининг стоит использовать и в свою пользу. Спросите, сколько будет секций и что каждая проверяет, будет ли задача с написанием кода в реальном времени, кто проводит финальную встречу, какие сроки между этапами и есть ли дедлайн по вакансии. Эти ответы прямо влияют на то, как вы распределите подготовку. Если рекрутер чего-то не знает, это тоже нормальный результат: значит, формат уточняется ближе к секции, и стоит попросить написать вам детали заранее.

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

Типичная ошибка: кандидат сразу начинает писать финальный код, не проговорив ход рассуждений, и застревает, когда решение не работает с первой попытки. Рабочий порядок другой. Сначала перескажите условие своими словами и уточните неочевидное: что делать с пустым входом, могут ли быть повторяющиеся элементы, важен ли порядок результата. Потом назовите один-два подхода вслух и объясните, почему выбираете конкретный. Затем пишите код и по ходу проверяйте его на небольшом примере. Если по ходу видите, что подход упирается в ограничение, скажите об этом сами, не дожидаясь подсказки.

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

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

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

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

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

Готовиться лучше заранее, разобрав два-три проекта на уровне конкретных действий. Цифры приводите только те, которые действительно знаете: если вы помните, что время ответа сервиса сократилось, но не помните на сколько, так и скажите, это честнее, чем придумать красивое число, которое развалится на уточняющем вопросе. Полезно держать в запасе не только истории успеха, но и один пример ситуации, которая не получилась: что именно не сработало, как вы это заметили, что изменили в своей работе после. Такой пример почти всегда просят, и импровизировать на нём тяжело.

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

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

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

Глубина проверки прикладных навыков отличается между командами. Где-то попросят написать запрос на SQL или разобрать таблицу с выгрузкой, где-то ограничатся вопросами про подход к анализу, а где-то дадут домашнее задание с данными. Заранее спросите у рекрутера, будет ли практическая часть с инструментами и какими, нужен ли ноутбук со своим окружением, есть ли ограничение по времени. Это тот случай, когда один вопрос экономит несколько вечеров подготовки не в ту сторону.

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

Ошибка здесь в том, чтобы считать финал формальностью после технической части и прийти без вопросов или с общими словами о мотивации вида «интересные задачи и сильная команда». Более сильная позиция: два-три конкретных вопроса, из которых видно, что вы разобрались в направлении и понимаете, о чём спрашиваете. Хорошо работает вопрос про то, какая задача команды сейчас самая неприятная, и про то, чего не хватало предыдущему человеку на этой роли: ответ даёт вам реальную картину, а не описание из вакансии.

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

Первый шаг после приглашения: уточнить у рекрутера структуру процесса для вашей позиции. Сколько будет секций, что каждая проверяет, в каком формате пройдёт встреча, будет ли написание кода в реальном времени или обсуждение без него, кто будет на финале. Эта информация экономит время, потому что вы не готовитесь к тому, чего в вашем процессе нет. Дальше двигайтесь по порядку: разберите формат ближайшей секции, а к следующей переходите, когда предыдущая назначена или уже пройдена.

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

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