Как научиться решать задачи на Leetcode

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

Недавно рассказывал, как получил оффер от Яндекса. Одним из этапов был live coding с алгоритмическими задачами.

А сегодня решил показать свою статистику на LeetCode: всего решил примерно 100 задач: 61 easy, 33 medium. Кому-то наверное нужно больше, кому-то меньше, но думаю что этого количество должно хватить.

Как я готовился и чтобы посоветовал тем, кто готовится.

1. Разбирайте задачи по паттернам.
Два указателя, скользящее окно, HashMap, бинарный поиск, обход деревьев. Решите несколько задач на один подход, чтобы понять, что у них общего. Так проще увидеть знакомую идею в новом условии.

2. Не превращайте одну задачу в испытание на весь вечер.
Если за 25–30 минут совсем нет продвижения, возьмите подсказку. Если не помогла — разберите решение. Потом закройте его и напишите самостоятельно. Прочитать понятный разбор и самостоятельно воспроизвести решение — разные уровни понимания.

3. Возвращайтесь к уже решённому.
Повторите задачу через несколько дней без подсказок. Именно здесь становится понятно, разобрался ты или просто запомнил, как выглядел код.

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

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

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

5. И самое главное — продумывайте краевые случаи до написания кода.
Что будет с пустым массивом? С одним элементом? С дубликатами? Не случится ли переполнение?

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

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

Поэтому я бы не ставил себе цель «решить 500 задач». Мне ближе другая идея: научиться быстро разбираться в условии, выбрать подход, объяснить решение и проверить, что оно работает за пределами happy path.

А у вас что сложнее на LeetCode: придумать решение или написать его без багов?