Языки программирования: почему начинал с JavaScript, перешёл на TypeScript и попробовал Go
Ситуации когда мне пригодились алгоритмы на работе или в жизни
Время чтения ~40 минут
TL;DR для занятых
730 дней, 1000+ задач на LeetCode, 2000+ часов
От "обычного" web разработчика до уверенного решения "любых" задач
Инвестиция: потрачено 3-4 зарплаты senior разработчика, +2-4 часа ежедневно
В статье — конкретные инструменты (Obsidian, Miro, Excalidraw), методология решения задач, работа с mock-интервью и честный разбор ошибок
Главный секрет: алгоритмы — это не про талант, а про систему, постоянство и правильную организацию процесса
Бонус: алгоритмы меняют инженерное мышление даже вне контекста собеседований
Введение
Эта статья — не инструкция "как быстро выучить алгоритмы" и не история успеха в духе "сделал X и теперь у меня всё получилось".
Скорее, это подробный и честный рассказ о длинном пути: с моими сомнениями, ошибками, периодическими откатами назад и постепенным прогрессом.
Я решил написать этот текст по нескольким причинам.
Во‑первых, за последние годы мне часто задавали вопросы про алгоритмы: с чего начать, сколько времени нужно, реально ли учить их параллельно с работой и семьей, и какой черт возьми смысл в них — кроме как на интервью?!.
Во‑вторых, мне самому хотелось зафиксировать опыт: разложить его по полочкам и понять, что в нем было действительно полезным, а что — избыточным или совсем ошибочным.
Если коротко: за два года решил больше 1000 задач на LeetCode и потратил на это, по моим оценкам, свыше 2000 часов. Это не рекорд и не повод для гордости. Это просто факт, который задаёт масштаб проделанной работы.
Итак, наливайте чай, теперь начинаю свою историю…
Немного о вводных данных
Важно сразу обозначить контекст, потому что без него весь дальнейший рассказ легко неправильно интерпретировать.
Я не олимпиадник. В школе не учился в математическом классе, не участвовал в соревнованиях и не решал алгоритмические задачи. Алгоритмы и структуры данных в классическом понимании прошли мимо меня. Программировать начал уже во взрослом возрасте и учился в основном самостоятельно — по статьям, курсам и личной практике.
К моменту, когда всерьёз взялся за алгоритмы, у меня было около восьми лет коммерческого опыта в веб-разработке на php и js. При этом, как позже выяснилось, этот опыт почти не пересекался с тем, что требуется на алгоритмических интервью. Я умел писать рабочий код, проектировать системы, разбираться в чужих кодовых базах, но при виде классических задач на графы или динамическое программирование чувствовал себя тупым и безграмотным.
Отдельно стоит упомянуть про жизненные обстоятельства. На тот момент у меня была постоянная работа, семья и двое маленьких детей. Свободного времени было немного, а усталость в конце рабочего дня — обычным состоянием. Это важно, потому что мой путь — не история про "уволился и полгода учил алгоритмы по 8 часов в день". Всё происходило параллельно с обычной жизнью.
Если попытаться выделить мою сильную сторону, то это точно не скорость мышления и не врождённый талант к математике. Скорее, это способность долго и последовательно заниматься одной и той же задачей, даже когда прогресс кажется минимальным. Забегая вперед: именно это качество оказалось решающим.
Зачем мне вообще понадобились алгоритмы
Примерно два года назад я начал серьезно задумываться о смене работы как о следующем этапе в моей карьере. Мне было интересно попробовать себя в крупных международных компаниях, где требования к инженерной культуре выше, а процессы — более профессиональные.
Довольно быстро стало понятно, что независимо от конкретной компании, алгоритмическое интервью — почти неизбежный этап. И именно он вызывает у большинства разработчиков наибольшее отторжение. И я не был исключением.
До этого момента уже предпринимал попытки "подтянуть алгоритмы". Читал классические книги, смотрел видео, решал отдельные задачи. Но каждый раз всё заканчивалось примерно одинаково: энтузиазм в начале, хаотичное обучение, отсутствие ощущения прогресса и, в итоге, постепенный спад мотивации. Знакомо?
Основная проблема была не в сложности материала, а в отсутствии системы. Было не понятно:
в каком порядке и какие изучать темы
какие задачи действительно важны, а какие — второстепенны
как отслеживать прогресс
и как отличить реальное понимание от иллюзии знания
В какой-то момент честно признался себе, что самостоятельно выстроить этот процесс мне сложно. Не потому что "не способен", а потому что цена ошибки — сотни часов, потраченных впустую.
Решение пойти в структурированное обучение
Какое-то время назад до начала моего обучения я наткнулся на youtube канал Cronis. Меня зацепил подход: упор не на заучивание шаблонов, а на понимание идей и принципов. Материал выглядел максимально структурированным, а подача — инженерной и понятной, а не академической как в книгах по математики. (привет всем кто читал Кнута)
Совпало и то, что в тот момент открывался набор на индивидуальный формат обучения. Программа была рассчитана примерно на год и включала 60 персональных занятий по часу, кураторство в течение года, чёткий учебный план, теорию и большое количество задач для самостоятельной работы.
Стоимость обучения была для меня высокой — эквивалент нескольких зарплат senior-разработчика. Это решение нельзя было назвать очевидным или легким. Долго сомневался, взвешивал риски и в какой-то момент понял, что для меня это, по сути, инвестиция в собственное образование.
Я не ожидал быстрых результатов. Скорее, рассчитывал получить структуру, дисциплину и внешнюю обратную связь — то, чего мне не хватало в предыдущих попытках.
Так начался мой двухлетний путь в мир алгоритмов и структур данных.
Организация обучения: как выглядел процесс на практике
Когда обучение стартовало, довольно быстро стало понятно: само наличие учебного плана и регулярных занятий — это лишь каркас. Основная работа всё равно происходила между встречами, в одиночку, за задачами и конспектами.
В среднем мой учебный процесс выглядел так:
несколько занятий с ментором в месяц по видеосвязи
самостоятельное изучение теории по текущей теме
основную теорию получал от преподавателя или добирал из публичных источников — если мне хотелось взглянуть под другим угломрешение задач — от простых к более сложным
разбор ошибок, возврат к теории и повторение
В хорошие периоды занимался каждый день по 4 часа, в плохие — делал минимальный возможный объём 2 часа. Со временем стало очевидно, что ключевым фактором является не интенсивность, а регулярность.
Почти сразу возникла проблема фиксации знаний. Теории было много, задач — ещё больше, а удерживать всё в голове оказалось невозможно.
Моей первой идеей был приватный Telegram-канал. Я писал туда короткие заметки:
идеи и описания решений
куски кода (кстати хорошо форматируется)
свои мысли после занятий
ощущения от тем и задач
может быть рисунок
На старте это даже казалось удобным: быстро, просто, всегда под рукой. Но довольно скоро проявились ограничения:
невозможно нормально структурировать материал
сложно что‑то найти через месяц
нет наглядных схем и связей между задачами
канал превращается в бесконечную ленту
сложно придумать какую-то агрегацию и статистику
нельзя рисовать онлайн с кем то, да и рисовать в целом
Telegram оказался хорош для фиксации эмоций и мыслей "здесь и сейчас", но плохо подходил для построения долгоживущей базы знаний.
Следующим этапом стала доска в Miro. Это был серьёзный шаг вперёд.
Я начал использовать Miro как:
хранилище теории по темам
место для визуальных разборов задач
инструмент для систематизации уже решенных задач
разбора задач на личных встречах с преподавателем
видео-конспекты (ограничены по кол-ву для бесплатных пользователей)
На доске появились:
блоки по темам (графы, деревья, комбинаторика и т.д.)
схемы по теории и ссылки на внешние ресурсы
таблицы с задачами по каждой теме: ее номер, сложность, acceptance rate из Leetcode, ссылка, ключевая идея, комментарии
в каждой задачи могло быть несколько решений с кодом и схем, сканов от руки или из whiteboard, видео и различные комментарии
Визуальное представление сильно помогало. Многие алгоритмы, которые плохо укладывались в голове в виде текста, становились понятными после одной-двух схем.
Но со временем начали проявляться и минусы:
доска разрасталась и начинала "тормозить"
сложнее стало поддерживать порядок, все темы по алгоритмам на одной доске, а больше досок ограничение бесплатного тарифа
различные ограничения бесплатного тарифа например по записи видео внутри Miro, мне это функция "зашла"
данные хранятся не у меня, а в miro
Miro отлично подходил для активной фазы обучения, но плохо масштабировался на дистанции в год и больше и стал все меньше подходить под мои требования.
На втором году обучения я перешёл на связку Obsidian и Excalidraw. Именно она в итоге стала моей основной системой.
Ссылка на плагин excalidraw в Obsidian
Что это дало:
текстовые заметки с удобной навигацией
обратные ссылки между документами (гиперссылки) и как итог возможность связывать задачи, идеи и теорию
добавление внешних источников, сайты и видео ресурсы
встроенные шаблоны по рисованию (в miro тоже есть свои)
приятный глазу дизайн и шрифт (субъективно)
быстрый поиск по всей базе знаний
возможность самостоятельного расширения функционала
хранение информации у меня лично
бесплатно
Каждая алгоритмическая тема имела свой документ:
таблица со всеми решенными задачами, со структурой аналогичной в miro
основные паттерны и теория
само решение по каждой задачи
визуальные схемы — много схем!
ссылка на внешний документ или видео (или можно было встраивать в рисунок)
Задачи тоже перестали быть просто списком. Для них я делал отдельные заметки:
формулировал идею решения своими словами
фиксировал, почему именно этот подход работает
отмечал, на чём я споткнулся в первый раз
много рисовал (apple pencil, trackpad)
писал код не в IDE с подсветкой синтаксиса, а "на белом листе". (как в Google Docs)
Полезный навык для интервью.
Со временем Obsidian превратился не просто в конспект, а в персональную "алгоритмическую вики", к которой я регулярно возвращался.
Со стороны может показаться, что все это — избыточно. Но на практике без системы происходит следующее:
темы путаются между собой
решения забываются быстрее, чем хотелось бы
создаётся иллюзия прогресса
повторное погружение требует слишком много времени
вы не анализируете свои шаги
Хорошие конспекты не избавляют от необходимости повторять материал, но сильно снижают порог входа при возврате к теме. Это особенно важно, когда обучение растягивается на месяцы и годы.
Темы для изучения и их порядок
Важно отдельно отметить, что порядок изучения тем не был случайным и не формировался мной с нуля. Структуру обучения задавал мой преподаватель.
Темы шли не изолированно, а логически связывались между собой. Новые разделы опирались на уже пройденные, а знакомые идеи постоянно переиспользовались в новом контексте. За счёт этого постепенно формировалось ощущение целостной картины, а не набора разрозненных алгоритмов.
Для понимание какие темы я проходил в сохраненном порядке:
Поиск с возвратом и комбинаторика
Очень сложная тема в самом начале, но задает вам базу по рекурсии. Рекурсия на комбинаторных алгоритмах с полным перебором одна из самых трудных, но после нее деревья и графы уже кажутся проще.Связанные списки (Linked list)
Задачи на внимательность и шаблоны. Переброс ссылок между узлами надо делать аккуратно. В самом начале у меня взрывался мозг от решений через рекурсию. Переброс ссылок в связном списке через возврат в функции — это были не забываемые ощущения.Tree: бинарные дерево и BST, префиксные деревья(trie), сбалансированные деревья (на уровне идей), LSA
С деревьями у меня ��ыл долгий и не самый простой путь. Первое время они воспринимались как что‑то абстрактное и не очень применимое. Переломный момент произошёл, когда я начал рисовать их буквально в каждой задаче и разбирать рекурсию не как "магическую конструкцию", а как обычный стек вызовов. Черт возьми, и тут рекурсия!
Графы (DFS, BFS, алгоритм дейкстры, union find, топологическая сортировка, shortest path)
Графы — одна из самых объемных, сложных и любимых мною тем:
Здесь особенно важно было не просто выучить, а научиться распознавать граф в условии задачи. Часто слово "граф" там вообще не фигурирует, но по сути задача именно про него. Поначалу я не мог понять, как матрица и граф вообще связаны между собой. Да и тут тоже рекурсия 🙂Сортировки + поиск + куча(heap)
Quick sort это однозначно hard задача — зачем ее вообще дают в самом начале в учебных заведениях?!
Все классические сортировки не так сложно написать если у вас хорошо прокачен навык написания алгоритмов.
Двоичный поиск — надо уметь закрытыми глазами, в разных вариациях - и он сильно хорош! Я даже узнал задачи, где применение двоичного поиска был для меня открытием (пример на youtube)
Heap в идеале уметь писать с нуля, я даже слышал что просили в Yandex. Положа руку на сердце, писать вы, скорее всего, будете долго — поэтому надо знать только как работать через стандартные методы. И таки да, Heap очень популярна - и большое кол-во задач были решены через нее.Динамическое программирование
Динамика заслуживает отдельного упоминан��я. Это была одна из самых тягостных тем для меня.На первом этапе DP выглядело как набор формул, которые нужно угадать. Постепенно, через десятки задач, пришло понимание: как формулировать состояние, что такое переход, как выбирать размерность DP, когда нужна оптимизация по памяти и как написать рекурсию, мемонизацию и закончить табуляцией.
Прорыв произошёл не сразу и не за одну тему. Скорее, это было накопительное понимание, которое складывалось из ошибок и повторений.
Жадные
Sliding window + two pointers + stack
Queue + монотонные
Интервалы
Мелкие задачи на prefix sum, алгоритм Кадана, геометрию, битовые операции и другие
Оставшиеся темы имеют свои подходы и нюансы. Какие-то стандартные вроде sliding window, а какие-то супер hard на интервалы или prefix sum.
Самостоятельно выстроить такой порядок мне было бы крайне сложно. Ретроспективно понимаю, что именно эта связность тем уберегла меня от хаотичного обучения и бесконечных прыжков между задачами.
Языки программирования: почему начинал с JavaScript, перешёл на TypeScript и попробовал Go
В процессе обучения несколько раз менял язык программирования для решения алгоритмических задач. Это не было частью изначального плана — скорее, естественным развитием по мере роста понимания и смены приоритетов.
На старте выбрал JavaScript. Причина была простой: этот язык хорошо знал, на нем часто писал код и чувствовал себя максимально уверенно.
На начальном этапе это оказалось большим плюсом. Мне не нужно было тратить ментальные ресурсы на синтаксис и нюансы языка и все внимание уходило на сам алгоритм.
JavaScript позволял быстро писать и переписывать код, экспериментировать и не застревать на технических деталях. Для первых сотен задач это было особенно важно.
При этом довольно быстро начали проявляться и ограничения:
отсутствие строгой типизации
больше шансов допустить глупую ошибку (субъективно)
нет реализации heap, только сторонние библиотеки (на leetcode есть встроенная до определенной версии)
сложнее удерживать в голове структуру сложных состояний и их типов, особенно в DP, графах, деревьях (везде, где рекурсия), вложенные массивы и maps
В результате, через некоторое время я перешёл на TypeScript. Это был осознанный шаг, а не дань моде.
Типизация неожиданно сильно помогла:
снизилась когнитивная нагрузка
стало проще работать с составными структурами данных
ошибки начали ловиться раньше (если конечно использовать редактор)
код стал более "самодокументируемым"
В контексте алгоритмов TypeScript оказался удачным компромиссом: он по‑прежнему достаточно гибкий, но при этом даёт дополнительную опору, когда решения становятся сложнее.
На втором году обучения я решил намеренно выйти из зоны комфорта и попробовать Go. Это было не столько "необходимо", сколько полезно для расширения кругозора.
Go дал совершенно другой опыт:
более строгая модель типов
работа с указателями
часто отсутствие привычных абстракций в коде
необходимость аккуратнее думать о структурах данных
Где‑то Go упрощал жизнь — например, за счет стандартных методов heap. Где‑то, наоборот, усложнял: работа с двумерными массивами, сортировка map, работа со строками.
Этот опыт оказался полезным именно как контраст. Многие вещи, которые в JavaScript казались "магическими", в Go приходилось делать руками - и за счёт этого лучше понимать, что происходит под капотом.
Со временем я пришёл к довольно простому выводу: язык программирования вторичен.
Python, JavaScript, TypeScript, Go, Java — всё это рабочие инструменты для алгоритмов. Гораздо важнее:
понимать идеи и паттерны
уметь анализировать сложность
видеть структуру задачи
работать с пограничными случаями
знать computer science
знать хорошо язык — на которым пишешь
Выбор языка — это вопрос личного комфорта и целей. Если вы готовитесь к интервью в конкретную компанию, имеет смысл использовать язык, на котором вы будете проходить интервью. Если цель — общее развитие, язык можно менять и пробовать разные подходы.
Мой подход к решению задач
Со временем у меня сформировался довольно чёткий и повторяемый процесс работы с задачами. Он не возник сразу — скорее, это результат большого количества ошибок, застреваний и попыток "срезать углы", которые почти всегда заканчивались плохо.
Шаг 1. Теория прежде всего
Первый этап — изучение теоретической базы по конкретной теме.
Например, если речь идёт о графах, то сначала нужно разобраться:
какие бывают типы графов;
как они хранятся (структуры данных);
какие существуют алгоритмы обхода и поиска.
В моем случае это были видео от преподавателя. Важно, чтобы на этом этапе у вас уже был полный и связный материал. Если его нет — стоит честно добавить ещё один подпункт: поиск и изучение хорошей теории. Без этого дальше будет значительно сложнее.
Шаг 2. Подбор задач по теме
Далее — выбираем задачи. Если у вас есть готовый список — отлично. Если нет, подойдут:
roadmap от Neetcode - англоязычного YouTube-блогера (в прошлом сотрудника Google), который системно разбирает алгоритмические задачи
сортировка задач по темам и сложности в LeetCode
если нет premium - внешние сервиса по задачам такие как Leetcode Patterns
Я часто ориентировался на acceptance rate: высокий процент означает меньше пограничных случаев и более "прямолинейное" решение.
Если вы готовитесь к собеседованиям, можно дополнительно фильтровать задачи по компаниям (эта функция доступна только в Premium или бесплатно Leetcode Patterns).
Шаг 3. Понять условие на 200%
Это, пожалуй, самый коварный этап.
Очень часто люди начинают решать задачу, не до конца поняв, что от них требуется. Или думают, что поняли - а на деле нет. В итоге: решается совсем другая задача или возникает тупик на ровном месте.
Я сам регулярно наступал на эти грабли.
На этом этапе важно:
перечитать условие несколько раз, посмотреть примеры, подумать..
внимательно изучить constraints (размеры массивов, диапазоны чисел)
понять ограничения данных: строки это, числа, символы и т.д.
заранее отсеять невозможные сценарии
Например, если массив состоит только из чисел — нет смысла думать о символах.
Проще говоря, мы "срезаем углы" и направляем мыслительную энергию туда, где она действительно нужна.
Шаг 4. Попытка придумать решение (с таймером)
Дальше — собственно поиск решения.
Мой преподаватель рекомендовал тратить на это не более 30 минут. На практике я часто доходил до 60 — эгоизм и вера в себя не позволяли сдаться раньше 🙂
По моим ощущениям: если за 30 минут не появилось вообще никаких идей, значит решения вы просто не знаете и дальнейшее "сидение" - неэффективно.
Важно понимать: "не придумать решение" - это когда идей нет совсем, а не когда решение "почти готово".
Например, пытаться с нуля изобрести алгоритм Дейкстры за 30 минут — мало реалистично. Его сначала нужно понять и осознать, а уже потом применять и тренировать. Это утверждение справедливо для любого алгоритма.
Если решение появилось — смело пробуйте реализовать. В целом пары часов достаточно, чтобы честно попытаться решить задачу самостоятельно.
Отведенное время на задачу - отличный диагностический инструмент, особенно при подготовке к собеседованиям.
Если вы долго думаете, стоит задать себе вопросы:
знаю решение, но не могу быстро закодить → нужно больше практики
нет идей вообще → пробел в теории
Не пренебрегайте ретроспективой — она сильно ускоряет рост.
Немного про уровни компетенций
Если опираться на Таксономия Блума, то для эффективного решения задач нужно находиться как минимум на уровне Apply.
Про это хорошо рассказано на YouTube-канале "Кодируем" — в этом видео. Рекомендую посмотреть целиком: оно отлично дает ответы на различные вопросы про алгоритмы, а так же почему поначалу "ничего не получается" - и почему это нормально.
Как можно помогать себе, не убивая процесс обучения
Можно выделить несколько уровней помощи.
Уровень 1. Теги в задаче
Теги вроде HashMap или Binary Search - это лишь ориентир, но иногда он очень полезен.
Конкретные алгоритмы со временем начинают "всплывать" в вашем сознании автоматически, но на старте теги — вполне легитимная подсказка.
Уровень 2. Подсказки (hints)
Подсказки в LeetCode часто далеки от идеала, но могут подтолкнуть мысль в нужную сторону.
Главное правило — не получать готовое решение.
Готовый ответ почти ничего не даёт в плане обучения. Подсказка должна стимулировать мышление, а не заменять его.
Шаг 5. Разбор решения и воспроизведение
Если задачу решить не удалось, я смотрел решение преподавателя, а затем пытался реализовать его самостоятельно, не копируя построчно.
Лучше всего работает воспроизведение не сразу, а через день или два.
Это сильно улучшает запоминание.
Для самых упорных — повтор через несколько дней, месяц и дальше. Так вы боретесь с кривой забывания Эббингауза
Шаг 6. Конспект и рефлексия
После этого я обязательно:
записывал решение
добавлял схемы, ссылки и видео
размышлял, как именно можно было прийти к этому решению
Полезные вопросы себе:
достаточно ли я понял условие
не начал ли думать о решении слишком рано
какие мысли/размышления помогли, а какие мешали
Отдельно рекомендую вернуться к задаче через полгода-год и дополнительно попробовать объяснить её кому-то другому.
Также очень полезен анализ чужих решений — во вкладке Solutions или среди принятых решений. Это расширяет кругозор не только в алгоритмах, но и в использовании возможностей языка программирования.
Решение по темам, а не хаотично
Одно из самых важных открытий — задачи нужно решать по темам, а не в случайном порядке.
Когда ты прыгаешь между разными типами задач, создаётся иллюзия активности, но понимание остаётся поверхностным. Решение же задач блоками даёт другой эффект:
глубже закрепляется идея
быстрее начинают распознаваться паттерны
Именно поэтому списки задач, которые давал преподаватель по каждой теме, были так важны. Они задавали маршрут и помогали не распыляться.
Собственно, ровно так устроены любые учебные программы.
Сколько времени заниматься в день
По моему опыту, более 2 часов в день для алгоритмов — это уже перебор.
Это очень высокая когнитивная нагрузка, особенно если у вас есть основная работа.
Для сравнения: как уже говорил, я занимался от 2 до 4 часов, но "чистого" продуктивного времени там было заметно меньше.
Мозг быстро устаёт, внимание рассеивается, мысли уходят "в никуда": как итог эффективность падает.
Два часа осознанной работы — более чем достаточно.
Если есть силы и мотивация, можно добавить ещё час на повторение, но важно следить за состоянием, чтобы не выгореть.
Про занятия сразу после пробуждения
Из-за высокой нагрузки не рекомендую решать алгоритмы сразу после сна.
Организму нужен хотя бы час, чтобы "включиться".
Да, сам часто так делал — просто потому, что другого времени не было (и тут отдельное спасибо моей жене что оно в целом было). Но объективно это не лучший вариант.
Если у вас есть время только утром — что ж, этим советом можно пренебречь. Кто я такой, чтобы запрещать 🙂
Небольшая история с mock-интервью
Раз уж заговорили про утро — вспомнился один случай.
Мы проводили mock-интервью ранним утром. Мой оппонент, судя по всему, только что открыл глаза и сразу сел за алгоритмы. Итог был предсказуем: длинные паузы, дезориентация, сложности с формулировками.
Только к концу сессии (примерно через час) стало заметно, что человек "проснулся".
Причём у меня было с чем сравнить — мы с ним уже встречались ранее.
Вывод простой и, возможно, наивный, но рабочий: после пробуждения нужна пауза.
Обучая других — учишься сам
Один из самых эффективных подходов, который использовал для структурирования и глубокого усвоения материала, — это обучение других. Его часто называют методом Фейнмана.
Его ключевая идея проста: если ты не можешь внятно объяснить решение другому человеку, значит, ты сам его до конца не понял.
Где на хабре почитать про метод Фейнмана
Для тех, кому интересно, на хабре есть перевод статьи про этот метод — материал довольно наглядный и практичный.
Первое, что нужно сделать — найти аудиторию.
На практике это проще, чем кажется, может подойти: друг, коллега, жена, родственники, открытая аудитория в интернете и в крайнем случае — кошка или собака (хотя, честно говоря, им обычно скучно).
Слушатель не так важен ради пользы для него, а как зеркало вашего понимания. Именно необходимость объяснять вслух быстро выявляет пробелы в знаниях.
Для себя выбрал сразу несколько форматов - о них ниже.
Формат 1. Видеоразборы задач на Youtube.
Первым направлением стали записи разборов задач на YouTube.
Формат максимально простой: камера (необязательно), микрофон, материал и я сам - с умением говорить вслух и по делу.
Когда ты записываешь видео, уже недостаточно просто "знать, как решить задачу".
Нужно:
четко сформулировать проблему и ее ограничения
объяснить, почему наивные решения не подходят
пошагово разобрать идею или идеи
аккуратно провести зрителя от условия к коду
понимать все решение от начала и до конца
Очень быстро стало видно, где у меня самого есть пробелы. Если объяснение начинало "расползаться", значит, идея ещё не устоялась и я сам ничего не понимаю.
Когда только начинал, у меня было чёткое понимание: есть два пути — делать идеально или делать практично. Я выбрал второе.
Моя цель была разложить материал по полочкам в первую очередь для себя, объяснить его максимально подробно и при этом не утонуть в монтаже.
В итоге сознательно подавил внутреннего перфекциониста и стал записывать видео одним дублем, вкладывая больше времени не в монтаж, а в подготовку: схемы, тексты и примеры.
Формат 2. Алгоритмический кружок на работе
Второй вариант - факультатив на работе. Затея, прямо скажем, оптимистичная, но мне удалось собрать небольшую группу инженеров из 3-4 человек.
Формат был таким: я предлагал задачу, коллеги пытались решить её самостоятельно — затем мы вместе разбирали варианты решений.
Этот формат оказался ценным по другой причине. Ты видишь, как одну и ту же задачу разные люди понимают по‑разному:
кто-то сразу видит паттерн
кто-то идёт через brute force
кто-то застревает на деталях
а кто-то просто не знает готовых шаблонов
Это сильно расширяет кругозор и учит не зацикливаться на единственно "правильном" пути, как бонус у вас появляется новая мотивация и социальное взаимодействие, а если еще и повезет, то и конкуренция.
И да, энтузиазм на работе, особенно в отношении алгоритмов, обычно не зашкаливает. Но даже в таком виде этот формат оказался полезным - и вполне рабочим. Берите на заметку.
Формат 3. Лекции и онлайн-митапы по Computer Science
Третье направление — подготовка лекций по Computer Science на работе.
Здесь аудитории было заметно больше, и формат уже напоминал полноценные онлайн-митапы.
В отличие от разборов задач, тут требовалось: структурировать материал, переработать большое количество источников, несколько раз все повторить, и только потом рассказать это вживую — желательно без фейлов.
Добавляет стресса тот факт, что вам потом продолжать работать с этими людьми, а авторитет — штука хрупкая.
Но именно это делает формат крайне эффективным для обучения.
Формат 4. Индивидуальное наставничество или найти "слушателя"
Четвёртый вариант — найти своего "падавана": человека, который будет готов учиться у вас. Это может быть коллега, студент или друг-программист. Лично я для поиска ученика: создал профиль на платформе GetMentor, где желающие могли обратиться ко мне за помощью с алгоритмами.
Еще иногда объяснял задачи друзьям, знакомым или даже членам семьи — людям, далёким от алгоритмов. Это, пожалуй, самый жёсткий тест.
Если ты можешь без формул и терминов донести суть решения человеку без технического бэкграунда, значит, ты действительно понял идею, а не просто запомнил шаблон.
Объяснение другим заставляет, структурировать мысли, явно проговаривать допущения, замечать логические дыры и отделять суть от деталей реализации. Как бонус, вы можете найти другие аллегории или геометрическое объяснение решения.
Кроме того, исчезает соблазн "проскочить" сложный момент. Когда ты учишься сам, легко сказать себе: "ну, здесь то понятно". Когда ты объясняешь, это "понятно" сразу проверяется на прочность.
Со временем стало заметно, что задачи, которые когда‑то разбирал для других, запоминались лучше и дольше. Даже спустя месяцы к ним было проще вернуться.
У меня этот формат был не самым системным. Я что-то объяснял жене, детям, друзьям — пользы для них было немного, но для себя регулярно повторял и переосмысливал материал.
Почему все это действительно работает
Все эти активности объединяет одно: они кратно улучшают усвоение материала.
Понимание — это время, которое вы провели над темой при изучении. А объяснение другому — это проверка, насколько глубоко вы её осознали.
Лично я не могу говорить на камеру или перед людьми, если сам не уверен, что понимаю тему до конца.
Да, можно верить в ерунду — согласен, но "врать" себе не могу.
Чтобы чувствовать уверенность, приходится: тратить значительно больше времени на тему, перепроверять факты и раскладывать всё по полочкам — сначала для себя, а уже потом для других.
Фейнман говорил, что обмануть себя легче всего. Прочитал статью — кажется, что понял. На следующий день - в голове пусто.
Поэтому да, это звучит банально, но факт остаётся фактом: глубокое понимание требует времени и погружения.
И обучение других — один из самых эффективных способов этого добиться.
Mock‑интервью: проверка знаний в условиях стресса
В какой-то момент я решил, что стресс — отличный катализатор обучения(ха-ха), и добавил в свой процесс подготовки mock-интервью.
"Mock‑интервью" сразу подсвечивают проблемы, которые сложно заметить при самостоятельной подготовке:
думать надо быстро (ограниченное время)
необходимость думать вслух
постоянное ощущение давления
параллельное мышление, объяснение и кодинг
Долго думать над организацией это процесса не пришлось: уже состоял в Telegram-чате канала FaangTalk, где периодически проводятся моки. Более того, там всегда можно просто написать в чат и найти партнёра без какой-либо организации.
Как проходят mock-интервью
В общих чертах процесс выглядит так: вы встречаетесь с незнакомым человеком и имитируете интервью по алгоритмам. На решение задачи даётся 40–60 минут для каждого и общение ведется на английском языке.
Перед встречей каждый участник готовит задачу для партнёра. Обычно заранее договариваются: о темах, о допустимой сложности, и о том, какие задачи не рассматривать (например динамическое программирование).
Дальше всё зависит от опыта — как вашего, так и оппонента - и в роли кандидата, и в роли интервьюера.
Когда задачу дают вам, кратко сценарий классический:
уточнить требования
обсудить возможные подходы
выбрать решение вместе с интервьюером
реализовать его.
Большой плюс mock-интервью - возможность посмотреть на процесс со стороны и получить живую обратную связь.
У всех людей есть свои приёмы и "фишки" - искренне верю что у каждого можно найти чему научиться.
Например, на одном из моков мне очень понравилось, как интервьюер вел логирование моих действий: фиксировал, что я спрашивал, какие решения предлагал и в какой момент. Настолько понравилось, что позже сделал для себя отдельный скрипт на node.js под это.
Почему записывать лог действий на интервью — это полезно
На реальных интервью такое встречается довольно часто. Пока вы решаете задачу, интервьюер может:
отмечать тайминг
фиксировать ваши вопросы
записывать ход мыслей и принятые решения
Это позволяет ретроспективно и объективно разобрать интервью: где были удачные шаги, а где — нет, как вы расставляли приоритеты и насколько эффективно использовали ограниченное время.
А в условиях жесткого тайминга это критически важно.
Мои типичные ошибки на моках
Одна из моих частых проблем — переусложнение решения в самом начале.
Бывало так: из условия сразу видно простое решение: понимаю, что оно "не то" и автоматически отбрасываю его, даже не озвучив.
В итоге: интервьюер не видит мой мыслительный процесс, я не даю никакой обратной связи, трачу время на сложный подход и иногда не успеваю решить задачу вообще.
На практике гораздо эффективнее:
начать с простого, пусть даже не оптимального решения
проговорить его ограничения
постепенно улучшать
Отсюда один из самых банальных, но рабочих советов, который оказался актуален и для меня: начинать с самого простого решения.
Даже если оно очевидное и неоптимальное: проговорите его вслух, обсудите с интервьюером, зафиксируйте(напишите) и уже потом двигайтесь к оптимизации.
Молчание и "мысли в голове"
Даже когда идея решения была, часто долго молчал, обдумывая ее внутри. В обычной жизни это нормально, но на интервью — плохо: интервьюер просто не понимает, что происходит.
Пришлось сознательно приучать себя:
проговаривать даже очевидные шаги
озвучивать сомнения
объяснять, почему выбираю тот или иной подход
Тайминг как отдельная польза mock-интервью
У моков есть ещё одно важное свойство — жесткий тайминг.
Решая задачи дома, легко растягивать решение: мозг отвлекается, появляется прокрастинация, внимание рассеивается.
На mock-интервью времени мало, и вы работаете максимально концентрированно.
Для многих это отличная тренировка и хорошее лекарство от прокрастинации.
Инструменты и ретроспектива
На всех моках я предлагал решать и рисовать в Excalidraw.
ASCII-графика у меня получается плохо и занимает слишком много времени.
После каждой сессии я делал ретроспективу, сохранял скриншоты наших "художеств", фиксировал комментарии оппонента.
Как дополнительный вариант — можно записывать процесс на видео, а потом анализировать: что пошло не так - а что, наоборот, получилось хорошо.
Альтернативные платформы
Раньше был популярный зарубежный сервис pramp, где можно было бесплатно проходить моки с рандомными людьми. Сейчас он, насколько я знаю, переименовался в exponent. На момент написания статьи там доступно до 5 mock-интервью в месяц.
Помимо этого существует множество платных платформ. Личного опыта с ними у меня не было, но при желании вы без труда найдёте подходящий вариант — поэтому ссылки приводить не буду.
Немного статистики и выводы
Всего у меня было около 15 mock‑интервью. Этого оказалось достаточно, чтобы привыкнуть к формату, снизить уровень тревожности, научиться структурировать ответы и перестать бояться пауз и уточняющих вопросов.
Со временем появился внутренний "скелет" ответа:
уточнить условие
предложить базовое решение
обсудить сложность
улучшить алгоритм
аккуратно закодить и проверить крайние случаи
Это сильно повышает ощущение контроля над ситуацией.
На мой взгляд, если вы активно готовитесь к интервью, то 30–40% всего времени подготовки стоит отдавать именно mock-интервью.
По формату и нагрузке они гораздо ближе к реальным собеседованиям, чем решение задач в комфортных домашних условиях.
Если смотреть на сухие цифры, то: примерно 50% задач на mock-сессиях мне удавалось решить.
Мой опыт: бумага, iPad и whiteboard ✍️
За время обучения автор успел попробовать, кажется, все возможные способы для решения алгоритмических задач.
В ход шло буквально все: бумага и ручка, iPad Pro 11, Amazon Kindle Scribe, обычный whiteboard, рисование мышкой или trackpad в Excalidraw и Miro, схемы "в голове", ASCII-диаграммы прямо в редакторе или на LeetCode.
Не пробовал разве что наскальную живопись.
Со временем пришел к довольно простому выводу: где и на чем решать задачу - в целом не так важно, если смотреть только на факт решения.
Разница начинается там, где вы хотите работать с этим материалом дальше.
Бумага: идеально "здесь и сейчас", но дальше начинаются сложности...
Обычная бумага отлично подходит для разовых задач и быстрого наброска своих идей. Ее главные плюсы: отсутствие отвлекающих факторов, порог входа (цена) и простота.
Но как только появляется необходимость хранить заметки, редактировать их, искать по ним, связывать между собой — бумага начинает проигрывать.
Даже если делать сканы, редактировать такие материалы неудобно, поиск ограничен и всегда есть риск потери или порчи.
iPad и Kindle
С точки зрения хранения и повторного использования iPad и Kindle выглядят логичнее, но ощущения от работы с ними сильно отличаются.
Amazon Kindle для меня максимально близок к бумаге: глаза почти не устают и ощущение от письма очень комфортное.
Но есть и ограничения: всё чёрно-белое (хотя для кого-то это может быть плюсом), нет нормальных гиперссылок, слабый поиск, медленный отклик из-за e-ink, отсутствие современных приложений для ведения заметок.
iPad Pro - полная противоположность: функциональность на 10/10, всё открывается мгновенно, удобный экспорт и работа с материалами.
Но: ощущения при рисовании другие, глаза устают заметно сильнее, особенно в конце рабочего дня и именно по этой причине я не могу использовать его на постоянной основе.
Whiteboard
Обычная доска с маркером — еще одна альтернатива бумаге. Я очень люблю рисовать на whiteboard - есть в этом что-то академическое.
Я даже делал вполне приличные фото-сканы таких схем, но дальше всплывают те же проблемы: сложно что-то поправить позже, тяжело встроить в цифровую систему, всё те же ограничения, что и у бумаги.
Тем не менее, могу понять ритуал рисования на доске.
Почему носитель — вторичен
Со временем мне стало ясно: сам инструмент почти не имеет значения, если нет процесса и сформированной привычки.
Можно:
иметь идеально настроенный Obsidian и не открывать его неделями
рисовать красивые схемы и при этом ничего не понимать
вести подробные конспекты и никогда к ним не возвращаться
И наоборот — простой лист бумаги плюс регулярная практика часто дают больше, чем любая сложная система без дисциплины.
Инструменты начинают работать только тогда, когда:
вы понимаете, зачем они вам нужны
используете их регулярно
возвращаетесь к старым материалам снова и снова.
Личный компромисс
Если положить руку на сердце — рисовать на бумаге мне нравится гораздо больше, особенно если взять цветные маркеры или карандаши.
Но в итоге пришлось выбирать между удовольствием "в моменте" и возможностью удобно использовать материал в будущем.
Для моих целей — обучение, повторение и систематизация — цифровой вариант оказался практичнее.
В конечном счёте я остановился на связке iPad + MacBook, а в качестве инструментов — Obsidian + Excalidraw, с синхронизацией между устройствами через iCloud.
Это решение дало баланс между: гибкостью, доступностью материалов и возможностью возвращаться к ним спустя время.
Если обобщить:
для мышления подойдёт любой носитель
для долгосрочного обучения важна структура и процесс, а не формат
систему стоит усложнять постепенно, по мере реальной необходимости
Я бы точно не стал начинать обучение алгоритмам с поиска "идеального инструмента".
Гораздо важнее — начать решать задачи, а уже потом подстраивать инструменты под себя и свой процесс.
Скачать мои шаблоны для Excalidraw
Скачать их здесь.
Алгоритмы — это не только про интервью
Хочу отдельно остановиться на том, какие побочные эффекты возникают при изучении алгоритмов. Причем эффекты эти, на мой взгляд, куда важнее, чем кажется на первый взгляд.
1. Понимание языка программирования на глубинном уровне
Алгоритмы довольно быстро заставляют разобраться в том, как язык работает под капотом. Не на уровне синтаксиса, а на уровне реального поведения.
Например:
как передаются аргументы в функции — копируются они или передаются по ссылке
что происходит с памятью при добавлении элементов в массив
где появляются лишние аллокации
что хранится в stack, а что - в heap
как устроены строки, кодировки и какие есть нюансы работы с ними
как реализуются стандартные и более сложные структуры данных
какие у всего этого есть ограничения и компромиссы
Конечно, можно возразить, что многие из этих вещей приходят с опытом на реальной работе. И это правда — но сильно зависит от конкретных задач. Вероятность регулярно сталкиваться со всеми этими вопросами в продакшене, на мой взгляд, не так уж велика.
(Если же вам повезло с такими задачами — искренне рад за вас и даже немного завидую 🙂)
Алгоритмы гарантированно вытаскивают все эти темы на поверхность и заставляют в них разобраться.
2. Неизбежное погружение в Computer Science
Второй эффект — одновременно и плюс, и минус.
При систематическом изучении алгоритмов практически невозможно избежать соприкосновения с классическим Computer Science. Лично я не очень разделяю "алгоритмы" и "CS", и многие инженеры, кстати, тоже.
Примеры здесь возникают постоянно:
работа со строками очень быстро упирается в кодировки и их способов хранения
рекурсия, которая должна писаться "как почистить зубы", напрямую связана со stack, heap, работой процессора и регистрами
числа разных типов — это уже про представление данных в памяти и особенности вычислений
и так далее, и так далее
В итоге приходится погружаться в фундаментальные темы нашего ремесла. Считаю это большим плюсом: появляется цельная картина того, как всё устроено.
Минус тоже очевиден — цена вопроса, а именно время, которое нужно дополнительно инвестировать, чтобы во всём этом разобраться.
3. Формирование инженерного мышления
И последнее, но, пожалуй, самое важное.
Алгоритмы очень хорошо воспитывают отношение к задачам через логику, рассуждение и прагматичный подход. Со временем начинаешь понимать, что решать алгоритмическую задачу гораздо проще, если:
сначала осознать и четко сформулиро��ать проблему
явно выделить входные данные и ограничения
думать о крайних случаях
отбросить лишнее простой логикой
наметить план решения, что-то набросать, нарисовать и дальше двигаться шаг за шагом, снова опираясь на здравый смысл
заранее прикидывать сложность решения
Звучит знакомо? По сути, это ровно те же качества, которые делают инженера сильнее в реальной работе и в жизни в целом.
За свою карьеру я видел немало "разработчиков". И могу уверенно сказать: человек, который умеет планировать, разбивать задачу на небольшие шаги, логически переходить между ними и аргументировать свои решения — на вес золота.
Искренне считаю, что работа с алгоритмами — один из самых надежных способов стать именно таким инженером.
Ситуации когда мне пригодились алгоритмы на работе или в жизни.
Чтобы немного снизить скепсис в духе "алгоритмы — это только для собеседований", приведу несколько реальных примеров из практики. Без теории ради теории — только то, что действительно встречалось в работе.
Поиск по файлу: простой двоичный поиск
Когда работал в команде биллинга, у нас была задача загружать файл с мобильными номерами для последующей блокировки по бизнес-логике.
Во время загрузки по этому файлу нужно было выполнять поиск.
В какой-то момент предложил коллеге использовать двоичный поиск вместо линейного.
Результат оказался довольно наглядным: загрузка, которая раньше занимала около часа, стала выполняться за несколько минут.
Мелочь? Возможно.
Но приятно - и, что важнее, быстрее.
Подбор номиналов: комбинаторика и динамическое программирование
В том же биллинге возникла ещё одна задача — подбор "купюр" для оплаты.
Проще говоря, нужно было разложить сумму платежа на уникальные комбинации существующих номиналов.
По сути, это классическая задача на комбинаторику и динамическое программирование.
Я даже разбирал похожий пример в видео на YouTube.
Такие задачи на первый взгляд выглядят "академическими", но в реальных системах встречаются куда чаще, чем кажется.
Графы для обработки очередности запросов
Ещё один пример — идея, которая не была доведена до продакшена, но хорошо иллюстрирует ход мыслей.
На предыдущей работе предложил концепцию на графах для сохранения логической последовательности запросов, приходящих из внешней системы.
Суть была в том, чтобы описывать flow в виде графа, а затем - в зависимости от типа HTTP-запроса - определять, какой из них должен обрабатываться в текущий момент времени.
Даже если идея не дошла до реализации, именно алгоритмическое мышление позволило быстро сформировать такую модель.
Связные списки в игровой логике
Несколько месяцев назад писал небольшую игру — классическую "змейку" — на Rust. Для реализации логики движения змейки я использовал связный список.
Да, можно было обойтись и другими структурами, но здесь он оказался естественным и удобным решением.
Топологическая сортировка в RoadRunner
И последний пример — уже из чтения чужого кода.
Когда я разбирался с корневым плагином RoadRunner - а именно с этим репозиторием -
стало очевидно, что загрузка плагинов там построена на топологической сортировке.
Благодаря базовому пониманию алгоритмов мне не пришлось долго "продираться" через исходники - логика решения была сразу понятна.
Подытожу
Cмело могу сказать, что подобные ситуации регулярно встречаются в работе и карьере.
Фундаментальные знания алгоритмов и структур данных дают вам возможность: быстрее видеть возможные оптимизации, легче читать и понимать чужой код, находить более чистые и логичные решения.
Поэтому, по моему скромному мнению, алгоритмы — это не аб��трактная теория и не только про собеседования.
Это навык, который реально помогает инженеру в повседневной работе.
Дневник занятий: зачем его вел и что он дал
Итак, в течение первого года обучения я вел дневник занятий в Telegram.
Каждый день писал небольшой отчет: что получилось, что не получилось, сколько времени ушло на обучение, делился полезными ссылками и своими ощущениями от процесса (некоторые из них я приведу ниже по тексту).
Идея дневника пришла не сразу — примерно через месяц — два после начала занятий.
В какой-то момент я понял, что такой формат может быть полезен сразу в нескольких смыслах: как ретроспектива для себя, как способ лучше осознавать собственный прогресс и, возможно, как полезный опыт для других.
Поэтому начал фиксировать каждый день в формате короткого мини-отчета.
На второй год обучения дневник перестал быть именно дневником в классическом смысле. Канал остался, но уже как место для заметок о computer science, алгоритмах и размышлений по ходу обучения.
Стоит ли вести дневник?
Решать, конечно, каждому. Ниже — несколько плюсов и минусов, которые могут помочь определиться.
Плюсы
Поддержка мотивации на длинной дистанции.
Когда вы фиксируете мысли и результаты, а затем возвращаетесь к ним спустя месяцы, прогресс становится наглядным.
Очень отрезвляет увидеть свою запись полугодовой давности в духе:
"Боже, это невозможно, я ничего не понимаю" — и осознать, что сегодня эти задачи кажутся вполне решаемыми.Более качественный рост за счёт анализа ошибок.
Дневник отлично работает как инструмент ретроспективы на любом этапе обучения: что не получилось, почему, какие выводы можно сделать.Дисциплина.
Особенно если дневник публичный. Он заставляет регулярно останавливаться, анализировать прошедшее занятие и, что важно, не пропускать обучение.Вдохновение для других.
Честный дневник хорошо резонирует с людьми. Он показывает, что вы — обычный человек, который прошёл длинный путь, а не стал "умным внезапно, проснувшись однажды утром".
Минусы
Время и отложенный эффект. Дневник требует регулярных затрат времени, а его польза почти не ощущается "здесь и сейчас". Это скорее долгосрочная инвестиция: сегодня вы вкладываетесь, а отдачу начинаете видеть значительно позже.
Страх "забыть все алгоритмы"
"Мы все учились понемногу Чему-нибудь и как-нибудь…"
Страхи есть у каждого - и с ними имеет смысл иногда работать.
Давайте разберём один из самых популярных страхов, связанных с алгоритмами.
Алгоритмы действительно забываются — и это нормально
К сожалению (или к счастью), любые знания со временем выветриваются, если им не находится применения.
Это верно для любого навыка.
Выучили иностранный язык, но не используете его?
Результат предсказуем — через какое-то время он начинает забываться.
С алгоритмами ровно та же история.
Если не практиковаться, навык решения задач действительно деградирует.
Но есть важный нюанс:
👉 если навык уже был, то восстановить его за относительно короткое время гораздо проще, чем учить всё с нуля.
Именно по этой причине многие крупные компании дают время на подготовку к собеседованиям.
Они прекрасно понимают, что реальная работа - это не ежедневное решение задач на LeetCode, а совсем другой набор активностей и навыков.
Все упирается в цель
Прежде чем переживать, "забудете вы алгоритмы или нет", полезно честно ответить себе на вопрос: зачем вы их учите?
Цель №1 - получить работу
Отлично.
Выучили → прошли собеседование → успешно забыли.
Схема знакома ещё со школы.
Цель №2 - держать мозг в тонусе
Тогда относитесь к алгоритмам как к кроссвордам.
Пара задач в неделю - и этого более чем достаточно для поддержания формы.
Цель №3 - стать более квалифицированным инженером
И вот тут начинается самое интересное.
Моё мнение простое: навыки существуют для того, чтобы их использовать. Иначе они теряют смысл. Если вы действительно хотите сохранить и развивать алгоритмическое мышление:
ищите задачи ближе к низкоуровневой разработке
участвуйте в open-source проектах (да пишите хоть в core linux!)
пробуйте смотреть на рабочие проблемы через призму алгоритмов
размышляйте о структуре данных и эффективности решений в повседневной работе.
При таком подходе вы найдёте применение этим знаниям в реальной жизни.
Немного фантазии напоследок
Представим ситуацию. Вы работаете в продуктовой разработке:
пилите UI, перекладываете JSON из базы в клиент и обратно. Почти культовая классика — "JSON туда и обратно". Затем вы тратите пару лет на фундамент: изучаете computer science, разбираетесь в алгоритмах и структурах данных, прокачиваете мышление.
Вопрос:
каковы шансы, что вам всё ещё будет интересно заниматься тем же самым?
Ответ каждый пусть найдёт для себя сам. 🙂
Вместо вывода
Относиться к знаниям стоит как к навыку, который должен работать, а не как к галочке в резюме.
Получать второе высшее образование "ради престижа" - сомнительная идея.
Но учиться чему-то осознанно — по мне, гораздо лучше, чем просто прокрастинировать и смотреть бесполнезные рилсы.
❤️ Семья и баланс
Формально тема семьи касается этой статьи лишь косвенно, но на практике она напрямую влияет и на количество свободного времени, и на уровень мотивации.
Кроме того, меня регулярно задевали комментарии в духе:
"Ну да, попробуй учить алгоритмы, когда у тебя семья и дети".
Поэтому решил немного разбавить технический контекст своим субъективным опытом и мнением.
Плохая и хорошая новость
Начну с плохой: у меня нет простого рецепта или "серебряной пули", как идеально сохранить баланс между семьей, жизнью и обучением.
Это очень индивидуальный и, по-своему, философский вопрос.
Хорошая новость в том, что ответ можно найти самому — если честно перед собой определить важность цели.
По моим ощущениям, по-настоящему важная цель всегда немного ревнива: она не любит конкурентов и требует внимания.
Поэтому каждому приходится самостоятельно расставлять приоритеты и искать свой баланс.
Очень точно это описал Альберт Эйнштейн:
"Жизнь — как езда на велосипеде: чтобы сохранить равновесие, нужно двигаться".
Из этого следует простой вывод: если у вас действительно есть цель — будь то изучение алгоритмов, поступление в вуз или освоение новой темы — компромисс почти всегда можно найти.
В моём случае это были:
ранние утренние часы, когда все еще спали
иногда — поздний вечер после работы
Честно скажу: это два не самых комфортных варианта.
Утром ты еще не до конца проснулся, вечером — уже "никакой" и плохо соображаешь.
Но именно так выглядел мой компромисс на текущий момент.
Здесь очень кстати вспоминается еще одна цитата — от Теодор Рузвельта:
"Делай, что можешь, с тем, что имеешь, там, где ты есть".
Про приоритеты и цену выбора
Если говорить честно, без жертв не обошлось.
Иногда я жертвовал сном, иногда — временем с близкими, иногда — личными увлечениями.
Самый неприятный опыт оказался связан со спортом.
Я фактически "задвинул" физическую активность, которая десятки лет была частью моей повседневной рутины и, как выяснилось позже, хорошим источником серотонина.
Из этого сделал важный вывод и для себя: не стоит полностью отказываться от увлечений и особенно от физической активности.
В долгосрочной перспективе это сильно бьет по психологическому состоянию и умственной энергии — по крайней мере, так было в моём случае.
Итоговый баланс
Обучение должно встраиваться в повседневную жизнь, а не становиться ее единственным смыслом.
Гораздо эффективнее каждый день делать небольшие шаги в разных сферах, чем полностью смещать баланс в одну сторону.
Попробуйте честно посмотреть на свой график:
где можно выкроить час — два
сколько времени уходит на YouTube, соцсети и "залипание";
какие занятия можно временно сократить без боли
Я почти уверен, что при желании 1–2 часа в день найти можно.
А если не получается — значит, у вас просто другие приоритеты.
И это, кстати, тоже хорошая новость: вы честно поняли, что алгоритмы сейчас не являются вашей целью.
Да, возможно, всё это звучит банально.
Но если у меня получилось - я искренне верю, что получится и у вас.
Что на самом деле проверяют алгоритмы на интервью
За год регулярных занятий, решения задач и изучения разных источников про алгоритмические интервью у меня сложилось довольно цельное представление о том, зачем вообще этот формат существует.
Если говорить честно, алгоритмические задачи на интервью — это далеко не только про сами алгоритмы.
В осознанном виде это один из способов проверить, как инженер решает проблемы в условиях ограниченного времени.
Алгоритмы — это лишь инструмент
В больших компаниях алгоритмическая секция используется как формат, позволяющий за короткое время собрать множество сигналов о кандидате.
При этом проверяют не столько знание конкретных приемов, сколько:
подход к решению задачи
умение коммуницировать
способность планировать
навык декомпозиции
реакцию на неопределенность и обратную связь.
Проще говоря, алго-интервью — это симуляция мышления инженера, а не экзамен по учебнику.
Какие сигналы пытаются "поймать"
Простой пример.
Интервьюер даёт задачу, и кандидат сразу начинает писать решение, не задав ни одного вопроса.
Возникает логичный вопрос: будет ли он уточнять требования в реальной работе или тоже сразу "бежать кодить"?
Другой сценарий — кандидат задаёт вопросы. И тут важно не само наличие вопросов, а:
какие именно вопросы он задаёт
зачем он их задает
думает ли он перед этим или просто следует шаблону
Например, классический вопрос:
"А могут ли в массиве быть отрицательные числа?"
Иногда он важен, а иногда не влияет на решение вообще.
Интервьюеру важно понять: кандидат действительно анализирует задачу или просто воспроизводит заученный чек-лист.
Также обращают внимание на другое:
умеет ли кандидат начинать с простого решения и постепенно его улучшать
может ли он разбить задачу на понятные шаги
что он делает, если застрял - спрашивает или молча пытается "продавить" решение
легко ли его сбить с выбранного плана неудачным комментарием.
Все эти моменты довольно легко проецируются на реальную работу в команде.
Идеального способа оценить инженера за час не существует.
Алгоритмическое интервью — это просто один из компромиссных форматов, который прижился в больших компаниях.
Он позволяет: быстро проверить инженерное мышление, увидеть стиль коммуникации, оценить базовые soft skills.
Кстати, у FaangTalk есть хорошее видео на эту тему.
Я даже делал конспект у себя в дневнике: там опытный инженер подробно рассказывает, на какие сигналы реально смотрят в больших компаниях. Очень рекомендую всем, кто задумывается о карьерном росте и не только в MAANG-like компании.
Немного про критику алгоритмов
Алгоритмические интервью часто критикуют - и не без оснований.
Часть претензий справедлива, часть — скорее эмоциональна.
Большие компании для себя этот формат давно приняли и отточили.
Маленькие компании иногда просто копируют его, не всегда понимая, зачем именно они это делают.
Если вы целитесь в BigTech, то на момент написания статьи правила игры остаются прежними — их придётся принять и к ним подготовиться.
Лично для меня алгоритмы — это не только способ пройти интервью. У меня к ним чисто инженерный интерес.
Я воспринимаю любую алгоритмическую задачу как challenge - и на собеседованиях, и в реальных рабочих ситуациях.
С таким подходом формат перестаёт раздражать и начинает приносить удовольствие.
И, пожалуй, именно это отношение в итоге мне дает максимальную пользу.
Стоило ли все это того?
Почти под каждой статьей про алгоритмы можно найти комментарии в духе:
"В реальной жизни алгоритмы не нужны",
"С появлением ИИ это вообще потеряло смысл".
Когда-то давно я читал обсуждение на похожую тему — нужна ли математика программисту.
Один из комментариев звучал так:
"Я работаю программистом N лет, и математика мне ни разу не пригодилась".
На что ему логично ответили: как может пригодиться то, чем ты не владеешь?
Можно представить и более абсурдную ситуацию.
Например, человек не знает английский язык и утверждает, что он ему никогда в жизни не пригодился.
Вопрос тот же самый: как он мог пригодиться, если вы его не знаете?
Computer Science и алгоритмы — это не абстрактная теория.
Это знания и навыки, которые напрямую применяются в программировании.
Сложно "увидеть" двоичный поиск, если ты: никогда его не писал, не понимаешь, где он уместен, не применял его на практике.
Знания сами по себе не решают задачи за вас — но они открывают новые возможности.
А как именно эти возможности использовать — зависит уже только от инженера.
После опыта, описанного в этой статье, у меня заметно изменился подход к мышлению и решению задач в работе в целом.
Мне стало интересно браться за более сложные проблемы, а большие и нагруженные системы теперь выглядят куда более прозрачными и понятными, чем два года назад.
Про подготовку и ожидания
Важно понимать: чтобы подготовиться к интервью, необязательно идти в таком же темпе, как это делал я.
По моим ощущениям, если начинать с нуля, то: год занятий по ~2 часа в день — вполне разумный срок, чтобы подготовиться к интервью в BigTech.
Я же продолжал заниматься с большей интенсивностью по другой причине — из-за собственного инженерного интереса и искренней любознательности.
Ну и, честно говоря, без упрямства и характера тут тоже не обошлось.
Если вы еще в раздумьях — начните спокойно и без давления на себя.
Вы довольно быстро поймёте, "ваше" это или нет.
Момент истины обычно наступает тогда, когда: вы начинаете получать удовольствие от решенных задач и появляется чувство гордости за аккуратное или элегантное решение.
Если вы уже на полпути — не сдавайтесь.
Недаром говорят: у самурая нет цели, есть только путь.
Старайтесь получать удовольствие от процесса, фокусироваться на маленьких победах и не спешить.
В сложности как раз и заключается весь смысл и интерес.
Легкие задачи редко приносят удовлетворение — как и в жизни: сначала преодоление, потом награда.
Если что-то не получается — не расстраивайтесь.
Важно понимать и выучить подход, а не конкретную задачу.
При эт��м стоит быть честным: на LeetCode есть категории задач, где решение просто нужно знать.
Чаще всего встречал в задачах на Prefix Sum — вот один из примеров.
Все задачи запомнить невозможно — да и не нужно. Гораздо важнее научиться думать и узнавать знакомые паттерны.
Также не менее важно уметь различать: "это не моё" и "я просто устал". Отдохните, переключитесь и попробуйте ещё раз. Если это действительно ваше — вы всё равно к этому вернётесь.
В заключение хочу оставить простую мысль, сформулированную одним известным музыкантом:
Time spent enjoying is not time wasted.
Что дальше и где логичный конец?
У этой истории нет классического финала. Здесь нет формулы вида: "хотел A, сделал B и получил C".
По законам жанра в этом месте автор должен был бы написать, что теперь работаю в Google, или, наоборот, пройти через миллион собеседований и нигде не получить оффер — особенно учитывая, что в начале статьи цель действительно звучала именно так.
Но реальность оказалась сложнее и, пожалуй, честнее.
На текущем этапе жизни мои планы немного изменились. Я пока не подаюсь и не прохожу интервью в крупные компании. Тем не менее мне показалось важным подытожить этот опыт именно сейчас — зафиксировать мысли, выводы и материалы, пока они не покрылись пылью и не утратили актуальность, или, как иногда говорят, "не канули в лету".
Знания, которые получил за эти два года, я считаю чрезвычайно полезными — по крайней мере, лично для себя. Причем ценность оказалась не в количестве решенных задач или цифрах в профиле на LeetCode, а в том, как изменилось мышление и подход к сложным задачам, ну и безусловно сами технические знания.
В ближайшее время не планирую каждый день тратить время именно на "прорешивание" алгоритмических задач. Скорее, фокус смещается в сторону изучения смежных тем и применения уже полученных знаний в более прикладных областях — там, где они действительно дают практическую пользу.
Скорее всего, в зависимости от настроения, продолжу выкладывать видео с разборами задач у себя на канале. Но, как уже писал выше, сейчас хочется использовать приобретенные навыки для чего‑то большего, чем просто красивые цифры и статистика на платформе с задачами.
Алгоритмы для меня перестали быть самоцелью. Они стали инструментом - и, возможно, именно в этом и был их главный смысл.
Кто знает, возможно, спустя какое‑то время я вернусь с новой статьей.
Например, с названием:
"Как я прошел интервью в Google".
А может и с совсем другой историей...
Полезные ресурсы и инструменты для изучения алгоритмов
За время подготовки собрал довольно большой набор инструментов и ресурсов, которые так или иначе помогали мне в обучении. Ниже — список того, чем реально пользовался или что показалось мне полезным. Не обязательно использовать все сразу, но, возможно, что‑то из этого хорошо ляжет именно в ваш процесс.
Браузерные расширения для LeetCode
LeetCode Forcer Google Chrome
Расширение, которое "принудительно" предлагает решить задачу дня: при открытии сайта происходит редирект, пока задача не будет решена. Насколько такой подход подойдёт именно вам - вопрос открытый, но как способ борьбы с прокрастинацией может быть полезен, особенно если сложно заставить себя начинать.
LeetCode Recall Google Chrome
Плагин, который напоминает о задачах, решённых ранее. Идея в том, чтобы возвращаться к старым решениям и освежать их в памяти. По сути, это упрощённая альтернатива самостоятельному менеджменту повторений. Может быть полезен, если вы хотите лучше удерживать решения в долгосрочной памяти.
Leetcode Difficulty Rating
На мой взгляд, один из самых полезных плагинов. Он показывает более точный рейтинг сложности задачи, основанный на данных из LeetCode Contest, а не только на категориях Easy / Medium / Hard.
К слову, не так давно сам LeetCode начал добавлять похожий показатель - Contest Rating — прямо на странице задач но только для Premium подписок.
Подборки задач и фреймворки/инструменты
LeetCode Patterns by Sean Prashad
Сайт с подборкой популярных задач, сгруппированных по темам и компаниям. Хорошо подходит для системного прохождения паттернов.
Фреймворк или рекомендации по задачам от канала "Кодируем"
Документ с рекомендациями по подходу к решению задач. В статье выше я уже упоминал этот канал, а здесь можно подробнее почитать про методологию и, в частности, про Bloom’s Taxonomy в контексте обучения.
Топ 100 залайканных задач
Подборка из 100 самых залайканных задач на LeetCode. Это скорее список "для удовольствия": многие задачи здесь нестандартные и не всегда относятся к категории "обязательно знать для интервью", но отлично прокачивают мышление.
Список всех возможных badges на Leetcode
Полезно скорее из любопытства и для понимания, какие активности вообще существуют на платформе.
LeetCode 75 и Top Interview 150
Два официальных списка задач от LeetCode, которые часто рекомендуют для подготовки к интервью. Хорошая отправная точка, если вы не знаете, с чего начать.
LeetSolv
Сам я не пробывал но выглядит интересно. Это консольная утилита, написанная на Golang для подготовки к собеседованиям по алгоритмам и структурам данных.
Помогает повторять задачи по умному расписанию (алгоритм SM-2) и не забывать то, что уже решал.
Небольшой психологический трюк
Один раз я видел забавный приём:
можно открыть devtools в браузере и заменить в HTML красную надпись Hard на жёлтую Medium. Формально задача не меняется, но психологически решать её становится чуть легче.
Работает ли это — не гарантирую, но иногда такие мелочи действительно снижают внутренний барьер.
Книги и визуальные материалы
Думай как математик — Барбара Оакли
Книга не про алгоритмы напрямую, но про подходы к обучению и мышлению. Помогает лучше понять, как учиться сложным вещам и не застревать в ощущении "я ничего не понимаю".
Сайт с визуализациями алгоритмов и структур данных. Особенно полезен на ранних этапах, когда важно "увидеть", как именно работает алгоритм.
Сообщество и совместная подготовка
Для поддержки и более эффективной подготовки к MAANG‑подобным компаниям могу порекомендовать Telegram‑сообщество faangtalk.
В чате много ребят, которые уже проходили интервью или готовятся к ним сейчас. Там регулярно организуют mock‑интервью по алгоритмам, а также можно просто написать что‑то вроде:
"Привет, кто хочет помокаться?" - и довольно быстро найти партнёра.
У ребят есть и Youtube канал , где они выпускают тематические видео и делятся историями прохождения интервью.
Также могу отметить neetcode - англоязычный YouTube‑канал с качественными разборами алгоритмических задач.
Личные ссылки
Мой профиль на Leetcode
Мой основной телеграм канал
Мой профиль на github
Мой телеграм дневник и канал по CS
