Все знают о LeetCode — его можно любить, ненавидеть, презирать или даже бояться, но равнодушным точно не останется никто.
А для тех, кто все‑таки не знает, LeetCode — платформа для решения алгоритмических задач разной сложности и тематики, соревнований по скорости и производительности и просто общению с коммьюнити единомышл��нников по этой теме.
Эта статья - впечатления о моём 600-дневном марафоне на этой платформе, динамике моих скилов и ответе на главный вопрос “надо ли решать там задачи?”.
Как правило, по отношению к LeetCode люди делятся на два лагеря:
ценители и любители LeetCode и алгоритмов;
ненавистники LeetCode, которые считают его бесполезной тратой времени.
При этом длительное время я не принадлежал ни первому, ни второму лагерю, хотя иногда и проявлял интерес в сторону LeetCode, но руки так и не доходили. Страшно было даже притрагиваться к такой фундаментальной вещи, как алгоритмы. Но вот, в июльский вечер 2023 года я все-таки решился посмотреть пару задачек - на этих задачках и закончилось мое первое знакомство с платформой. Интерес был утолен, и на какое-то время я успокоился.
На этом мое знакомство с Leetcode закончилось и на некоторое время отстранился.
Все было спокойно, пока мы с другом не заключили спор - сможем ли мы решить 100 задач до конца 2023 года? А это было 50 задач всего за 1 месяц - декабрь.
На одном из моковых собеседований мы услышали, что для прохождения алгоритмического этапа может хватить решения 50 задач на Литкоде.
Челлендж в 100 задач оказался достаточно легким - Новый год мы встречали уже с круглым числом выполненных задач в профиле. Так быстро мы решили не останавливаться - Покоренная вершина стимулировала покорить новую - 200 задач к началу лета (за 5 месяцев).
В конце челленджа в 200 задач мой друг принял решение сойти с дистанции - переизбыток алгоритмов в крови, голове и остальных частях тела вызывал у него дискомфорт и галлюцинации, поэтому в его профиле красуется круглое «200», а я же к этому времени только “разогрелся” и вошел во вкус.
24 февраля 2024 в течении недели LeetCode предлагал неплохие и не очень сложные задачи на дейли челлендже, и у меня случайно получился стрик в районе 10 дней подряд.
Сбивать стрик было как-то жалко - это же целых 10 дней. Так и началась долгая история в 600 дней...
Впечатление
В итоге стрик продлился на 600+ дней и 700+ задач и продолжается на текущий момент: явный интерес был первые 100-200 дней, а далее началась рутина и тяжелая дисциплинированная работа - важно было установить личный рекорд.
Мой алгоритм в решении был весьма тривиален:
Если дейли решаемый - решаю дейли.
Если чувствую, что на дейли времени нужно больше, чем обычно - решаю любую попавшуюся под руку задачу.
Как правило, под руку попадались Easy/Medium задачи - этого хватало, чтобы размять свою голову с утра / перед сном.
Со временем я стал четче ощущать внутреннюю уверенность перед стартом решения задачи любой сложности - яркий признак того, что время потрачено не зря.
Теперь, видя огромную лесенку из 10+ вызовов std функций языка, больше нет страха, а есть четкая цепочка шаблонных действий.
А надо ли оно
Главный вопрос:
А надо ли оно? Для точного ответа на этот вопрос важно ответить на уточняющие:
Вы работаете с высоконагруженной системой?
Хотите ли вы попасть в бигтех?
Вас привлекают алгоритмы и приносят вам радость?
Если хотя бы на один вопрос вы ответили «да», то LeetCode - подходящий способ прокачать ваши алгоритмические скилы. Хотя бы на 100 задачек.
Какую пользу можно извлечь из такой авантюры?
Алгоритмическая сложность - ее можно будет увидеть даже невооруженным взглядом и сразу вычислять недостатки алгоритмов / методов и т.п. В продакшн коде это иногда может дать небольшой буст при некоторых сценариях, и ваши пользователи наверняка скажут вам спасибо.
-
Изучение языка - возможно, лучше способа для этого и не придумать. Человек - ленивое существо, и вам наверняка не захочется в очередной раз писать шаблонный код для тривиальной задачи, а воспользоваться готовой функцией. Для этого придется подробно ознакомится с std функциями вашего языка. Спустя какое-то время вы сможете писать их даже в блокноте без подсказок ide, что иногда требуют на некоторых собеседованиях.
Junior код:
fun countChars(s: String): Map<Char, Int> { val res = mutableMapOf<Char, Int>() for (c in s) { if (res.contains(c)) res[c] = res[c]!! + 1 else res[c] = 1 } return res }Senior код:
fun countChars(s: String): Map<Char, Int> = s.groupingBy { it }.eachCount() Паттерны - любой базовый алгоритм превратится для вас в набор шаблонных действий разной очередности. Со временем понимать чужие решения станет в разы проще.
Структуры данных - если это ваша слабая сторона, то LeetCode поможет исправить это: массивы, списки, хэш таблицы, деревья, графы и даже стэк с очередью будут ждать вас в решениях самых разных задач.
По началу придется смотреть чужие решение — по ним можно понять оптимальные пути решения проблем и увидеть шаблоны.
Возможно, кто‑то возразит о вышеперечисленных плюсах LeetCode. И скорее всего он даже будет в чем‑то прав, ведь универсального подхода к изучение алгоритмов нет: что‑то познается в практике, а что‑то в теории, а кому‑то они просто не нужны.
LeetCode — это просто один из удобных и порой интересных инструментов, где можно это освоить и «посоревноваться» с другими.
Почему не hard
Взглянув на статистику моего профиля, можно сразу увидеть одну немаловажную деталь - я вообще не решаю задачи уровня hard.
Плохо ли это? Опять же все зависит от ваших целей и возможностей.
Если ваша цель - подготовиться к собеседованию в Google или другие подобные компании, то это будет маст хев. Но для базового понимания алгоритмов и игры "в долгую" это явно будет лишним - заканчивая 8-часовой рабочий день, вы вряд ли захотите потратить еще пару часов на решение головоломки уровня hard для достижения эфемерной цели "узнать алгоритмы" Здесь больше подходит правило привычки, а не быстросгорающей мотивации, на которой далеко не уедешь.
Как правило, для решения hard задач, вам понадобится неплохая подготовка, пара часов свободного времени и крепкие нервы, потому что даже работающее решение вам могут забраковать по ограничению памяти или времени, поэтому стоит отталкиваться от вашей цели.
Решения
Из всех решений, что я видел за это время на LeetCode, я выделил следующие группы:
-
Максимально производительные и правильные решения.
Они основаны на паттернах или даже математике и дают "100% beats" в ваше решение: std функции языка не используются, а «изобретается велосипед», но весьма производительный.
Понять такое решение обычно может или только сам автор, или тот, кто и так решил задачу подобным же образом.
-
Элегантные и непроизводительные решения.
Обилие вызовов функций стандартной библиотеки языка; понятный и лаконичный код, который будет более дружелюбным для неподготовленного читателя.
Такой код не претендует на эффективность, но демонстрирует красоту языка и уровень его познания у написавшего.
Именно этот вариант для меня - максимально предпочтительный, ведь больше всего похож на продакшн код в большинстве проектов.
-
«Чтобы просто работало».
Немалая доля решений, которые сочетают в себе все что только можно - лишь бы работало. В них авторы редко задумываются о красоте или сложности той или иной вызываемой функции.
Таких решений достаточно много, особенно в непопулярных языках
Для примера - сравним подходы к решению одной и той же задачи из подборки Яндекса
Производительный вариант (~1ms):
fun canPlaceFlowers(flowerbed: IntArray, n: Int): Boolean {
if (n == 0) return true
var remaining = n
var i = 0
while (i < flowerbed.size) {
if (flowerbed[i] == 0) {
val prev = if (i == 0) 0 else flowerbed[i - 1]
val next = if (i == flowerbed.size - 1) 0 else flowerbed[i + 1]
if (prev == 0 && next == 0) {
flowerbed[i] = 0
remaining--
if (remaining == 0) return true
i++
}
}
i++
}
return remaining == 0
}Лаконичный вариант (~30ms):
fun canPlaceFlowers(flowerbed: IntArray, n: Int): Boolean = flowerbed
.withIndex()
.filter { it.value == 1 }
.map { it.index }
.let { listOf(-2) + it + (flowerbed.count()+1) }
.zipWithNext { i, j -> (j - i - 2) / 2 }
.sum() >= nКод выглядит абсолютно по-разному, хотя алгоритм практически идентичен.
Тут каждый сам выберет для себя лучшее решение, но разница между ними очевидна и будет видна даже человеку, который никогда не писал код и не понимает его:
Первое решение заметно выигрывает в скорости.
Для человека, который не знаком с языком, второе решение может быть сложным для понимания.
Их алгоритмическая сложность одинакова и равна
из-за полного обхода.Первое решение заметно выигрывает по потребляемой памяти (
vs 
), из-за отсутствия преобразований структур и работы с исходным массивом.
На самом деле, существует огромное множество алгоритмов, с помощью которых можно решить почти любую задачу на LeetCode, однако есть ряд самых популярных:
prefix sum
sliding window
hash table
dfs
binary search
two pointer
stack & queue
Останавливаться на них мы не будем, но если вы разберетесь в них, то большая часть задач LeetCode будет вам под силу.
С базовыми интерпретациями можно ознакомиться в прекрасной и легкой книжке - «Грокаем алгоритмы».
Систематичность
В чем же секрет? Да, на самом деле, ни в чем.
Простая систематичность и привычка - неважно, будний день, выходной или праздничный - вечером я сажусь и решаю задачу любой сложности, что мне по душе в тот момент.
Это может занять 2 минуты или 2 часа, но задача будет решена и квадратик заполнится зеленым цветом
Единственный минус при таком раскладе - достаточно часто это просто задача ради задачи: она не учит чему-то новому и уже не развивает какие-то скилы в алгоритмах или языке.
Как я и писал выше, где-то на 200+ день это просто превратилось в рутинную работу, которую я в том или ином виде делаю каждый день.
Если у вас есть конечная цель такого обучения, то скорее всего вы сможете вынести из решения задач больше пользы и видеть более явный прогресс.
Подводя итог моего 600-дневного путешествия, могу сказать, что базовые паттерны в разных их проявлениях становятся видны достаточно быстро, однако достаточно сложные вариации и комбинации нескольких иногда могут вызвать явные затруднения.
Для прохождения на базовые позиции разработчиков, скорее всего, этого будет достаточно, но выше могут быть трудности.
Собеседования
Цель решения этих задачек может быть разной:
изучение функций языка;
изучение алгоритмов;
небольшая разминка для мозга;
просто банальная состязательность в решениях между собой;
тренировка к прохождению собеседований в бигтех компании по типу Google, Yandex и подобных.
Последняя как раз и является самой популярной причиной.
Поможет ли вам в этом LeetCode? Скорее да, чем нет. Все зависит от подхода к решению задач.
Основная цель - понять какой-то паттерн решения и получить навык применять его в решении аналогичной задачи
Для такой тренировки отлично может подойти раздел курсов, где задачи сгруппированы по принципу их алгоритмов и поможет вам заметить между ними общие черты.
Иногда даже сами HR высылают список задач на тренировку к алгоритмической секции собеседования (Yandex).
Исходя из опыта коллег, для порога прохождения собеседований необходимо решить хотя бы 100 задач easy/medium сложности. При этом это не дает никаких гарантий и некоторым может понадобится в разы больше.
Из своего опыта могу сказать, что уверенность в себе начинает появляться примерно после 300+ задач.
Однако, не стоит быть слишком самоуверенным, ведь среди 3-х тысяч задач всегда найдется та, что сможет вдребезги опустить вашу самооценку
П.с. картинка взята из чужой статьи про литкод
Также ходят слухи, что некоторые HR могут хантить лучших LeetCode'еров, которые занимают призовые места на турнирах и ведущие места лидербордов.
Советы
И наконец от себя хотел бы дать ряд советов:
-
Определитесь с целью.
Правильная цель задаст нужный ритм вашей работе!
Возможно, оно вам просто не нужно. -
Начните с простого.
Мало кто сможет сходу решить большинство medium и hard задач.
Обращайте внимание наAcceptance Rateв задачах: чем выше процент, тем больше вероятность решить ее. -
Не стесняйтесь смотреть чужие решения.
В них часто можно найти что-то новое для себя: алгоритмы, удобные функции, радикально новые взгляды.
-
Экспериментируйте.
Большинство задач имеют несколько решений.
Не все из них будут оптимальными, но это все еще верные решения.
Лучшее - враг хорошего. -
Привычки сильнее мотивации.
Я бы никогда не дошел до такого количества решенных задач на одной лишь мотивации.
Ее, как правило, хватит не более, чем на месяц.
Делайте по одному небольшому шагу каждый день и через год вы удивитесь проделанному пути. -
Делитесь своими решениями.
Если вы пишете на популярном языке, то можете получить одобрение или ряд советов от единомышленников. Это поможет влиться в это сообщество и прокачать свои скиллы.
Итоги
В самом начале, перебарывая себя еще на этапе решения easy задач, я потратил колоссальное количество усилий и времени. И по итогам 600 дней с уверенностью утверждаю - все это было сделано не зря.
LeetCode - это отдельный мир, в котором свои правила игры и не так много соприкосновений с реальностью.
Но он точно даст вам понять, что такое алгоритмы и нужны ли они вам: для работы, собеседований, учебы или общего развития.
Комментарии (137)
stas_dubich
29.10.2025 09:21Выглядит как литкод ради литкода)
Есть конкретный пример из жизни ? Например раньше я делал задачи так, а теперь когда преисполнился делаю в 10 раз быстрее и работают они в 50 раз лучше
Просто хочется какого то осязаемого сравнения, что это дает на практике, а не вот эту воду про собесы в бигтех и разминку для мозга
Человеческий мозг это как уникальный процессор, который способен творить, но почему то из него пытаются сделать hdd, заучить функции языка, заучить алгоритмы которые с вероятностью 99% никогда не пригодятся и тд
qveex Автор
29.10.2025 09:21Выглядит как литкод ради литкода)
Именно так это и ощущалось!)
На самом деле, примеров не так уж и много
Для себя отметил такие вещи:
Стал обращать внимание на последовательность вызовов - если можно изменить их очередность и кол-во обрабатываемых данных сократиться.
Аналогично с алг. сложностью - чаще использовать set, map и иногда деревья (их редко). Т.е. мозг начал обращать внимание на вещи, которые большинство пропустит мимо.
Заметно подрос уровень владением языка - для чего раньше придумывался велосипед, сейчас я знаю как сделать функциями из коробки (группировки, окна и т.п.). Это может и просто с опытом прийти, но многим проще писать по старинке как привыкли, а тут будет небольшой толчок.
Как и писал в статье, очень это специфический инструмент обучения, но мне почему-то зашло (не во всех аспектах)
ImABug
29.10.2025 09:21Литкод просто инструмент. Площадка, которая способна что-то тебе дать, но не обязательно она тебе это даст) Все же зависит от человека. Для кого-то это литкод ради литкода, а кто-то увидев новое решение пойдет как минимум почитает о нем. Я первое время с интересом шерстил гугл когда встречал новые для себя вещи.
Я спустя 700 задач могу сказать, что по сравнению с 1,5-2 годами назад натыкаясь иногда на свои старые решения смотрю на них с улыбкой и понимаю сколько же в них лишнего, буквально натягивание совы на глобус по сравнению с тем как решаю сейчас. Стал использовать более подходящие структуры данных, стал почти моментально видеть хотя бы верхнюю границу big О того или иного кода, не говоря о том, что узнал кучу алгоритмов, которые на порядок бустят мои старые решения. Да и банально, это учит тебя постепенно смотреть на задачу под разным углом. На литкоде не мало задач, которые разумно решаются фактически только одним способом, но есть и те, где можно раскрутить и реализовать по-разному и все варианты хороши.
Ну и конечно начинаешь быстрее решать задачи, так как уже есть какой-то багаж в голове и более широкий кругозор, быстрее приходят некоторые варианты решения и сразу понимаешь их ±, где это будет быстро, а можно ли быстрее и как, и т.п.
itatarchenkoru
29.10.2025 09:21Искренне восхищен дисциплиной. Сам пытался в такой марафон, но сошел с дистанции уже на второй день. Понимаю какая сила воли нужна для такой системной работы. Думаю, что именно способность системно и дисциплинировано двигаться вперед и приводит к самым крутым результатам.
В реальной работе алгоритмы не так часто применяются, но тем не менее, как результат многократных упражнений в спортзале — прокачанная мышца, которая затем помогает развиваться профессионально.
Viacheslav01
29.10.2025 09:21Код выглядит абсолютно по-разному, хотя алгоритм практически идентичен.
А потом такое, для запуска нашего notepad вам необходимо 100500 гб винта, 100500 гб мозгов и камень в 32 ядра о 5 ггц.
qveex Автор
29.10.2025 09:21На самом деле, меня иногда сильно удивляет производительность работы "коробочных" функций
Даже использование базовых функций
map,sumOf,reduceи т.п. накладывает какой-то отпечаток на производительность. Несмотря на то, что алгоритм идентичен, "модное" решение практически всегда будет заметно проигрывать в скорости и памяти.Аналогично и со стримами java, насколько я знаю
По-хорошему надо покопаться в кишках реализации и выяснить в чем все-таки дело, но это уже совсем другая история)
alexandr93
29.10.2025 09:21О да, тоже решаю литкодж и пытаюсь как-то эксперементировать. Решение просто манипулировать массивом в джаве это 6 мс, но вместо массива взять стримы иииии 26 мс. В 4 раза дольше. Но самый прикол. Решение на джаве - 5 мс: https://leetcode.com/problems/maximum-number-of-distinct-elements-after-operations/submissions/1805361112/ Решение абсолютно такое же, но с векторами на С++ - 95 мс: https://leetcode.com/problems/maximum-number-of-distinct-elements-after-operations/submissions/1805360930/
qveex Автор
29.10.2025 09:21Тоже замечал такое
Иногда кажется, что литкод просто рандомное число выдает в этот результат
HiItsYuri
29.10.2025 09:21Вы отключаете синхронизацию ввода/вывода для C++ в своем решении?
alexandr93
29.10.2025 09:21Вот не знаю чего не открывается. Я только сам код решения адаптировал. Там по сути 2 решения. Одно за O(max val) и с соответствующим расходом памяти для диапазонов до 500 000. Другое - с сортировкой за O(N log N). Я думал, что в решении ща O(max val) самое сложное это выделение такого объёма памяти, но C++ по идее с этим должен был справиться не хуже джавы. Я так подозреваю, что дело таки в использовании вектора, но для C++ литкод всегда и предлагает использовать векторы.
Java
class Solution { public int maxDistinctElements(int[] nums, int k) { if (nums.length <= (k << 1) + 1) { return nums.length; } int result = 0; int minVal = Integer.MIN_VALUE; int max = 0; for (int num : nums) { max = Math.max(max, num); } if (max < 500_000) { return digSortSolution(nums, k, max); } return sortingSolution(nums, k); } private int digSortSolution(int[] nums, int k, int max) { int minVal = Integer.MIN_VALUE; int[] freqs = new int[max + 1]; int result = 0; for (int num : nums) { freqs[num] ++; } for (int i = 0; i < freqs.length; i ++) { int count = freqs[i]; if (count > 0) { int currentMinVal = Math.max(minVal, i - k); for (int j = 0; j < count && currentMinVal <= i + k; j ++, currentMinVal ++) { result ++; minVal = currentMinVal + 1; } } } return result; } private int sortingSolution(int[] nums, int k) { int result = 0; int minVal = Integer.MIN_VALUE; Arrays.sort(nums); for (int num : nums) { int currentMinVal = Math.max(minVal, num - k); if (currentMinVal <= num + k) { result ++; minVal = currentMinVal + 1; } } return result; } }C++
class Solution { public: int maxDistinctElements(vector<int>& nums, int k) { if (nums.size() <= static_cast<size_t>((k << 1) + 1)) { return nums.size(); } int max_val = 0; for (int num : nums) { max_val = max(max_val, num); } if (max_val < 500000) { return digSortSolution(nums, k, max_val); } return sortingSolution(nums, k); } private: int digSortSolution(vector<int>& nums, int k, int max_val) { vector<int> freqs(max_val + 1, 0); int minVal = INT_MIN; int result = 0; for (int num : nums) { freqs[num]++; } for (int i = 0; i < static_cast<int>(freqs.size()); i++) { int count = freqs[i]; if (count > 0) { int currentMinVal = max(minVal, i - k); for (int j = 0; j < count && currentMinVal <= i + k; j++, currentMinVal++) { result++; minVal = currentMinVal + 1; } } } return result; } int sortingSolution(vector<int>& nums, int k) { int minVal = INT_MIN; int result = 0; sort(nums.begin(), nums.end()); for (int num : nums) { int currentMinVal = max(minVal, num - k); if (currentMinVal <= num + k) { result++; minVal = currentMinVal + 1; } } return result; } };HiItsYuri
29.10.2025 09:21Я не был залогинен, потому и не открывалось.
У меня больше подозрения на то, что нужно отключать синхронизацию ввода вывода:
https://stackoverflow.com/questions/48367983/why-does-sync-with-stdiofalse-speed-up-the-code
Алсо есть в голове идея, что можно решить и без выделения доп вектора, но обязательно с сортировкой. Но руки не дошли попробовать написать решение.
warkid
29.10.2025 09:21Решение абсолютно такое-же. Но, полагаю, значимое отличие это сортировка. Которая под капотом реализована силно по-разному в Java и С++. Алгоритмы разные и возможно тестовые данные для джавовского удобнее.
malkovsky
29.10.2025 09:21А литкод убрал убрал дисперсию в замерах? Если нет, то на время работы особого смысла нет смотреть. Раньше точно было такое, что посылка одного и того же решения могла дать "beats 100%", а могла и "beats 30%"
domix32
29.10.2025 09:21Там для разных языков есть заметный разброс на накладные расходы - на время исполнения, на потребление памяти. Непонятно с чем связана, но два идентичных сабмишна на Rust будут выполняться с практически милисекундной точностью и относительно стабильно съедать примерно 2мб+сколько сами навыделяете сверху. В С++ сабмит даёт разброс по времени едва ли не в полсекунды иногда и разброс по памяти 5-10мб + выделенная вами память, хотя если запускать тот же код локально с некоторой минимальной обвязкаой, то память едва-едва будет больше килобайта помимо того, что выделил непосредственно ваш алгоритм. Отдельно встречал приколы, когда отправлял очень старые решения повторно и те показывали втрое худшие цифры как по скорости, так и по памяти. Видимо там есть какие-то накладные расходы на песочницы, поэтому замеры скорости у программ на leetcode полезны только ранжирования решений на leetcode. Аналогичные истории с другими языками.
А вообще подозрительно, что код на С++ при прочих равных сожрал на 30 метров памяти больше.
Artem_Omny
29.10.2025 09:21И notepad этот обязательно от самых пресамых, у кого уже hard задачи на собеседованиях
green_fenix
29.10.2025 09:21Ну а как, в блокноте же теперь копайлот есть. Жизненно необходимая фича.
Warperus
29.10.2025 09:21Копайлоту всё равно из какого утюга вещать, тем более есть люди, которые в блокноте пишут тексты и кодами балуются.
AlexeyK77
29.10.2025 09:21fun minimumPushes(word: String) = word .groupingBy { it } .eachCount() .values .sortedDescending() .chunked(8) .foldIndexed(0) { i, acc, counts -> acc + counts.sum() * (i + 1) }Скажите, а вот это вот,что сейчас стало признаком крутизны, как его дебажить и ускорять.
Раньше били по рукам за гото и чрезмерное увлечение сырыми указателями, а тепреь вот новая напасть.
domix32
29.10.2025 09:21как его дебажить
ну, кажется очевидным поставить бряк в нужный этап. Ну, а с ускорением тут не сказать чтобы много вариантов - либо смотреть на производительность алгоритмов (например, поменять сортировку на нестабильную), либо на выделения памяти в куче (как у автора listOf), либо на размер передаваемого контекста, но последнее это уже этап микробенчмаркинга.
Artem_Omny
29.10.2025 09:21Код читается довольно легко с таким подходом. Не зная язык программирования, я просто прочел и просто понял почти всё, что там делается
AlexeyK77
29.10.2025 09:21фрагмент скопировал из этой же статьи, и который оказался в 30раз медленее обычного прямого подхода. (правда смотрю. что автор уже подправил листинг в статье, но это не принципиально).
Warperus
29.10.2025 09:21Так сильно медленней он не потому, что в обвязке, а потому что алгоритм другой.
Первым шагом вместо сортировки подсчётом (мутный reduce) делается группировка списка, а уже вторым подсчёт.
И будет несильно медленней.
MechanicZelenyy
29.10.2025 09:21как его дебажить
Извините за пассивно агрессивный тон, но дебажить это надо деббагером.
Мне лень прикреплять картинку, но IDE спокойно ставит брики внутри лямбд и спокойно проваливается внутрь функцийускорять
1) По ситуации. Заменять библиотечные функции, своими если вас не устраивает их скорость, использовать sequence там где просто mapReduce обработка, добавить подсказки компилятору
tenzink
29.10.2025 09:21Да и дебажить именно этот метод нет вообще никакой необходимости. Он "чистый", идеально покрывается тестами и очень понятен.
Kanut
29.10.2025 09:21Ну ошибиться там тоже можно. И если результат не совпадает с ожиданиями, то дебажить вполне себе вариант.
Другое дело что не особо понимаю в чём должна быть проблема. Любая более-менее адекватная IDE имеет что-нибудь вроде "watches" или "live console". Поставил брейкпоинт в начале выражения и можно "вручную" выполнить любой из этапов с просмотром результата...
atd
29.10.2025 09:21А как "highload" связан с языком программирования, простите?
AndreyDmitriev
29.10.2025 09:21Тут видимо имеется ввиду. что С# - это управляемый код, так что у нас есть дополнительная прослойка в виде IL/JIT, соответственно получить производительность, сравнимую с тем же Си или Растом бывает чуть сложнее. Писать высокопроизводительный код на нативном Питоне (ну то есть без библиотек) - примерно тоже самое, только ещё хуже. Вообще если упираться в максимально эффективный машинный код, то тут ещё и компилятор влияет, ингода перекомпиляция Си кода интеловским компилятором может дать хороший буст. Ну и при анализе узких мест желательно заглядывать именно в машинный код, на уровне ассемблера, и С# тут не сильно помогает. Бывает проще расчехлить Си, аккуратно выписать и отпрофилировать самую нагруженную часть там, а затем уже подключать к С# или Питону в виде библиотеки.
atd
29.10.2025 09:21Так "highload" же не связан с оптимальным машинным кодом. Есть много примеров хайлоада, написанных вообще на пхп, нагрузка никак не зависит от того, насколько быстро оно будет шевелиться.
AndreyDmitriev
29.10.2025 09:21Может я тогда сакральный смысл "highload" не очень понимаю. Просто захожу вот сюда - highload.fun/tasks, вижу список заданий. Соревнование идёт именно за время выполнения кода, там везде "...for the shortest time". Практически везде С++ с хорошим отрывом от С#, и мне понятно почему. В первом же примере С++ 2,911, а С# 14,506 - это пятикратная разница. Вот медиана ещё показательнее - тут вообще в 60 раз, медиану на чистом шарпе оптимально найти непросто. Кстати, Раст почти вровень с С++, это то что я и на практике наблюдаю. Я это к тому, что можно соревноваться в классе С++ или С#, но сравнивать их нельзя. Это примерно как есть Формула 1, а есть ралли "Дакар" - просто разные вещи, разные "весовые категории", что ли. Но писать оптимальный код именно на используемом языке надо уметь, конечно, и такие упражнения помогают, да.
MountainGoat
29.10.2025 09:21Этот язык я не знаю, но в Rust IDE после каждой строчки напишет, что именно за типы получаются на выходе. А в Python можно бряк с условием поставить, типа "останови на восьмой итерации или когда х % 2 == 0"
Так что применяйте современные инструментарии и всё будет.
iamkisly
29.10.2025 09:21Я вот ни бельмеса в Kotlin, но это буквально почти как dotnet linq, и читается не хуже
Zara6502
29.10.2025 09:21тут же на хабре узнал о проекте highload.fun (можете считать за рекламу). а вот leetcode мне сильно не понравился, неудобен, постоянная борьба с интерфейсом.
WASD1
29.10.2025 09:21Ну это же просто наблюдение Гудхарта (все "законы" Мёрфи - это наблюдения за функционированием бюрократических \ социальных систем в реальности) в действии.
Раньше "умение решать алгоритмы" хорошо коррелировало с сообразительностью и способностью разобраться в других сферах.
Сейчас "умение решать алгоритмы" (ну за исключением hard - но там уже даже при наличии олимпиадного бэкграунда не 2 вечера вспоминать) - коррелирует с потраченным на leetcode временем.
SWATOPLUS
29.10.2025 09:21Как правило, по отношению к LeetCode люди делятся на два лагеря:
ценители и любители LeetCode и алгоритмов;
ненавистники LeetCode, которые считают его бесполезной тратой времени.
Приглашаю в свой третий лагерь:
LeetCode - это слишком легко, решайте серьезные задачи на https://eolymp.com/ru/problems или https://codeforces.com/problemset?locale=ru
UFO_01
29.10.2025 09:21Зашёл на codeforces, и как будто попал в школьные времена, когда к ЕГЭ и олимпиадам готовился, странно что я тогда про него не слышал. Возьму на заметку, спасибо. Жаль что для eolymp айпишником не вышел :(
Femistoklov
29.10.2025 09:21Тогда уж вот эти: https://ru.wikipedia.org/wiki/Категория:Нерешённые_проблемы
PS: и я не шучу.
RikkiMongoose
29.10.2025 09:21В заголовке написано "что из этого вышло".
В тексте нет ни слова о том, что же из этого вышло.
Как решал задачи, так и решает.
День за днем. Месяц за месяцем.
"потратил колоссальное количество усилий и времени."
У вас жизнь бесконечная, усилия ничего не стоят. Решайте Литкод.
vadimr
29.10.2025 09:21Само по себе решение задач по фану - вполне достойное времяпрепровождение, но вряд ли большое количество решений уровня Easy поднимет ваш уровень программирования. В любом деле для прогресса обучения надо повышать сложность. Программирование тут не является исключением, реальные задачи обычно требуют продолжительной работы. Они могут быть и не сложными алгоритмически, но требующими многодневной концентрации внимания.
А как хобби - почему бы и нет.
Sequoza
29.10.2025 09:21Адепты литкода подскажите пожалуйста, когда вы решаете - вы сначала перечитываете всю теорию и уже потом приступаете или сначала сталкиваетесь с проблемой и уже потом заполняете пробелы?
alexandr93
29.10.2025 09:21По-разному. По большей части вопросы по математике ставят в тупик и нужно что-то повторять. Но при этом задачи как будто похожи друг на друга. То есть всё вертится вокруг формулы сочетаний и способов посчитать их. Например, все сочетания до 50 50 можно считать треугольником Паскаля, но иногда есть приколы, что нужна малая теорема Ферма, когда нужно посчитать сочетания для очень больших значений по модулю. Но недавно в дэйли задачах была задача, где модуль - составное число и тут даже малая теорема Ферма не поможет) Не люблю математику в общем)
qveex Автор
29.10.2025 09:21Больше зависит от человека, который решает
Если говорить про "правильный" способ, то конечно надо знать основные моменты всех базовых алгоритмов, чтобы при решении понимать в какую сторону копать
Но на практике, конечно, знать все невозможно, поэтому часто приходится разбирать алгоритм в процессе решения конкретной задачи
tommyangelo27
29.10.2025 09:21Помню начал решать, понял, что у меня пробелы в базовых знаниях, и от этого процесс решения неэффективен. Отставил литкод и пошёл проходить курсы, благо материалов в интернете - вагон и маленькая тележка.
После прокачки теории вернулся к задачам, стало гораздо лучше.qveex Автор
29.10.2025 09:21Вполне логичный подход
Так и надо делать кмк
Многим просто хочется в моменте утвердить свои скиллы, поэтому останавливаются чисто на практике, хотя это малоэффективный подход
domix32
29.10.2025 09:21Большинство задач просто брутфорсом пробовал, потом оптимизировал по необходимости алгоритм, какие-то задачи разбирают на ютубе. Например, neetcode имеет много разборов дейликов на питоне. Какие-то задачи поясняют в обсуждениях но там как повезёт - иногда есть годные разборы, иногда фигня типа "ставь лайк, подписка, вот тебе скриншот решения вензельным шрифтом". Для большинства задач имеется достаточно явная чуйка о необходимых подходах, что позволяет брутфорсить оптимальные решения сходу.
0x131315
29.10.2025 09:21Человеку для хорошего настроения нужны регулярные победы. Пусть они будут маленькими, но победы. Обычно их и так хватает в жизни и работе, но иногда может быть недостаток. Решение легких задачек может быть неплохим источников таких маленьких доступных и регулярных побед.
wmlab
29.10.2025 09:21Я учился по книжке "Задачи по программированию". За давностью лет не помню автора. 80-е годы, перевод. Задачи были типа "Вот упрощенный вариант Монополии (для N игроков) - правила. Напишите код. Слишком легко? Предложите и напишите оптимальную стратегию игры со стороны компьютера". А на первом курсе нам показали пошаговую игру "Посадка на Луну" (на текстовом терминале) - предложили свой вариант написать. Мне это показалось легким и я стал решать задачу оптимальной посадки в общем виде. Быстро пришел к выводу необходимости тренировок и расставлением полученной телеметрии в многомерном пространстве высота-скорость-масса-топливо-тяга. С интерполяцией между исследованными точками. А вот до обученной нейросетки не додумался, это да :)
bak
29.10.2025 09:21Решать 600 легких задач никакого смысла нет. Чтобы рос навык - надо постепенно усложнять уровень задач. Это все равно что ходить в качалку и каждый день жать один и тот же вес одинаковое число повторов.
qveex Автор
29.10.2025 09:21Абсолютно согласен
Последнее время стараюсь больше внимания уделять medium задачам
Но вообще, как и написал в статье, т.к. цели решать любой алгоритм у меня нет, то и стремления повышать уровень тоже не хватает
Вероятно, после нового года перестану заниматься этим, т.к., как отметили комментаторы выше, смысла в этом мало.
На Easy и Medium чувствую себя +- комфортно, но на Hard уже нужно реально тратить время, а не под чаек посидеть
Sau
29.10.2025 09:21Вы всё равно упрётесь в максимальный вес и одинаковое число повторов, просто оно будет больше.
bak
29.10.2025 09:21С таким настроем можно вообще ничем не заниматься, зачем менять работу "вы все равно упретесь в потолок по ЗП просто он будет больше", зачем покупать новую квартиру "все равно упретесь в максимальную жилплощадь, просто она будет больше".
Sau
29.10.2025 09:21Заниматься физкультурой может быть нужно для профилактики гиподинамии, например. Возможно, решение простых задачек тоже профилактирует чего-нибудь при неизменном уровне. И наращивать сложность совершенно необязательно.
tommyangelo27
29.10.2025 09:21Это все равно что ходить в качалку и каждый день жать один и тот же вес одинаковое число повторов
А что плохого? Если устраивает объем мышц и сила
dovg
29.10.2025 09:21>Это все равно что ходить в качалку и каждый день жать один и тот же вес одинаковое число повторов.
так это норм же, не? Я несколько лет уже делаю "одинаковое число повторов с одинаковыми весами" и бегаю "одинаковые дистанции в одинаковом темпе с одинаковым пульсом"
Это же гигиена, чищу зубы я тоже одинаково.
Если у тебя цель "чтобы навык не падал" (aka "бегаю, чтобы не жиреть"), то подход автора вполне ок, разве нет?
Kovurr
29.10.2025 09:21Если бы литкод был просто сайтом для добровольной тренировки навыков, это одно. Но когда из него сделали мерило "берем на работу или нет", это лис полярный. И вызывает только злость, потому что не хочется тратить кусок жизни на это.
bak
29.10.2025 09:21То что в полицию не берут людей не сдающих нормативы - это ок, а то что разработчиков не знающих алгоритмы - не ок?
Представляю нытьё полицейских:
- "В реальной работе я не занимаюсь отжиманиями и подтягиваниями!"
- "Я и с пузом нормально арестовываю!"
- "Мы давно на машинах за преступниками бегаем - кому этот бег нужен!"
- "А мы просто за жизнь спрашиваем - если человек может рассказать кого как арестовывал над какими делами работал - берем!"domix32
29.10.2025 09:21Для крупных кампаний такой фильтр относительно оправдан. Ошибки полицейского не влияют на большое количество людей, в отличии от ошибок серийного программиста Джона.
i86com
29.10.2025 09:21Нормативы физподготовки может без труда сдать примерно каждый второй здоровый человек. Конкретную сложную алгоритмическую задачу с литкода - едва ли один на 10к - если вот недавно именно её читал и ещё не успел забыть за ненадобностью.
bak
29.10.2025 09:21Если бы на работу в полицию стояла такая же очередь как и на работу в условный google - нормативы были бы куда выше. Тут скорее по требованиям надо сравнивать с отрядом элитного спецназа. (хотя сейчас и там скорее недобор желающих нежели какой-то конкурс)
PS. Когда ты обычный разраб и решил пройти собес в гугл
jakobz
29.10.2025 09:21Как-то на каком-то похожем сайте решал задачки давно.
И там была задачка - дано сколько-то «рук» в покере - надо посчитать когда левая бьет правую комбинацию.
И мне она так понравилась, что я её давал как тестовую потом.
Прикол в том, что это не сложная какая-то муть про o(n), это максимально близко к тому, что приходится писать в бизнес-приложениях: куча странных условий друг на друге. И написать это красиво и понятно - надо прям уметь.
Такие задачки на leetcode попадаются?
navferty
29.10.2025 09:21А опишите пожалуйста коротко задачу, с примером. Может быть, тоже возьму на вооружение такое тестовое.
jakobz
29.10.2025 09:21Вот она: https://projecteuler.net/problem=54
domix32
29.10.2025 09:21На hard и medium иногда встречаются задачи подобной сложности. Иногда читаешь задачу - звучит просто. А потом добавляется какой-нибудь дополнительный финт к базовой струтуре и начинается веселье.
talebin
29.10.2025 09:21Прочитал вашу задачку - вроде интересная, но думаю, можно подобрать задачку получше. Позвольте пояснить (вдруг кому опыт пригодится)...
Дело в том, что "работать при зрителях" - это одна из самых стрессовых ситуаций в профессии. Даже если человек способен выдать решение или знает то, что мне нужно, далеко не факт, что я эту информацию смогу из него достать. Примерно у половины разработчиков тип личности такой, что при зрителях они буквально входят в ступор. Уж не знаю, как правильно этот эффект называют психологи - "социальная ингибиция" или просто "паническая атака", но факт в том, что нужен буквально "высший пилотаж", чтобы подобного человека раскрепостить. В рамках собеседования, скорее всего, просто не успеешь.
Поэтому со временем я ввел некоторые правила, которые помогают искать подходящие задачи. Одно из них звучит так:
Запрещено использовать текст задачи, в котором встречаются такие выражения, которые человек не мог вчера услышать "в IT-быту". То есть, запрещены: анаграмма, палиндром, сходящийся ряд, фулл-хаус, ход конем, интеграл, римские цифры, дискретность, инвариант, простые числа и так далее. Вы поняли идею...
Это не значит, что нужно запрещать все техническое. В активном словаре айтишника достаточно материала, чтобы работать. Например, следующие слова совершенно не вызывают проблем в тексте и нейтральны для состояния "пациента": стек, односвязный список, сортировка, массив, пара, вектор, равенство и т. д.
Я не имею в виду, что человек, скорее всего, "сложного" не знает - наоборот, скорее всего, все он знает. Но когда мы только знакомимся и занимаемся такой хрупкой работой, как оценка его аналитических способностей, способности к структурному мышлению, каждое лишнее слово может быть фатально. И мы просто не узнаем за отведенное время, кем же он был на самом деле.
PS: Кстати, если на какую-то позицию допустимо проводить собеседование без задач - лучше так и сделать. Вряд ли кто-то из нас заканчивал "пед". Мы с трудом понимаем, как именно это нужно делать, чтобы не навредить ни себе, ни испытуемому.
jakobz
29.10.2025 09:21Конкретно эту я давал офлайн решать, ребятам из учебки - там это было уместно.
Для онлайн "при зрителях" - она прям слишком сложная. У меня для собесов задачи прям супер-простые, в т.ч. чтобы не парализовало. Уровня дописать полу-готовый ToDo List на React, или вынуть суммы из трех связанных таблиц на .NET.
Но задачи все - с кучей точек где что-то дописать, спросить, обсудить.talebin
29.10.2025 09:21Понял вас, спасибо за пояснение. Тогда мой комментарий нерелевантен.
Но пусть будет, раз уж я его накатал, может кому мысль пригодится.
axion-1
29.10.2025 09:21На самом Эйлере ещё несколько похожих было, правда сходу не найду. Они может и ближе к практике, но решать такое в свободное время - очень на любителя имхо. Больше про гриндинг, чем про нахождение красивого и эффективного решения.
yadobr
29.10.2025 09:21Не знаком с leetcode, подскажите, в чем отличия от codewars?
qveex Автор
29.10.2025 09:21Суть одинаковая, но codewars имеет больше уровней сложности, из-за чего можно более точно под себя подобрать.
Плюс слышал, что тесты там сложнее пройти и они мене щадящие
Сам давно туда не заходил, Литкод просто показался больше юзер френдли, поэтому остановился на нем
domix32
29.10.2025 09:21leetcode и hackerrank просто считаются "более профессиональным" т.к. позволяют получить некоторую сертификацию за отдельную плату. А так площадок подобного рода уже немало. Та же code kata, например.
sunnybear
29.10.2025 09:21Если 600 дней тратить по 2 часа, можно неплохой дом построить. Или на квартиру накопить.
DarthVictor
29.10.2025 09:21Если 600 дней тратить по 2 часа, можно неплохой дом построить. Или на квартиру накопить.
1200 часов — это семь с половиной месяцев. При средней зарплате, показываемый сейчас Хабром для мидл-разработчика квартирку придётся брать где-нибудь в Воркуте.
Panzerschrek
29.10.2025 09:21За последние 14 месяцев решил более 1300 задач, из них чуть больше 200 сложных. При этом замечаю, что я достиг некого потолка - многие сложные задачи всё равно не даются, ибо предполагают знания какого-то специфического неочевидного подхода, который фиг найдёшь, опыт решения других задач в этом не помогает.
Ещё есть некоторые задачи, которые так уродски составлены, что могут быть решены в требуемых временных рамках только одним конкретным подходом. При этом могут быть и альтернативные подходы, на тесты составлены так, чтобы эти альтернативные подходы не укладывались в данное время. И я тут имею в виду не очевидные случаи с линейными/квадратичными алгоритмами, а нечто более хитрое, вроде оптимизаций, которые в некоторых случаях не срабатывают или просто алгоритмы с другой константой перед показателем временной сложности.
Сложность задач (easy/medium/hard) весьма тролльская. Некоторые easy задачи всё-же требуют написание немалой портянки кода для решения. Половина medium задач вполне себе тяжёлые и или не поддаются вовсе, или требуют от часа времени мозговых усилий.
Ежедневные задачи - вдвойне троллинг. Там или что-то очень лёгкое, или же наоборот - практически нерешаемые задачи. Зачем редакторы ставят такие задачи ежедневными - неясно, разве что чтобы аудиторию разозлить.
urvanov
29.10.2025 09:21В итоге помогло-то хоть? Зарплату там повысить, работу получше найти. 1300 задач — это так-то довольно много времени. Можно было пет-проект для души за это время создать.
Panzerschrek
29.10.2025 09:21Это интересный вопрос, в какой мере это мне помогло. Что-то я конечно из этого вынес, но я не проверял (не было алгоритмических собеседований). Ну а хобби-проект у меня и так есть, даже не один.
Keeper22
29.10.2025 09:21не было алгоритмических собеседований
Отрицательный результат -- тоже результат.
urvanov
29.10.2025 09:21А тамошних монеток-то хоть нафармил сколько-нибудь? Ачивки все закрыл?
qveex Автор
29.10.2025 09:21Конечно
Не сказать, что много, сейчас в районе 5т монеток
Ачивки в основном за дни активности дают
За дейлики так и не удалось получить: откровенно не хотелось копировать чужие решения, а чаще всего каждый месяц в дейли попадается такая задача, которую хрен решишь самостоятельно
Dywar
29.10.2025 09:21Тоже иногда решаю литкод.
Мне нравится ощущение когда ты решил задачу, накатывают позитивные эмоции :)
Есть ли польза? Я думаю что есть, иногда на работе нужно написать алгоритм сортировки с несколькими условиями или обойти дерево. Их решение уже не вызывает трудностей как раньше.
Сейчас есть ИИ, много бесплатных, которые напишут тебе нужный алгоритм, и тесты к нему, это будет быстрее чем делать самому. Надо ли самому что то делать или уже нет, каждый сам решит. Я продолжу решать сам для себя, не так часто как раньше конечно, но думаю что это полезно, и когда мне будет лень, то передам это ИИ.
vasiliy_moscow
29.10.2025 09:21Дофаминовая зависимость или как правильно называется то о чем пишет автор статьи? Напишите кто разбирается.
Kahelman
29.10.2025 09:21funcanPlaceFlowers(flowerbed:IntArray, n:Int):Boolean{if(n == 0)returntruevarremaining = nvari = 0while(i < flowerbed.size) {if(flowerbed[i] == 0) {valprev =if(i == 0) 0elseflowerbed[i - 1]valnext =if(i == flowerbed.size - 1) 0elseflowerbed[i + 1]if(prev == 0 && next == 0) { flowerbed[i] = 0 remaining--if(remaining == 0)returntrue i++ } } i++ }returnremaining == 0}
Вы только что показали. Почему ваш восход ни к чему не приводит. В вашем, так называемом «высокоскоростном» решении, нет ничего высокоскоростного и оптимизированного. Так нормальные люди писали код пока не набежали фанаты цепных вызовов и не стали говорить что это круче.
У вас идёт проверка условий и доступ к массиву для prev и next, которые не нужны и могут быть оптимизированны
qveex Автор
29.10.2025 09:21Код без цепочки вызовов - не мой
Взят самый популярный пример в разделе Kotlin. Это просто пример и не претендует на максимальную производительность. Это решение такого же обычного человека
Цепные вызовы и правда стабильно хуже в производительности, но позволяет меня задумываться о деталях, а отдаваться реализации конкретной функции
Плюс такие функции являются чистыми, что дает больше уверенности и претендует на тестируемость
Все зависит от вашей цели. Если нужна производительность - придется писать обычный код
Kahelman
29.10.2025 09:21Претензия не е коду, а к вам. Вы привели его как пример высокоскоростного решения. Как пример «нормально решения» он подойдёт, но говорить о том что это оптимизированный код нельзя. Это просто «тупой» код для решения задачи как он должен быть. Тупо, понятно, легко транслируется на любой язык.
Source
29.10.2025 09:21Цепные вызовы и правда стабильно хуже в производительности
А в Kotlin разве нет lazy-evaluation? Обычно это позволяет писать код обработки массивов в виде цепочки вызовов, а в итоге выполнять все эти действия за 1 проход.
qveex Автор
29.10.2025 09:21Есть похожий механизм - Sequence
В некоторых кейсах он может дать буст, но это вообще не панацея
Зависит от цепочки вызовов сильно, поэтому достаточно специфичный инструмент и особо не ориентировался бы на него
andrsam
29.10.2025 09:21Проходил курс Grokking на educative.io. Принцип построения материалов неплохой - сначала демонстрируется примерное решение на основе псевдокода, затем ты пытаешься его выполнить, далее сверяешься с ответом. На практике, большую часть заданий приходится решать через воспроизведение кода из ответов по памяти. Это страшно демотивирует. Как научиться решать задачи самому без зубрёжки?
jirdis
29.10.2025 09:21Не уважаю казуалов, уважаю только hard, только жесть. Грудью на танк! С ноги в толпу!
DaggerMouse
29.10.2025 09:21Были времена, когда я был моложе и готов был биться за идею о том, что задачки бесполезны и все кто ими увлекаются, в итоге теряют чужое время, задавая их на собеседованиях и что-то по ним измеряя.
С тех пор я поменялся, вырос над собой, стал сильнее
Биться за идею стало проще
Femistoklov
29.10.2025 09:21Дополнил:
А надо ли оно? Для точного ответа на этот вопрос важно ответить на уточняющие:
Вы работаете с высоконагруженной системой?
Хотите ли вы попасть в бигтех?
Вас привлекают алгоритмы и приносят вам радость?
У вас нет профильного высшего образования?
Вы не участвовали в олимпиадах по информатике?
alkneu
29.10.2025 09:21
ez katka
qveex Автор
29.10.2025 09:21Больной человек!) В хорошем смысле)
Я довольно часто натыкаюсь на дейли, которые не могу решить
Из-за этого так ни одной медальки за месяц и не получил
Ваша выдержка и скилл алгоритмов явно на несколько уровней выше
T-D-K
29.10.2025 09:21
=)
alexandr93
29.10.2025 09:21Записную книжку с Big O заказали?)
T-D-K
29.10.2025 09:21Не увидел для себя смысла в нёй. Я взял набор "t-shirt, keychain and coaster". Подставкой под кружку пользуюсь каждый день на работе. Вообще ради неё и брал набор.
Ещё осталось чуть больше 12К коинов. Пока не придумал куда их деть.
axion-1
29.10.2025 09:21Ориентироваться на количество имхо непродуктивно, т.к. мотивирует щёлкать множество лёгких однотипных задач. Сложные задачи могут стоить десятков если не сотен "пятиминуток", и по пользе и по затраченному времени.
В плане прокачки скиллов, может лучше было бы ставить целью, например по 10 лёгких задач из каждого подраздела, затем по 10 средних и сложных.
alexandr93
29.10.2025 09:21Там сложность непонятно как оценивается. Есть задачи на easy, которые не самые простые. А есть задачи hard, которые в одну строчку-формулу решаются.
urvanov
29.10.2025 09:21А в Ежедневных заданиях вообще сложность скачет. Специально, чтобы спринт сломать человеку
agoncharov
29.10.2025 09:21Не будете вы ни в каком бигтехе решать хоть что-то отдалённо похожее на задачи с литкода. А то что там на собеседованиях такое спрашивают - это другой вопрос, но в любом случае это их проблемы
Merkan
29.10.2025 09:21Решая задания на Литкод и ему подобных сайтах, вы научитесь решать задания на Литкод и ему подобных сайтах.
Anfet
29.10.2025 09:21Все бомбически, вот только откуда столько свободного времени? Имея основную работу + подработку, выходит по 10-12 часов занятости. Какой литкод, ррработать.
qveex Автор
29.10.2025 09:21На easy/medium задачи уходит не так много времени, как может показаться (до часа максимум, а иной раз можно и за минуту решить, если совсем легкая)
Это как раз мой основной поинт, почему не трогаю hard - экономия времени
alexandr93
29.10.2025 09:21Особенно мне интересно как люди решают контесты. Там вроде как 4 задачи. И есть довольно сложные. И вот топовые китайцы решают всё минут за 10-20. Вот это кажется вообще нереальным.
qveex Автор
29.10.2025 09:21Для меня это даже сейчас звучит как что-то нереальное
Кажется, люди этим всю жизнь занимаются, либо реально гении
domix32
29.10.2025 09:21Ну, так китайские студенты гриндят как Anfet работает - по 10-12 часов в сутки без продыху. Только наверняка реальный рабочие часы у человека всё же близятся к половине этого времени, а остальное на покушать, пообщаться, поволанить в сторонке - чтобы не выгорать. Китаец же тратит 90% этого времени на код, а остальное на покушать. Вот и получаются такие "суперлюди", впихивающие четырёхчасовые таски в полчаса.
sci_nov
29.10.2025 09:21Китайцы после обеда спят, потом работают. Может, в этом секрет?)
domix32
29.10.2025 09:21Их просто много и у них хардкорная конкуренция за хорошие места во всех сферах. Именно поэтому большинство победителей мат.олимпиад по миру тоже имеют узкий разрез глаз. Интереса ради можете посмотреть как выглядит какой-нибудь Gaokao и сравнить с экзаменами МГУ/МФТИ/МИФИ.
sci_nov
29.10.2025 09:21Боком им потом это выйдет. Хотя роботам сойдёт)
domix32
29.10.2025 09:21Ну, к середине следующего десятилетия их на пару сотен миллионов человек поменьше станет, тогда может и жить попроще станет, если индусы не прижмут.
sci_nov
29.10.2025 09:21Индия, в целом, гораздо больше ориентирована на духовность, чем Китай. Индия ближе к России. Пусть прижимают)
supremum76
29.10.2025 09:21Я узнал, что такое лидкод :)
Нас учили на кафедре, все эти штучки дрючки конечно прикольно, но в российской реальности кормить вас будут 1С и эскуэль :) Так реально и выходит.
Pifarh
29.10.2025 09:21Субьективное мнение. Проще под каждую задачу спрашивать у нейросети оптимальные алгоритмы для такой то задачи с условием. Пробелы в знаниях спрашивать там же. для большинства решений этого достаточно. Скорость решения + какое то понимание запоминание. Часто приходишь к такой необходимости быстрее запомнишь решение+понимание структуры решения.
alexandr93
29.10.2025 09:21Нейросетки знают решения и из них очень трудно выудить что-то, что не заложено в стандартные решения. К примеру, была задача, где надо было раобтать с элементами в изменяющемся массиве и авторское решение было с деревом Фэнвика. И нейросетка только про это решение долбила. А я хотел проконсультироваться про другое, но нейросетка долбила, мол только дерево Фенвика, хотя есть и другая реализация у дерева отрезков. Просто нейросетка знает авторское решение и ни в какую не отклоняется от него. Хотя другое решение таки было засабмитано, то есть оно есть.
sinuke
29.10.2025 09:21У меня примерно такой же подход - если могу быстро решить дейли - решаю. Нет - любую попавшуюся, которую могу быстро решить. Не хочется тратить более 30 минут, т.к. семья, работа, ремонт и т.д. За 350 дней - 650 задач.
Однако чувствую, что не хватает системности. Т.е. если подходить к решению более осознанно, решать по каким-то темам, постепенно повышая сложность задач, то, наверное, можно добиться лучших результатовqveex Автор
29.10.2025 09:21Согласен с вами
Тоже считаю, что решение первой попавшейся задачи дает крайне мало профита в последнее время
Кажется, что просто не хватает какой-то глобальной цели и плана
Иначе так можно и застрять на каком-то уровне
Основная проблема в том, что на такой дистанции обучение без плана, я бы сказал, что даже невозможно.
И тут либо самому жестко запариваться и создавать этот план или искать какие-то левые курсы по алгоритмам. У Яндекса что-то такое есть, но даже не думал пробовать пока
sinuke
29.10.2025 09:21Я попробовал зарегистрироваться на тренировки по алгоритмам от Яндекса в этом году. Отвалился в первый же день =)) И вот почему:
Задачи не самые простые, я бы сказал medium+. Т.е. времени на само решение нужно потратить немало
Во многом тесты придумывать самому, что тоже время
Решение нужно оформлять практически как полноценный проект с импортами (не так как на LeetCode, где просто решаешь). В общем, это тоже время
В целом, задачи крутые, заставляют думать над решением, продумывать и контролировать свое решение. Есть чатик для обсуждений, еженедельные разборы. Но времени на это нужно прилично.
qveex Автор
29.10.2025 09:21Получается полноценное обучение прям, а не по 15 минут в день на литкод потратить
Нужно собираться с мыслями и конкретно тратить время) Не каждый готов к такому
Warperus
Литкод - это не замена теории и не мерило красивого кода. Учить теорию больших О по литкоду - это как учить язык по дуолингво, примеров много, но правильных ответов не найдёшь.
Алгоритмическая сложность "производительного" алгоритма O(N), потому что сортировка 26 значений в O-нотации это всё ещё O(1).
Потребление памяти обоими алгоритмами O(N), хотя константа у левого и меньше. Наивно полагать, что на больших N слово влезет в память константного размера.
Попробуйте прогнать эти решения со строкой в миллионы символов.
qveex Автор
Согласен. Учить что-то на литкоде - довольно сомнительное удовольствие с невнятным результатом. По-хорошему это инструмент чисто для практики, но так вышло, что через "игру" и "соревнования" это интереснее делать, поэтому способ в какой-то степени рабочий.
По сложности тоже согласен. Не самый удачный пример выбрал все-таки. Постараюсь поправить этот момент
domix32
O() потребление памяти подразумевает сколько дополнителной памяти будет выделено в худшем случае при выполнении алгоритма, то есть исключая память на входные данные. Если это несколько переменных и исходный входные данные меняются на месте или происходит выделение памяти некоторого фиксированного размера, не имеющего зависимости от размера входных данных, то это всё ещё константа. У производительного примера именно так и происходит, а у лаконичного происходит кучка почти N константных небольших аллокации (
listOf(-2)) в лямбде, которая почти сразу же освобождаются. И вероятно есть скрытые аллокации в zipWithNext, из-за чего и страдает производительность, но эти аллокации делают как раз C*N дополнительных аллокаций, что приводит к амортизированному O(N) по памяти для второго алгоритму и O(1) для производительного.Когда решал задачи на Rust, старался сделать так, чтобы код был лаконичным и производительным. 99.9% задач решались как раз вот такими вот map/filter цепочками с ленивым вычислением. Отслеживание лишних аллокаций - как раз путь к производительному коду. Есть алгоритмы, которые нельзя записать лаконично и производительно, но большинство алгоритмов вполне. По крайней мере в рамках задач на литкоде, где обработка ошибок/исключений обычно не требуется.
qveex Автор
Там был комментарий к предыдущему примеру
По памяти абсолютно правы, это главная проблема коробочных функций, как по мне
Код получается "чистым", но производительность и память явно страдают
В идеале, нащупать эту грань между велосипедом и переизбытком синтаксического сахара. Это и есть наша работа)
Samhuawei
Я бы ещё добавил что первое решение игнорирует полезные практики, например, continue если ветка условия не нужна в цикле. Когда отступов много фокус теряется и легко допустить ошибку. Ну и I там не нужно. Понятно что компилятор оптимизирует обращение к массиву по индексу, но там вполне можно обойтись двумя указателями.