Comments 92
Зашел на LeetCode: Kotlin 1.3.10 - за год ничего не изменилось
Не использую котлин, но вряд ли для решения алгоритмических задач нужна актуальная версия языка или это не так?
Тоже не использую Котлин, но понимаю, почему люди недовольны платформой, где последня версия языка - 4хлетней давности, при этом языку чуть больше 10 лет. Тем более что речь-то не проcто про написание валидного кода - там ещё и соревнование по затраченной памяти и скорости.
там ещё и соревнование по затраченной памяти и скорости
Но тогда понятно, ведь при обновлении версии пришлось бы выбросить все старые результаты? Как вариант, могли бы предоставить выбор - или стабильная версия, или последняя но вне зачёта (или в отдельный зачёт)
Там никто не считает секунды и байты, единственный критерий — прошло/не прошло.
Недовольство коментатора, как я понимаю, в том, что приходится себе наступать на горло и даунгрейдить привычный код, который пишешь на автомате, до версии, поддерживаемой сервисом. На работе уже давно пользуешься новым синтаксическим сахарком, а тут нельзя.
Конечно, можно решать и на старой библиотеке, но в новых версиях добавлено очень много методов в стандартную библиотеку. Эти новые методы позволяют написать в 1 строчке то, для чего в старой либе нужно 2-3 и более строк. Но проблема ещё в том, что время введения функций ведь мало кто помнит, а в результате - ошибки компиляции и переписывание (да, со временем запомнится, но в целом это бесполезная информация). В результате - просто писать не очень приятно и уж лучше пайтон/джава...
Более того, у Scala как-то странно считается время исполнения! 700 мс на очень маленьком тесте. (Ну и Scala 3 нет)
Но вообще очень жаль, что Haskell нет на большинстве подобных площадок. А если и есть (например, CodeForces или sort-me), то либо старая версия GHC (8.10.7), либо даже нет самых базовых вещей по типу vector (приходится юзать array, а тут уже не получится воспользоваться AoS/SoA). С другой стороны CF и sort-me про спортивное программирование (бег в мешках?), а Haskell, как показывает практика, слабо для этого подходит.
Codewars, сильно разнообразнее в плане языков: хаскель уже стабильный, агда в бете
Решение абсолютно любых задач постоянно возрастающей сложности в течение года приведет к тем же результатам.
Правда на работе можно 10 лет перекладывать json и фактически ничему не научиться.
Зачем мне нужен LeetCode, если я каждый день гоняю джейсоны туда-сюда?
Чтобы гонять джейсоны за log(N)
вот как раз для этого: лучший отдых - смена деятельности
Потому что HR важно, чтобы кандидат знал деревья
чему их учат на курсах
Где вы нашли такое?)
В литкодовских задачках встречаются только обычные бинарные деревья, больше ничего из той картинки там нет.
Нет. Есть немного задач, где обычных бинарных не хватает.
Есть на Фенвика, который пишется слёту. Но штук 10-15 я решал именно красно-чёрными. В язык Go поставлена внешняя либа с деревьями. И в Python подтянута внешняя либа с хитрой структурой (которая в каком-то смысле эквивалент сбалансированных деревьев)
Defined behavior - это поведение которое не определено в спецификации. Интересные курсы
Может быть весело и интересно. А ещё это один из способов потренировать умение видеть крайние случаи.
Чтобы, когда у вас возникнет задача, где json надо сначала чуть-чуть преобразовать, вы не впендюрили O(n^2), даже не задумываясь, что вот тут у вас не тупое "перекладывание джсонов", а задача на Алгоритмы. Вполне может быть, что у вас такое уже было несколько раз, но вы даже этого не заметили. Потому что у большинства задач на алгоритмы есть наивное медленное решение.
За LeetCode не скажу, а вот на Codeforces, где, бывало, сиживал вечерами, красивый и чистый код не в почете. Только хардкор по скорости и краткости.
Если на работе работать, то все 5 пунктов прокачиваются и без литкода.
1) Ник в тему
2) Ну повезло Вам с работой. Я пару лет провёл на легаси-дрочильне, где вся прокачка была только в умении "взять побольше да кинуть подальше". И платили не плохо, даже временами было стыдно, что я такой фигнёй занимаюсь за такие деньги.
Работа не этническая принадлежность. Ее выбирают. Я сейчас не конкретно про вас, но киснуть на легаси-дрочильне, а потом идти на литкод и "прокачиваться" там - это какая-то логика наизнанку. Лучше напрячься и попасть на проект, где реально приходится ломать голову, как линейную сложность превратить в константную, а не синтетикой на литкоде заниматься.
Я вижу тут замкнутый круг - чтобы попасть на сложный проект, надо пройти сложный литкод-собес, а где опыт алгоритмов взять, кроме синтетики?
Ту работу я выбрал сам, по задачам она устраивала примерно полгода, а дальше покатилось. Можно ли позволить себе менять работу каждые полгода? Ответ, по-моему, очевиден - нет, потому что в какой-то момент резюме начнёт летать в мусорку с первого взгляда HR.
Я для себя нашёл на литкоде неплохие карточки с разбором алгоритмов по темам, плюс практику. Узнал всякого нового, думаю, поможет в будущем. Я не считаю, что пройдя весь литкод на 100% я стану лучшим погромистом в мире, но это неплохой вариант обучения.
Зачем менять работу, если она нравится? Это как человеку, который ходит в спортзал три раза в неделю посоветовать сменить работу на работу тренером, только потому-что ему нравится там заниматься.
Работа может быть интересной архитектурными задачами, которые приходится решать и получать удовольствие. Литкод же - про алгоритмические задачи, как головоломки, и точно также получаешь удовольствие если наконец-то решил какую-то сложную задачку. Но типы задач сильно разные.
Работа может быть интересной архитектурными задачами, которые приходится решать и получать удовольствие. Литкод же - про алгоритмические задачи, как головоломки, и точно также получаешь удовольствие если наконец-то решил какую-то сложную задачку. Но типы задач сильно разные.
Всё так, подписываюсь под вашими словами
1) Ник в тему
Да. Вопреки мнению в статье, в западном (американском) айти распространено и прямо противоположное отношение к литкодрочерам: непосредственно в разработке абсолютно бесполезная публика.
Первый пункт, по сравнению с литкодом, будет на порядки медленнее прокачиваться. Нужно сделать ошибку, которую не выявят тесты, которые сам-же и написал, потом дождаться, пока она вслывет на проде и еще не факт, что именно тебе достанется тикет на исправление. Короче, никакой обратной связи, либо она есть с сильной задержкой. На литкоде же в тестах как-правило будут крайние случаи, и нажав кнопку проверки сразу получишь обратную связь.
Алгоритмические задачи с Литкода
Ожидание: супер сложные алгоритмы, решающие проблемы мироздания
Реальность: https://leetcode.com/problems/add-two-integers/
p.s. Ну ладно, кто-то непонятно зачем закинул это туда, но самое страшное вот это:
Acceptance Rate 87.8%
На литкоде сидят не только суровые сеньор-джсон господа, поэтому есть совсем никакие задачи. Также там есть обучающие материалы, в целом подходящие для вкатывания в алгоритмы с ноля.
По поводу Acceptance Rate - это любители нажать submit до того, как проверили все случаи через run.
По поводу Acceptance Rate — это любители нажать submit до того, как проверили все случаи через run.
В контексте этой конкретной задачи, мне кажется, это любители нажать submit до того как вообще что-то напишут)
Или любители повыпендриваться, как здесь: https://leetcode.com/problems/add-two-integers/solutions/1968134/21-different-ways-to-solve-this-problem/
Да можно просто случайно опечататься и написать = вместо +, не заметя, что шифт не отработал например :)
Там в условии:
-100 <= num1, num2 <= 100
С другой стороны, конечно, если int размером в байт, то можно и UB.
del
Низя инт размером с байт, по стандарту он должен хранить числа от -(2^15 - 1) до +(2^15 - 1)
В ЦПП единственное требование к инту это не быть меньше шорта. А у оного не меньше байта (чара).
Неверно, это не единственное требование: https://eel.is/c++draft/basic.fundamental#4
Добавлю табличку из cppreference для наглядности
См. int8_t: https://en.cppreference.com/w/cpp/types/integer
Ну вот вам следующий уровень, без операторов "+" и "-": https://leetcode.com/problems/sum-of-two-integers/ :)
Это буквально первая задача из гайда литкода для абсолютных начинающих. Своеобразный hello world. Попробуйте задачи уровня Hard.
-
Ну на самом деле даже на олимпиадах где я участвовал (лет 15 назад хехе), были подобные задачи, они были за день до олимпиады, чтобы проверить среду, что все настроено нормально, что все сабмитится. Ну и заодно разные задачи можно решать очень разными способами, даже есть задачи hard которые очень легко решаются в лоб и литкод их пропускает, а вот оптимальные решения уже интересные и догадаться до них очень не просто.
Ну ладно, кто-то непонятно зачем закинул это туда
Задача суммирования двух чисел — это абсолютно стандартная задача на платформах с автоматическим тестированием; встречал её неоднократно. Она проверяет не способность реализовать алгоритм, а то, что новичок освоил платформу: запуск тестов, сабмит кода. С этой задачей можно экспериментировать: как поведёт себя платформа, если реализовать функцию заведомо неправильно, или зациклиться, и т.п.
Везет человеку с мотивацией. Меня за 2.5 года только на 120 задач хватило (80 мидях). Ненавижу их решать. Вроде ведь и получается, где-то 5-8 мидях за день могу решить, несколько дней порешаю - и полгода отходняк, а то и год. Вроде и понимаю, что надо, а не могу себя заставить. Треш какой-то.
Если вам это не нравится, но вы считаете, что вам это надо, на хабре была хорошая статья.
Ненавижу их решать. Вроде ведь и получается
Strong hire! Мозг кандидата, настроенного на решение реальных проблем бизнеса, всегда будет сопротивляться всякой херне типа литкода.
если бы еще бизнес думал так же) все же большое количество контор считают, что им нужны алгоритмически подкованные люди. Я и сам считаю, что алгоритмическая подготовка - это must have, насмотрелся и нафиксился случаев, когда вектор вместо мапы/сета, односвязный immutable список копируют за O(N^2) на ровном месте, компоненты связности самописные и за квадрат, parquet-файл с сервера отдают постранично, каждый раз перечитывая его с начала (итого - квадратичная сложность, ну а чо такого), ну и так далее. Как бы реальные проблемы бизнеса вроде как решены, но сильно через одно место. Но у меня какой-то внутренний протест против именно задрачивания.
И я тоже насмотрелся как на фронтенде иммитируют работу СУБД и помпезно решают задачи которые там попросту не должны появляться.
Если у вас вектор таких размеров что нужна мапа "для скорости", есть вероятность вы занимаетесь хернёй типа выгребания raw данных из базы и ручной их обработкой.
На типичных страницах со срачами столько комментов, что квадратичный алгоритм по ним покажет заметную нагрузку на CPU в браузере.
В первую очередь, мне их зачем-то все загрузят. Будто я собираюсь их все до единого прочитать.
Я до сих пор пользуюсь "старой версией" Хабра, где все комменты грузятся сразу на одну страницу. Это банально удобнее:
- работает поиск
- можно проскипать пару неинтересных веток, цепляясь глазами за ключевые слова
- если вырубится сеть, можно спокойно дочитать.
Вот как раз бесит невозможность на некоторых сайтах просто прогрузить все комментарии. Полностью согласен с комментатором выше: если фронтенд не написан алгоритмо-фобами, то вполне можно грузить и тыщу и две комментариев. А браузеры пишут те, кто в основном интервью с литкод-задачками проходили, т.ч. браузеры как-нибудь справятся.
Ох, если литкодрочеров ещё и до юзабилити допустить, то всё, туши свет. Взяли вот и в одностороннем порядке решили, без рисёча и согласований, что раз им как-то лучше, то так будет лучше всем. Нет, литкодрочеров однозначно надо держать подальше от разработки. Несомененно, они полезны в ряде специфичных кейсов. Но вот только туда их и надо на выгул выпускать, а в остальном строго держать в загоне.
Нет, литкодрочеров однозначно надо держать подальше от разработки.
Вас в детстве родители били Кнутом (книжкой)? Или вы не решили задачку на интервью и вас не взяли на работу и теперь вы люто-бешено ненавидите всех, кто умеет решать задачи?
Взяли вот и в одностороннем порядке решили, без рисёча и согласований, что раз им как-то лучше, то так будет лучше всем.
Ну если так передергивать, то вы сделали точно так же — сами вдруг решили, что раз вам лучше не грузить все комментарии, то так лучше всем.
Но я лишь высказывал свои предпочтения, которые отличаются от ваших.
Несомененно, они полезны в ряде специфичных кейсов. Но вот только туда их и надо на выгул выпускать, а в остальном строго держать в загоне.
Еще раз повторю свою мысль: если не знать алгоритмы и не уметь решать задачки, то вы скорее всего даже и не заметите, что вот тут вот надо было домашнего алгоритмиста выпускать. Так не работает.
Говорю же, знаю и умею. Вымораживает когда этими "знаниями" с умным видом заметают корень проблем под ковёр - а именно, бездарную архитектуру. Вымораживают когда наоверинжинирят трёхэтажный алгоритм "на перспективу". Только перспектива эта год за годом всё не наступает, а сопровождать этот говнокод надо здесь и сейчас. Когда пора выпускать алгоритмиста отлично показывают тесты производительности. А до этого, пусть, чтоли, хоть не мешает работать, и на этом спасибо.
Когда пора выпускать алгоритмиста отлично показывают тесты производительности
Это так не работает. Если отчёт грузится 5 секунд, пора "выпускать алгоритмиста", или и так сойдёт?
Если у меня ffmpeg кодил файл 4 часа 57 минут, надо его оптимизировать, или уже нормально? Как это понять, не умея в алгоритмы?
Говорю же, знаю и умею.
Т.е. вы критерию "литкодрочеров" удовлетворяете. Обладаете этими порочащими и портящими знаниями. По вашим же словам, вас "допускать до разроботки" нельзя, так что ли?
Вымораживает когда этими "знаниями" с умным видом заметают корень проблем под ковёр
Всегда плохо, когда вместо решения проблем занимаются фигней, да. При чем тут именно умение решать задачки с литкода? Точно так же можно сказать про TDD. Им тоже можно вместо грамотной архитектуры заниматься. Или умение в ООП. Если им обмазаться не понимая, то можно тоже архитектуру испортить. Что теперь, презирать всех кто может ответить на вопрос "что такое инкапсуляция"?
Вымораживают когда наоверинжинирят трёхэтажный алгоритм "на перспективу".
Это на самом деле редкость. Чаще нормальный алгоритм будет и короче и проще наивного. Например там, где можно или делать рекурсивынй брут форс, или пустить 2 вложенных цикла динамического программирования, вторая реализация будет легче поддерживаема, понятнее и короче, даже с объясняющими все комментариями (ну, правда, читающему придется хотя бы со статьей "Динамическое программирование" на вики ознакомиться. Но если в интервью спрашивают алгоритмы, то в фирме уже все итак должны это понимать).
Потом, если вы склонны оверинженирить, то и на литкоде, и на алгоритмических интервью вам будет будет очень нелегко. А если человек способен хотя бы зазубрить и воспроизвести различные алгоритмы, то ему должно хватить IQ понять, где их стоит применять, а где нет. Плюс присущее всем человеческое качество лень — предотвращает нерациональное использование сложных алгоритмов.
Когда пора выпускать алгоритмиста отлично показывают тесты производительности.
Тесты не говорят, что где-то наговногочено. По просто замерам времени не понятно, это близко к оптимальному, или вообще печаль. Даже сравнительные тесты почти 100% времени будут показывать, что производительность постепенно падает и все.
И опять же, дешевле нанимать тех, кто сможет сразу не впендюривать квадраты там, где они не нужны, вместо того, чтобы переодически выпускать алгоритмистов переписывать практически все.
Я – фронтенд-разработчик, и за последний год встречалась с необходимостью использовать нетривиальные алгоритмы несколько раз. Наиболее сложные случаи были связаны с визуализацией графов.
У фронтендеров слегка отличаются задачи от типичного leetcode / codewars и прочих. При чем и по реальной работе и по вопросам на собеседованиях. Фронтам не особо нужны задачи на динамическое программирование или backtracking, но зато нужно больше задач на обход деревьев и задачи на асинхронность. Особенно на асинхронность. На литкод недавно даже отдельный блок с JavaScript добавили. Также рекомендую https://bigfrontend.dev/
На моей текущей работе всё отлично со внимательностью к таким вещам, но до неё я повидала всякое (и наслышалась от знакомых тоже). Далеко не во всех местах реальной разработки всё так же хорошо, как у нас с вами сейчас.
Ну и плюс в тексте я упоминала это ближе к контексту, когда падает один крайний кейс из нескольких десятков. Даже с очень грамотно построенными процессами, от всех возможных багов на 1000% не застрахуешься наверняка, разное случается.
А авторка точно уверена, что это произошло благодаря литкода, а не благодаря тому, что она в течении этих полугода на работе каждый день решала реальные рабочие задачи?
Уверена: на тот момент, когда я решала, моя работа была достаточно рутинной.
Лучше вечер потратить на прочтение полезной книжки про юнит тестирование например и багов станет меньше.
Можно и нужно! Книжки и юнит тестирование — это прекрасно. Одно другому не мешает.
Вообще то мешает, общий ресурс время.
Вам виднее, на какие вещи тратить своё время. Я рассказала, по каким причинам решила тратить своё свободное на задачи, и развитие внимательности стало одной из них. Хорошо совместилось с навыком тестирования и улучшило качество самопроверки.
Что за навык "тестирование"? Вы тестировщик? Программирование состоит не только из локальных алгоритмов. Большая часть времени это организация архитектуры, рефакторинг и здравые решения, на одной внимательности вы не выедете, если вдруг у вас получится спагетти код который будет без ошибок. Бинарный поиск или быстрая сортировка не скажут вам как сделать не спагетти.
Да и это банально не интересно набивать алгоритмы вместо изучения интересных и полезных кейсов. Очнитесь.
Большая часть времени это организация архитектуры
Большая часть времени это у кого? Лично у меня организация архитектуры занимает меньшую часть, а большую алгоритмы, математика и всякие скорее лоу левел оптимизации. Те же алгоритмы это скорее для меня частные случаи интересных и полезных кейсов и мне интересно их изучать. Программирование большое и интересные и полезные кейсы для всех разные. Я например точно так же могу сказать "зачем тратить время на архитектуру приложений, хотя гораздо интереснее и полезнее потратить время на изучение процессорных и GPU архитектур, математику и алгоритмы (те же lock-free)".
Лучше вечер потратить на прочтение полезной книжки про юнит тестирование например и багов станет меньше.
Но и к офферу в FAANG не приблизит.
писал ранее - участь решать задачи вы приобретаете только один навык - умение решать задачи. для того чтобы эти решения перешли в что-то большее - нужно образование или определенные навыки с рождения (гены).
как хороший пример - зазубривание билетов при сдаче экзамена ПДД. Это абсолютно никак не помогает в изучении ПДД и тем более не дает никаких навыков вождения, если - про если я уже написал выше. У большинства никаких "если" в принципе нет. Поэтому подача таких ресурсов как панацеи это какая-то глупость.
Давайте посмотрим на мои 25 лет работы - я написал кучу кода на разных ЯП и ни разу в жизни не занимался чем-то что потребовало бы от меня знаний теории графов, деревьев или бинарных поисков, сортировок, поиска подстроки в строке и т.п. Если такие вещи и использовались, то как встроенный инструмент библиотечных функция ЯП. Причем то, чем я занимался в 1999 году вообще никак не пересекалось с работой в 2005 году и тем более сейчас. Опыт 1999 года мне совсем не пригождается сейчас. Несомненно есть люди, которые работают в определенном направлении и все эти задачки для них реальность, но из статей-то этого и не видно, всегда подача такая что без LeetCode ты вовсе не человек.
Ну как минимум там хочешь-не хочешь познакомишься со структурами данных и попробуешь их, узнаешь что такое сложность алгоритма и почему она важна и так далее. Например я видел людей которые не знают чем std::vector реально от std::list или std::map от std::unordered_map, что в общем-то не лишние знания (хотя для этого можно по диагонали учебник алгоритмов прочитать, но кому-то формат литкода проще). И нарешивать тысячи заданий для этого не обязательно. Хотя имхо это вполне себе занятные тематические головоломки.
это вопрос самообразования. никто не сомневается что нужно читать, изучать, пробовать и т.п. а литкод только еще один из инструментов. я же конкретно указываю на аспект, где литкод подают (как и изучение алгоритмов) как всепоглощающую обязательность без вариантов).
как пример могу привести себя - если я просто прочитаю про std::vector но не буду им пользоваться, то я забуду про него через неделю, а через пол года, если появится задача где его нужно использовать, я опять окажусь в ситуации - не знаю, надо почитать, попробовать. То есть я никогда не покрываю знанием весь ЯП со всеми библиотеками. У меня есть пару знакомых, у которых феноменальная память и они всё держат в голове, они и пишут хорошо и зарабатывают много, но я не они. И я когда-то давно думал что я один такой, но позже узнал и других людей и много материалов почитал про память в целом и оказалось наоборот, что такой как я это и есть норма, а все кто лучше меня, вот такие они уродились молодцы.
Ну я и не призываю именно сидеть и прорешивать, хотябы просто ознакомиться с алгоритмами и структурами данных (для кого-то формат литкода удобнее, для кого-то учебник). Просто если даже у вас память не очень, вы можете ознакомиться со структурами данных и посмотреть что из ни что в вашем языке и у вас есть все равно неплохой шанс когда вам нужен определенная структура вы можете вспомнить "ага, я помню что что-то когда-то читал, что конкретно было не помню, но надо пойти посмотреть данную тему", если никогда не читали, то и вспоминать нечего и есть вероятность выбрать плохую структуру/алгоритм потому что он работает, а о существовании аналогов не знаете. То есть не с целью вызубрить изучать, а просто ознакомиться по крайней мере с основными алгоритмами и структурами и их маппингом на контейнеры языка.
Хотя конечно надо учитывать что в принципе память у меня не плохая (по крайней мере на уровне "ага, я помню что то читал по теме, кажется в этой статье/книге, надо бы перечитать"), работа связана с математикой/алгоритмами/оптимизацией в основном и есть определенный биас по этой теме.
мысль понятна, но я не об этом. впрочем не важно.
когда вам нужен определенная структура вы можете вспомнить "ага, я помню что что-то когда-то читал
у меня это так не работает. я скорее всего даже не вспомню что вообще читал об этом.
если никогда не читали, то и вспоминать нечего
пока я с чем-то работаю почти каждый день, у меня это так и происходит - ага, я вчера что-то похожее делал, надо почитать СНОВА и вспомнить как это я делал. ВЧЕРА дружище, не месяц назад, а только вчера. Если я это читал прошлой осенью, то в лучшем случае я вспомню что читал что-то по C#, а что именно - никто не знает. Я IDE VS современный чем обожаю, так это подсказками по формату данных, я вижу что выше использовал например GetInteger, набираю, а он мне показывает как его оформлять, ибо я не помню. В общем всё очень сложно))))
вероятность выбрать плохую структуру/алгоритм потому что он работает, а о существовании аналогов не знаете
никогда в жизни такое не делал и никогда не знал о таком выборе и об альтернативных вариантах. как правило я пишу в гугле направление в котором хочу двигаться, нахожу варианты, читаю, изучаю, выбираю, если есть из чего. В основном пишу чтобы работало, а потом оптимизирую. Часто оптимизация равна написанию с нуля. Я пишу софт очень долго, поэтому в явном виде никогда в этом направлении не работал профессионально. По сути я пишу его в голове как некую структуру, а потом просто заворачиваю в код. Структуру конечно всегда привязываю к платформе, на которой это будет работать, например на старых системах это вопрос выбора аппаратных возможностей и ограничений например по памяти.
не с целью вызубрить изучать, а просто ознакомиться по крайней мере с основными алгоритмами и структурами и их маппингом на контейнеры языка.
когда я сравниваю ассемблерные команды MOS 6502, которых 200 штук всего и их документацию и MS .NET, который я вообще не знаю кто-то выучить весь способен? То я не представляю сколько нужно времени чтобы хотя бы ознакомиться с .NET, я уж молчу чтобы знать весь АП со всеми библиотеками и еще и профессионально им пользоваться. Я на 6502 пишу довольно часто и часто же читаю мануал по его инструкциям. Я конечно помню всякие BNE, STA, но я могу не помнить например работает ли команда только с регистром или можно передавать и адрес памяти. Полез в мануал, прочитал. Через неделю еще раз и т.д.
Поэтому что-то учить заранее не вижу смысла, тем более не ясно будешь ли этим вообще пользоваться, а некоторые вещи даже из примеров непонятно как использовать и зачем.
PS: есть такая штука как MSDN, думаете кто-то её знает наизусть? Не уверен что это возможно в принципе.
Ну я в общем то не к тому что надо пытаться прочитать или выучить тот же MSDN, если попробовать прочитать и запомнить весь cppreference то можно в психбольнице оказаться нечаянно :) Я скорее про случаи что вам могут скорее всего пригодиться и более базовые - прочитать какие основные контейнеры есть и каким структурам данных соответствуют и какие основные алгоритмы в языке есть - сортировка например, поиск, да и наверное всё. В моем представлении это что-то вроде того как вы начинаете новый язык учить и смотрите как там циклы, условия работают, как функции объявлять и т.д. А вот как раз конкретику можно уже и гуглить каждый раз (условно хорошо знать что есть std::map и для чего сама структура подходит, а уж как конкретно из нее например удалять, да можно и загуглить когда надо, обычно тех же контейнеров в языке ну штук 10 наберется, реально полезных которых после прочтения в голове стоит оставить штук 5). Но это само собой личное ИМХО и на истину в последней инстанции не претендую, для каждого оптимальный вариант может быть свой.
участь решать задачи вы приобретаете только один навык — умение решать задачи
Умение решать задачи — это реально крутой навык, которого многим не хватает. Ведь даже это пресловутое перекладывание джейсонов — это тоже задачи, хоть и тривальные. Умение разбить их на части, структурировать решение, представить его в голове и перевести это в код — оно вот вообще не лишнее программисту. И это именно то, что я бы и описал навыком "решать задачи".
Нужны нормальные исследования
Это может быть самовнушением. Корнер кейсы можно обдумывать и при TDD подходе.
Как по мне, алгоритмы и структуры данных -- это мат. часть, которую лучше знать, чем не знать. Вот до какой степени, зависит от ваших нужд. В таком изучении больше "системности" что-ли в знаниях.
Попробую привест три аналогии:
1) Можно научиться играть на гитаре не зная нот и вообще теории музыки. И многие так и поступают. Если эта глубина владения инструментом вас устраивает, то и не стоит дальше идти. В этом ничего плохого нет. А если захотите расширыть свои занния, то придется учить музыку. Будет ли это лучше, чем учиться сразу "правильно", сложный вопрос. Но по мне, скорее всего это хуже.
2) В шахматы тоже можно научиться хорошо играть просто начав играть. Если вас устраивает ваша игра в шахматы, то дальше что-то учить нет смысла. Но если хотите играть лучше, придется учить мат. часть. И опять же, будет ли такой подход лучше, тяжело судить
3) Иностранный язык. Можно бегло научиться говорить и писать, без особых знаний грамматики языка. Этого почти всегда достаточно для обширного числа работ на которые устраиваются люди. Но если возникает необходимость вести диалог в более формальной плоскости, сразу выявляются проблемы.
Суть в том, что хорошее знание мат. части в любой области никогда не навредит. Скорее всего, оно сделает вас только лучше.
Вы в любом случае решаете какие-то задачи на работе. Причем всегда. Явно или не явно вы пишете алгоритмы и используете стурктуры данных. Так вот вам предлагается тренажер, где вы можете прокачать этот навык да еще и мат. часть поднатаскать. Почему бы этим не воспользоваться?
А вот интересный аргумент, что алгоритмы прокачивают мышление. Но насколько это актуально для практического ремесла? Если основная часть работы это фреймворки и поддержка существующего кода
Как задачи на LeetCode прокачали меня как разработчика, или по-честному про алгоритмы