434 задачи, 1450 сабмитов — мой путь к пониманию того, как на самом деле работают алгоритмические интервью
Введение
Всем привет! Меня зовут Евгений Мацюк. Сейчас я работаю в X (Twitter) на позиции Staff Software Engineer, до этого — TrustWallet, Careem, Kaspersky. Я соавтор Kaspresso, co-founder в MarathonLabs и Android Google Developer Expert с 2020 года.
За последние годы (2021-2025) я прошёл кодинг-интервью в X, Google, Careem, TrustWallet, Yandex и много других компаний. И знаете что? Я прошёл абсолютно все. При этом на интервью в Google в 2022 году я даже не до конца решил задачу — сказалось сильное волнение. Но интервьюер остался доволен, и рекрутер это подтвердила.
Как так вышло? Дело не в количестве решённых задач (хотя 434 — это немало). Дело в понимании того, что на самом деле оценивается на этих интервью и как правильно себя вести. Об этом и поговорим.
Три формата кодинг-интервью
Прежде чем погружаться в Leetcode, давайте быстро пробежимся по форматам кодинг-интервью, которые вам могут встретиться:
Leetcode-style задачки — самый распространённый формат. Классические алгоритмические задачи в shared-редакторе. Именно о нём эта статья.
Ревью кода + фича в блокноте — по моему мнению, самый адекватный формат. Вы делаете то, что делаете каждый день: смотрите чужой код и пишете свой. Мелкие помарки прощаются, можно писать на псевдокоде.
Реальный проект в IDE — самый хардкорный вариант. Нужно написать работающее решение, которое запустится. Обычно занимает от 90 минут. Хорошая новость: часто разрешают подготовить скелет проекта заранее.
Leetcode остаётся самым популярным форматом, поэтому сфокусируемся на нём.
Мифы и реальность
Миф #1: Нужно решать hard и крутить красно-чёрное дерево во сне
Реальность: Это было правдой лет 5-7 назад. Сейчас индустрия осознала, что умение решать hard-задачки ничего не говорит о том, какой вы в повседневной работе, архитектуре и коммуникации.
Я наблюдаю демократизацию процесса: акцент смещается на easy/medium задачи и на умение кандидата коммуницировать. За все мои интервью (2021-2025) мне ни разу не попалась задача на динамическое программирование — то самое «демоническое», которым всех пугают.
Миф #2: Результат бинарный — решил или провалил
Реальность: Совсем не бинарно. У задачи почти всегда несколько решений. Brute force очевиден, и важно его озвучить. Оптимальное решение — это хорошо, но не обязательно.
На том самом интервью в Google я не дошёл до оптимального решения. Но я правильно коммуницировал, показал ход мыслей, и этого оказалось достаточно.
Миф #3: Главное — знать алгоритм
Реальность: Знание алгоритма — лишь одна часть, и я бы не сказал, что самая важная. Вы можете не знать оптимального решения в начале — это нормально. Важен процесс: как вы думаете, как общаетесь, как реагируете на подсказки.
Интервьюер почти всегда будет вам помогать. Слушайте его! Подсказки обычно достаточно жирные.
Миф #4: На разных уровнях разные требования к кодинг-интервью
Реальность: Это правда — требования разные. На junior/middle кодинг — ваша главная секция, и спрашивать будут серьёзно. На senior/staff/principal это скорее проверка, что вы ещё помните, как программировать. Там важнее system design и behavioral.
Подготовка
Ресурсы
Я перелопатил много материалов за годы подготовки. Большинство либо устарели, либо содержат много лишнего типа логических задач «сколько крышек люка в городе».
На 2026 год мой главный совет — Leetcode Premium. Да, это стоит денег, но это разумная инвестиция. Там есть:
Структурированные курсы по темам
Задачи, отсортированные по компаниям
Качественные решения с объяснениями
Начать можно с базового курса. Дальше — раздел Learn для углубления в конкретные темы и раздел Interview для подготовки к конкретным компаниям.
Для быстрого повторения алгоритмов использовал документ с обнадёживающим названием "I'll sleep when I'm dead".
Моки — ключ ко всему
А теперь самое важное: моки. Mock-интервью. Как только освоите базу — сразу приступайте к ним. Просите знакомых, находите партнёров в интернете, используйте специальные платформы.
Пока не проведёте хотя бы 10 моков — не тратьте время на настоящие интервью.
Почему это так важно? На моках вы получаете реальную симуляцию: стресс, ограниченное время (15-30 минут), необходимость думать вслух. Это совсем другой опыт, чем решать задачки в одиночестве.
Ритуал решения задачи
Это, пожалуй, самая важная часть статьи. Правильный ритуал — это то, что отличает успешное прохождение от провала.
Шаг A: Выслушайте и уточните
Выслушайте интервьюера до конца, не перебивайте. Затем задайте уточняющие вопросы. Даже если вам всё кажется понятным — уточните corner cases:
Какой максимальный и минимальный размер массива?
Какие максимальные и минимальные значения элементов?
Могут ли быть отрицательные числа?
Отсортированы ли данные?
Какая максимальная длина строки?
Могут ли быть дубликаты?
Эти вопросы показывают, что вы думаете как инженер, а не просто кодер.
Шаг B: Покажите brute force
Проговорите и покажите очевидное решение. Именно покажите — не просто скажите словами.
Посчитайте сложность по времени и памяти. Спросите интервьюера: «Всё ли понятно? Согласны с решением?»
Шаг C: Обсудите оптимизацию
Для задач уровня medium и выше обычно есть более оптимальное решение. Обсудите с интервьюером — хотите ли вы искать его сейчас или сначала реализовать brute force.
Если не знаете оптимального решения — не паникуйте. Интервьюер будет подсказывать. Но даже если так и не придёте к оптимуму — можно реализовать brute force. Это лучше, чем ничего.
Шаг D: Имплементация
Спросите: «Могу приступать к коду?» Получив добро, начинайте писать.
Проговаривайте то, что делаете. Буквально: «Создаю массив для результата. Завожу переменную для суммы. Итерируюсь по входному массиву...» Что вижу — то и говорю.
Называйте переменные по-человечески. Не a, b, i, а currentSum, leftPointer, resultList.
Если где-то код получается не идеальным (а под стрессом это нормально) — оставьте комментарий: // TODO: refactor later. Это показывает, что вы понимаете, где можно улучшить.
fun calcSum(input: List<Int>): Int {
// TODO: handle empty input
var sum = 0
for (elem in input) {
sum += elem
}
return sum
}
Шаг E: Дебаггинг
Этим этапом очень любят пренебрегать. А он критически важен.
Дебаггинг — это не «пробежаться глазами по коду». Это написание комментариев с промежуточными значениями на каждом шаге.
Подробнее об этом — в разделе лайфхаков ниже.
Лайфхаки и визуализация
Как объяснять алгоритм без кода
Когда я начинал готовиться, меня ставило в тупик: как объяснить работу алгоритма, не написав код? На словах получается путано, особенно если оба не носители языка.
Решение: объясняйте письменно, прямо на структурах данных.
Работа с массивами
Используйте индексы и указатели в виде !:
[2, 4, 6, 8, -1, 3]
[0, 1, 2, 3, 4, 5]
!
Для двух указателей (sliding window):
[2, 4, 6, 8, -1, 3]
[0, 1, 2, 3, 4, 5]
!
!
При объяснении просто двигайте указатели и показывайте каждый шаг. Прописывайте переменные:
sum = 1
tempSum = 5
Работа с деревьями
Рисуйте дерево наглядно:
6
2 8
1 3 7 9
Используйте ! как указатель текущей позиции и * как пометку обработанного узла:
!6
*2 8
*1 !3 7 9
Здесь видно: начали с корня (6), пошли влево (2), ещё левее (1), обработали 1, обработали 2, сейчас в правом потомке двойки — это 3.
Визуализация рекурсии
[1, 2]
!
[4, 5, 6]
!
[7, 8, 9]
!
Каждая строка — уровень рекурсии. Указатель показывает, где находимся.
Дебаггинг в коде
Вот пример кода:
fun calcSum(input: List<Int>): Int {
var sum = 0
var threshold = 0
for (elem in input) {
if (elem >= threshold) {
sum += elem
threshold = sum / 2
}
}
return sum
}
Допустим, input = [1, 3, 5, 7, -1, 2, 9].
Дебаггинг выглядит так — для каждого шага прямо в коде пишем значения:
// input: [1, 3, 5, 7, -1, 2, 9]
// !
fun calcSum(input: List<Int>): Int {
var sum = 0 // 0
var threshold = 0 // 0
for (elem in input) { // elem = 1
if (elem >= threshold) { // 1 >= 0? true
sum += elem // sum = 1
threshold = sum / 2 // threshold = 0
}
}
return sum
}
Переходим ко второму элементу:
// input: [1, 3, 5, 7, -1, 2, 9]
// !
fun calcSum(input: List<Int>): Int {
var sum = 0 // 1
var threshold = 0 // 0
for (elem in input) { // elem = 3
if (elem >= threshold) { // 3 >= 0? true
sum += elem // sum = 4
threshold = sum / 2 // threshold = 2
}
}
return sum
}
И так далее. Это наглядно для интервьюера и помогает вам отловить ошибки.
Вспомогательные функции
Иногда решения получаются объёмными — 100-200 строк вместо 20-30. Используйте вспомогательные функции, которые реализуете потом:
fun someSolution() {
// основная логика
val diff = calculateDiff()
// продолжение логики
}
private fun calculateDiff() {
// will be implemented later
}
Это позволяет не отвлекаться от главного алгоритма и быстрее показать общую картину.
Правило одной строки
Одна строчка — одно действие. Это упрощает дебаггинг и чтение кода. Не пишите:
if (a > b && c < d || e == f) return doSomething(x, y, z).also { process(it) }
Разбивайте на понятные шаги.
Corner cases в конце
Сначала реализуйте общее решение, потом добавьте обработку corner cases:
fun calcSum(input: List<Int>): Int {
// TODO: handle corner cases (empty input, single element)
// основная логика
...
}
Преимущества и недостатки Leetcode-формата
Давайте честно.
Для кандидата преимуществ почти нет. Кроме того факта, что эти задачки помогут найти работу. Знание алгоритмов редко пригождается в повседневной работе. Структуры данных и сложность операций вы и так должны знать — это база. А вот время на подготовку уходит прилично.
Для интервьюера преимуществ много:
Интервью укладывается в 30 минут
Кода немного, легко оценить
Чеклист понятный
При желании можно завалить любого кандидата hard-задачей (так никто не делает, но возможность есть)
Несмотря на спорность формата, он остаётся самым популярным. Но ситуация улучшается: акцент смещается с «решил/не решил» на коммуникацию и процесс мышления.
Заключение
Подытожим главное:
Мифы устарели. Hard-задачи и экзотические алгоритмы уже не так важны. Коммуникация важнее знания оптимального решения.
Моки обязательны. Минимум 10 штук перед реальными интервью.
Ритуал решает. Уточняющие вопросы → brute force → обсуждение → имплементация с проговариванием → дебаггинг.
Визуализируйте. Показывайте работу алгоритма на структурах данных, не объясняйте только словами.
Дебажьте в коде. Пишите промежуточные значения прямо в комментариях.
Эти правила помогли мне пройти все кодинг-интервью за последние 4 года. Надеюсь, помогут и вам.
Всем бобра и успешных собесов! ?
Пишите в комментариях свой опыт и вопросы. Какие мифы о Leetcode слышали вы?
Больше про интервью, мобильную разработку, стартапы и жизнь инженера за рубежом — в моём телеграм-канале: t.me/matsiuk_speak
Комментарии (13)
sic
14.01.2026 13:19Начинается пост интересно, результаты на литкоде неплохие, биография вообще интересная, но мы быстро и глубоко погружаемся в легко узнаваемый характерный LLM контент.
Реальный проект в IDE — самый хардкорный вариант. Нужно написать работающее решение, которое запустится. Обычно занимает от 90 минут. Хорошая новость: часто разрешают подготовить скелет проекта заранее.
Это про хакатоны, для тех кто не знает слова хакатон? Да, это формат возможного найма на работу, но точно не формат собеседования, или хотелось бы хотя бы один пример компании, которые так и собеседуют. Тестовое задание под это описание так себе подходит. Что имелось в виду?
Несмотря на то, что в абзаце "Ритуал решения задачи" я в целом со всем согласен, но согласен я лишь потому, что уже имею свой опыт прохождения таких собеседований, и читаю немного "по диагонали". Обычно дается не более 15-30 минут на задачу, и если много временить тратить на "уточнение corner cases" и написание "наивного решения", то то решение, которое ожидалось увидеть вы просто не успеете написать.
Для задач уровня medium и выше обычно есть более оптимальное решение.
Более оптимальное, чем наивное? Так для большинства easy задач оно тоже есть, более того, это вся суть задачи. Начинать с имплементации менее оптимального, чем подразумеваемое оптимальное решение, опять же просто трата времени. И лишний стресс из-за того, что даже наивное решение можно написать криво, и потратить на это время. Не надо писать вычисление чисел Фибоначчи через рекурсию, вы потратите не только время на написание "ненужного кода", но еще и на разговор с интервьюером о том, почему рекурсия в такой задаче плохо, во всех языках ли она плоха и так далее. Плюсов никаких, а 10 минут просто исчезли.
Теперь перейдем к примеру из статьи:
fun calcSum(input: List<Int>): Int { // TODO: handle empty input ...Это LLM выдумала? Прекрасно эта функция будет работать и с пустым списком. Наоборот, такое TODO дает стойкое понимание интервьюеру о том, что вы не понимаете язык, на котором пишете. Просто немного неудачный пример, но зачем неудачный если есть миллионы удачных?
Про визуализацию без кода тоже надо учитывать, что возможно визуализировать процесс будет по времени дороже, чем написать код, пусть и с небольшими недочетами. Красиво рисовать дерево, переставлять значки, объяснять каждый шаг и не занервничать - это тоже скилл.
Одна строчка — одно действие
Вкусовщина. До крайности как в примере доходить не надо, но и использовать это как правило смысла нет. Те же небольшие LINQ конструкции они прямо просятся порою, чтобы их не дробили на несколько строк. if (x < 0 || y < 0) { x++; y++} тоже размазывать по нескольким строчкам затея, мягко говоря, на любителя. Если писать не в IDE а в блокноте, уйму времени потереяете на форматирование такого кода.
Интервью укладывается в 30 минут
То есть это либо одна задача на 30 минут, либо две по 15, либо "забудь обо всем, что мы сейчас говорили, и учи задачи наизусть!".
Из золотых правил остается неизменным только это по сути:
Пока не проведёте хотя бы 10 моков — не тратьте время на настоящие интервью.
Но так же и статью не напишешь. А вообще, уже какая там, пятая за месяц о литкод?
xoxol_89 Автор
14.01.2026 13:19Как же я соскучился по токсичности Хабра. Просто потрясающе.
Что ж, давайте я постараюсь ответить по пунктам.LLM
Вся статья собрана из моих постов в телеграм-канале. Можно посмотреть тут, тут, тут, тут, тут. Посты я пишу сам. Где в них LLM контент, простите?
Это про хакатоны, для тех кто не знает слова хакатон? Да, это формат возможного найма на работу, но точно не формат собеседования, или хотелось бы хотя бы один пример компании, которые так и собеседуют. Тестовое задание под это описание так себе подходит. Что имелось в виду?
Нет, это действительно есть формат собеседования. В 2021/2022 такие форматы я встречал как минимум в Bolt, Lyft (там вообще по сути интервью 3-4 были про построение одного проекта, просто с акцентом на разные вещи, типа здесь UI, там домен и тд.).
Обычно дается не более 15-30 минут на задачу, и если много временить тратить на "уточнение corner cases" и написание "наивного решения", то то решение, которое ожидалось увидеть вы просто не успеете написать.
Тут, наверное, стоит пояснить временной слот. На уточнение можно потратить пару минут, все уточняющие вопросы обычно очень типовые, и часть кейсов интервьюир подсвечивает еще при озвучивании задачи. По поводу brute-force решения. Очень часто, его достаточно просто проговорить и быстро показать. На это тоже должно уходить буквально пару минут.
Более оптимальное, чем наивное? Так для большинства easy задач оно тоже есть, более того, это вся суть задачи.
Думал, это очевидно, но, пожалуй, стоит подсветить. Конечно же, если задача легкая, и там по сути одно решение, то с него и нужно начинать. Создавать себе проблемы на ровном месте точно не стоит.
Это LLM выдумала? Прекрасно эта функция будет работать и с пустым списком. Наоборот, такое TODO дает стойкое понимание интервьюеру о том, что вы не понимаете язык, на котором пишете. Просто немного неудачный пример, но зачем неудачный если есть миллионы удачных?
Вы сейчас серьезно? Вы точно читали статью? Вполне нормально оставлять коментарии на потом. В данном случае я показываю, что есть edge case - пустой список (или отрицательное число, или еще что). Мы про этот кейс помним, и к нему вернемся попозже. Вы, конечно же, проговариваете это все.
Про визуализацию без кода тоже надо учитывать, что возможно визуализировать процесс будет по времени дороже, чем написать код, пусть и с небольшими недочетами. Красиво рисовать дерево, переставлять значки, объяснять каждый шаг и не занервничать - это тоже скилл.
А как вы будете объяснять свой алгоритм до имплементации? Сразу бросаться кодить - точно не поощряемое действие. Плюс объяснение алгоритма помогает и вам убедиться, что вы не упустили чего-то. Тут же достаточно объяснить хотя бы общий принцип, не нужно рисовать никакие супер красивые и длинные деревья.
Вкусовщина. До крайности как в примере доходить не надо, но и использовать это как правило смысла нет.
Не согласен. На интервью вам сильно проще будет дебажить ваш код.
А вообще, уже какая там, пятая за месяц о литкод?
Да ради бога, не читайте эти статьи, если они вам так надоели. Ко мне то какие вопросы? У меня есть реальный опыт, и я им поделился с теми, кому актуально это.
sic
14.01.2026 13:19Как же я соскучился по токсичности Хабра. Просто потрясающе.
Так выбирайте площадки, где за набросы большие пальцы и сердечки ставят. Были времена, когда люди публиковались на хабр преимущественно, чтобы получить советы и критику, а теперь даже уже не скрывают особо, что "нет подписоты, ну и идите своей дорогой".
Вся статья собрана из моих постов в телеграм-канале.
Ну так и нормально все было с постами в тг-канале. Кроме "Coding interview #5. Leetcode #3" где телеграм все пробелы съел в критически важных местах, поясняя как именно эта текстовая отладка выглядит, но кому до этого дело есть? А вот в структуру поста для хабра они не сами собой объединились. И от этого всего "нового" очень характерно веет.
Как соотносится более менее понятное:
В 2021/2022 такие форматы я встречал как минимум в Bolt, Lyft (там вообще по сути интервью 3-4 были про построение одного проекта, просто с акцентом на разные вещи, типа здесь UI, там домен и тд.).
С чистой воды абстракцией:
Реальный проект в IDE — самый хардкорный вариант. Нужно написать работающее решение, которое запустится. Обычно занимает от 90 минут. Хорошая новость: часто разрешают подготовить скелет проекта заранее.
Так можно и написать, разрешают в два этапа написать конкретный небольшой проект. Какие подготовки скелета проекта заранее? То есть вы еще конкретной задачи не знаете, но уже дома написали какие-то наброски кода? В ТГ вот прямо пишете "- Имплементация реального проекта в Android Studio и его запуск." - так вообще и вопросов нет.
я: Более оптимальное, чем наивное? Так для большинства easy задач оно тоже есть, более того, это вся суть задачи.
Вы: Думал, это очевидно, но, пожалуй, стоит подсветить.
Это не просто не очевидно, Вы же для новичков пишете, и даже закрепляете это концепцией "Уточняющие вопросы → brute force → обсуждение → имплементация с проговариванием → дебаггинг", которое вы называете Ритуал. Кстати в этой последовательности слов "оптимальное решение" я вообще не вижу. Зачем этот brute force, если вы уже знаете хорошее решение задачи? Или зачем вообще решать литкод, если любое решение можно сделать как brute force? Опять рисуем овал, а потом сову.
Вы сейчас серьезно? Вы точно читали статью? Вполне нормально оставлять коментарии на потом. В данном случае я показываю, что есть edge case - пустой список (или отрицательное число, или еще что)
Я очень даже серьезно. Тезис оставлять edge cases на потом - справедливый, но пример Ваш:
fun calcSum(input: List<Int>): Int { // TODO: handle empty input var sum = 0 for (elem in input) { sum += elem } return sum }Иллюстрирует то, что это строго бесполезно. Потому что, если вы знаете, как работает for in или foreach вы уже понимаете, что с пустым списком проблем не будет. Если вы не знаете, как работает то, что вы собираетесь использовать, то отчего не писать так:
fun calcSum(input: List<Int>): Int { // TODO: handle empty input // TODO: handle negative values // TODO: handle only one element // TODO: handle unsorted data var sum = 0 for (elem in input) { sum += elem } return sum }Все эти TODO имеют абсолютно равную силу здесь. Хотели бы придумать нормальный пример, он бы не заставил себя ждать.
fun calcIntAvg(input: List<Int>): Int { var sum = 0 var count = 0 for (elem in input) { sum += elem count += 1 } return sum / count // TODO: handle empty list }И это имело бы смысл. Причем именно так и пишут код в проектах. С какой-такой логики на собесах мы сначала обозначаем то что мы что-то недоделали, а потом только хоть что-то делаем вообще? Но вот я уже исправляю за Вас статью, а Вы говорите "токсичность".
А как вы будете объяснять свой алгоритм до имплементации? Сразу бросаться кодить - точно не поощряемое действие. Плюс объяснение алгоритма помогает и вам убедиться, что вы не упустили чего-то. Тут же достаточно объяснить хотя бы общий принцип, не нужно рисовать никакие супер красивые и длинные деревья.
Так не надо их рисовать, если вы знаете алгоритм, что dfs, что bfs это три буквы в рассказе об алгоритме. В каком порядке поддеревья обходятся это можно и словами в одном-двух предложениях описать, это если говорить об общих принципах. Опять же, нужен какой-то другой пример, где нарисовать просто, а объяснить сложно. Я таких примеров не знаю.
И вообще, про сам дебаггинг, если речь о собеседовании в IDE, то у вас есть все нормальные средства отладки, а если речь о работе в блокноте, то собеседующий, скорее всего, сам подскажет, где вы совершили небольшой недочет (на уровне синтаксиса или забытой операции), а в худшем случае, скажет "вы уверены, что алгоритм точно сработает?". В голове визуализация в любом случае будет работать быстрее, чем ascii-артом. Как способ "доказать" собеседующему, что вы не тупите, а хоть что-то делаете, текстовая визуализация может сработать, но надо ли это собеседующему? Это же не светский разговор, где бывают неловкие паузы.
Не согласен. На интервью вам сильно проще будет дебажить ваш код.
Когда у вас три примитивного типа переменных и одна коллекция на вход, а там обычно ничего дебажить и не надо. А иначе метод близок к неприменимости, если алгоритм дерево модифицирует, то в комментариях на каждый шаг будете каждый раз это дерево перерисовывать от вершины? Не на начальном этапе, когда вы просто поясняете, что алгоритм делать собирается, а когда у вас уже есть код, который вы хотите дебажить?
У меня есть реальный опыт, и я им поделился с теми, кому актуально это.
Так реальный опыт много у кого есть. Но если выводы из этого опыта значительно превышают самые общие (если угодно, базовые) вещи, и за ними не стоит какой-то теории или исследований, то это называется мнение.
xoxol_89 Автор
14.01.2026 13:19С чистой воды абстракцией
Причем тут это? У меня статья про Leetcode. Другие типы code interview освещены очень вскользь. Фокус не на этом, поэтому и придираться к этому не вижу никакого смысла.
То есть вы еще конкретной задачи не знаете, но уже дома написали какие-то наброски кода?
Да, там готовится структура типа MVVM, добавляются все библиотеки, может быть реализован супер базовый UI, сделана навигация, и даже прототипы юнит-тестов могут быть.
Реальный проект в IDE — самый хардкорный вариант.
Типа, если чуть по-другому названо, то уже сразу LLM? Сомнительно, конечно. Если честно, как андроид-разработчик большую часть жизни, я не вижу какой-то разницы в обеих формулировках. Возможно, для вас по-другому. Но опять-таки, статья про Leetcode.
Это не просто не очевидно, Вы же для новичков пишете
Тут для всех уровней. Пока что вы первый, кто за это зацепился. Нужно подумать, как лучше сформулировать тогда.
С какой-такой логики на собесах мы сначала обозначаем то что мы что-то недоделали, а потом только хоть что-то делаем вообще?
Мысль не в этом. Мысль в том, что сначала нужно фокусироваться на основном решении. Всякие edge cases, которые возникают по пути, их можно пометить комментами, мол потом рассмотрим, и идти дальше по решению. То есть вы расставляете эти комментарии по ходу имплементации, чтобы их не упустить, и чтобы не терять фокус.
Опять же, нужен какой-то другой пример, где нарисовать просто, а объяснить сложно.
Хорошо подходят практически все задачи с массивами. Где two pointer, greedy algorithm и тд. Может вы по easy задачам судите, где все довольно очевидно. Тут да, оно излишне. Но все что ближе к middle и выше, точно сильно облегчает жизнь что кандидату, что ревьюиру.
В голове визуализация в любом случае будет работать быстрее, чем ascii-артом.
Я думаю, что вы не пробовали просто. Я ровно так же рассуждал долгое время, пока не попробовал. В голове всегда хуже. Сколько багов я отлавливал вот таким вот письменным дебаггингом. Ну как бы неработающие советы я бы точно не приводил. Понятное дело, что если вы всегда все в голове делаете прекрасно, вам это не нужно. Но обычным людям помогает.
Но если выводы из этого опыта значительно превышают самые общие (если угодно, базовые) вещи, и за ними не стоит какой-то теории или исследований, то это называется мнение.
А какие тут базовые вещи превышаются, простите?
Но вот я уже исправляю за Вас статью, а Вы говорите "токсичность".
Громко сказано про исправление. Вы спрашиваете, что-то подсвечиваете, я вам отвечаю. Идет дискуссия. Но подача у вас действительно очень токсичная, она как минимум неприятная. Какие-то недостатки по вашему мнению всегда можно вполне уважительно к автору подсветить. Как никак любой автор проделывает определенную работу, выкладывает абсолютно бесплатно, чтобы помочь другим людям. За это можно хотя бы сказать спасибо. Вы же врываетесь с набросами, что тут везде LLM, что нужна "подписота" и тд. Желаю вам адекватных комментаторов к вашим статьям. Удачи.
killyself
14.01.2026 13:19Литкод easy - дело полезное, ради самого паттерна "а вот тут наверное можно ускорить если подумать". Задач 50 решить по вечерам - проект невеликий. Литкод mid не нужен, если оптимизация кода это не профиль позиции. Литкод hard имхо нужен 3.5 гениям, а мы не гении.
tkutru
14.01.2026 13:19Евгений, а теперь покажите нам где в работе новополученные знания с литкода вам пригодились.
ZlayaBelka1985
14.01.2026 13:19Конторы которые дают эту муть на интервью, заслуживают только чтобы кандидат юзал ИИ для решения этого бреда
vlad4kr7
14.01.2026 13:19Когда рынок не на дне, как последние пару лет, то набирают без леткода, и на зарплату влияют другие вещи. А когда на дне, то и литкод не поможет.
mitzury
На сколько хватит данных советов, когда впоследствии абсолютно все будут их прислушиваться. Все будут равны..
Советы базовые, я их использовал в Яндексе, так как это мой, можно сказать, родной стиль поведения. Но стресс - больное, сразу и руки не слушаются и языки заплетаются..
nex-54
Не будут все равны. Даже в США, где без литкода никуда, люди упираются и не хотят его решать, получая зп в несколько раз меньше.