Публичный мок АА в Яндексе: опыт, который не заменит никакая подготовка

от автора

Предыстория

Современный разработчик не упускает возможностей — отказаться от мок-собеса в Яндекс я не смог. Отдельная благодарность двум людям, без которых этого опыта не было бы: Оле Рыбаковой, которая предложила попробовать себя в прохождении мока — и это дорогого стоит, когда человек помогает, не будучи обязан это делать. И Наде Безносовой, продюсеру мероприятия — она ввела нас в формат и сделала всё для нашего комфорта.

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

Тема оказалась другой — АА секция.

Алгоритмы — это отдельный мир. На курсах язык учат 8 месяцев, а алгоритмический трек — это ещё полгода с нуля. Начинать с такого старта — вызов вдвойне. Но игнорировать не стал: 3 недели подготовки после плотного погружения в Go — месяцы практики, проектов и смежных тем. И в этот раз — с теорией, а не только практикой. Это основное отличие, которое дало результат.

Если посмотреть мой LeetCode на старте подготовки — около 50 решённых задач. Решал я их не алгоритмами, а перебором всех возможных условий — рабочее, но не универсальное решение. Настоящего понимания подходов не было — и это нужно было менять.

 LeetCode после трёх недель подготовки.

LeetCode после трёх недель подготовки.

Подготовка

Как человек-практик, первым делом нужно понять что и зачем делать, а потом уже как. За эти три недели решённых задач стало почти 90. Выстроился некоторый workflow:

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

  2. Видеоуроки не зашли — зато текстовая теория сработала неожиданно эффективно. Алгоритмы устроены иначе, чем кажется: база по каждой теме небольшая, 4–6 чётких случаев «когда и что применять». Вариативность здесь не в сложности подхода, а в комбинациях — как именно ты соединяешь знакомые инструменты под конкретную задачу.

  3. Основная сложность — не решить задачу, а сразу определить какой подход оптимален. Здесь работает насмотренность: чем больше задач прошёл, тем быстрее считывается паттерн. Когда начинает получаться — появляется следующий вопрос: а как ещё это можно решить? И какой вариант лучше — не только по O-оценке, но и на реальных данных в своём языке. Два решения с одинаковой асимптотикой могут вести себя по-разному из-за констант, особенностей памяти, специфики реализации. В Go это легко проверить бенчмарком — он сам отработает нужное количество итераций и даст объективную картину.

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

За три недели познакомился с 6 темами. Binary Search и базовые вариации Two Pointers — для меня оказались проще всего. Односвязный список только коснулся, хотя он часто идет первым в списке тем. С массивами отдельная история: они нужны внутри других подходов — например, в Sliding Window часто складываешь элементы в массив как вспомогательную структуру. Это не самостоятельная тема, это инструмент внутри других тем. Полноценно изучить не успел — начинал с другого. С таким багажом и пошёл на мок.

Мок

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

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

Вошёл в состояние «автоматического управления», как у пилотов F1 — отключилось всё постороннее, был полностью в вебинаре.

Задача оказалась несложной — классика на sliding window. Найти подмассив длины ровно k с максимальным средним:

// Дан массив целых чисел nums из n элементов и целое число k.// Найдите непрерывный подмассив длины ровно k с максимальным средним значением// и верните это среднее.find_max_average([1, 12, -5, -6, 50, 3], 4) -> 12.75

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

Тогда интервьюер добавил второй кейс:

find_max_average([1, 12, -5, -6, 50, 3], 40) -> ?

Массив длины 6, k=40. Раннего выхода на случай k > len(nums) в коде нет. В Go это panic на первом же цикле, но дело не в языке — на другом языке это будет исключение или мусор в ответе. Алгоритм не завязан на язык, ошибка тоже: решение не покрывает валидный вход.

Ровно тот случай, о котором я сам писал в четвёртом пункте подготовки. АА-секция проверяет не только знание алгоритмов. Она проверяет умение видеть краевые случаи, справляться с давлением, объяснять своё решение вслух. Три недели — это про наработку подхода к задачам. Всё остальное появляется только с объёмом практики.

«Под давлением ты не поднимаешься до уровня своих ожиданий — ты падаешь до уровня своей подготовки».

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

Подробнее о мероприятии — на лендинге, там же можно увидеть нас с Наташей.

Что дальше

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

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

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

ссылка на оригинал статьи https://habr.com/ru/articles/1059542/