Pull to refresh

Comments 182

Голосовалка плохая. Сначала для собеседования решал, а потом уже для души. Это просто напросто интересно, в конце концов.

Тут все конечно зависит от ваших целей в IT - если интересные проекты в дружном коллективе, то алгозадачи вам пригодятся. А если просто хочется денег заработать, то лучше избегать компаний, где на собеседованиях присутствует LeetCode-секция

Внезапно, сейчас она присутствует почти во всех ведущих компаниях.

не подскажете, это в каких?

Да начиная от FAANG'ов с майкрософтами (которые, кстати, платят сильно выше среднего по рынку) и заканчивая всякими HFT-конторами.

UFO just landed and posted this here
UFO just landed and posted this here

Я, например, никогда не использовал бэктрекинг и динамическое программирование в реальных проектах. Когда первый раз сталкиваешься подзависаешь.

UFO just landed and posted this here

Можно считать динамическим программированием генерацию строки-команды в баше для ssh?

Если при генерации этой строки использовался алгоритм с подходами ДП, то да.

Я не очень понял вопрос, но скрее всего нет.

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

В вашем же случае каждый следующий шаг использует данные снаружи.

Динамическое программирование — это решение класса однотипных задач через рекурентные соотношения с запоминанием результатов. Я слабо представляю как генерация команд для ssh сюда натягивается.

Так у хфт и гугла это хотя бы оправдано, а зачем такое у условного банка, где ты будешь 99% времени писать бизнес логику, вообще не очень понятно

Я не обсуждал осмысленность (спойлер - в фаангах с т.з. реальных задач это в 90% случаев оправдано ничуть не больше), я обсуждал факт наличия. :)

Из российских это точно озон, тинькофф и яндекс

тинькофф

Видимо, зависит от стека. У меня был лайвкодинг, но там было скорее "вот кусок кода, как бы ты его отрефакторил".

Вот тут собраны описания процесса для разных категорий. Надо докрутить до "Направления и секции"

https://www.tinkoff.ru/career/it/interview/

Если открыть бэкенд, то там литкод прямо в материалах для подготовки прописан

У меня такое было на первом собесе(типа скрининга). На втором уже норм секция с алгоритмами (пусть и не жутко сложными)

А если просто хочется денег заработать, то лучше избегать компаний, где на собеседованиях присутствует LeetCode-секция

Если не считать очень везучих стартапов, то условные FAANG, с котрых эти leetcode интервью и пошли — это одни из самых высокооплачиваемых позиций в IT.

думаю, что это заблуждение (но пруфов конечно не будет, основано на отзывах знакомых кто там работает)

Ну есть же levels.fyi и glassdoor.com. Это можно же посмотреть.
По личному опыту говорю. По крайней мере в Швеции Гугл платит повыше рынка.

UFO just landed and posted this here

Именно поэтому я написал "faang… это одни из самых высокооплачиваемых позиций в IT". Не самые-самые, но уж точно не ниже рынка.

А что спрашивают на сложных финтех интервью? Или под финтехом речь идёт про HFT, где идёт борьба за каждую нс?
UFO just landed and posted this here

Возможно, зависит от страны, но в Германии финтех существенно ниже FAANG по зарплатам.

UFO just landed and posted this here

Там - это в каких конкретно компаниях в каких конкретно локациях? :)

Внезапно, но самое эффективное решение не всегда оказывается самым читаемым

Чтобы избежать противоречий, можно говорить о разных аспектах решения:


  • корректность
  • потребление памяти и процессорного времени
  • легкость чтения/изменения/дополнения

Несколько раз встречал такое в своей работе. Самое эффективное по скорости решение было самым сложно читаемым. Следующее по эффективности решение (чаще всего имеющее ту же сложность в O-нотации, но отличающееся коэффициентами - например, вычисляющее результат не за два прохода по массиву, а за три) было намного более читабельно и компактно. Выбирали более читабельное.

А самое неэффективное, какой-нибудь полный перебор, вы в это сравнение даже не включаете. Скорее всего оно там есть и будет еще хуже решения с двумя проходами.

вот совсем не факт, с одной стороны теоретически обоснованный алгоритм, с другой - реальное приложение, где на выполнение вашего алгоритма влияет куча различных параметров.

Этоже классика, производельность против простоты. Читаемость обычно свзяана с простотой. Хотя именно в опубликованных здачах на литкоде часть читаемость ужастная. Там свой особенный стиль.

Если говорить о Питоне то читаемость и производительность часто идут рядом. Чем болше ты используешь стандартную библиотеку и меньше кода пишешь, тем Питон быстрее работает.

Ну кстати решение влоб может быть сильно более раздутым и сложночитаемым чем эффективный алгоритм.

Читаемость падает когда начинается байтодрочерство.

Всё-таки производительность лучше мерить не в О-нотации, а в профайлере на реальных данных в проде)

Я правильно понял вашу мысль: вместо того чтобы на раннем этапе разработки алгоритма прикинуть примерное BigO и объёмы данных, и на основе этого сделать выбор в пользу того или иного алгоритма… вы предлагаете написать, как пишется, и когда оно почему-то начнёт тормозить, начать это всё исследовать в профайлере, находить боттлнеки и выяснять почему алгоритм оказался "не очень"? :)


Пожалуй для Bodyshop-а с платой за время и количество закрытых тасков это и правда оптимально.

О большое это дешёвый способ оценить сложность перед написанием, профайлер дорогой и применяется после.

Другими словами используйте O большое всегда, а профайлер если есть для этого причины.

Может показаться что профайлер выдаст точные данные. Но тут на самом деле миллион нюансов.

Нужно тестировать на том-же желез, что и в проде. Мы как-то запустили нашу платформу на устройстве с SD картой и оказалось, что удалить пустой файл занимает больше 1 секунды на фоне прочей нагрузки на диск.

Если данные однородные то нужно просто выбрать правильное количество, а вот если нет, то протестировать все комбинации которые возможны в проде.

Я пробовал прфилировать на локальной машине, но зачастую в проде это не давало ожидаемого результата.

Почитайте старое (1960-е) сатирическое эссе Сирила Паркинсона о том, как правильно нанимать людей на работу: бенефиты должны уравновешиваться сложностями и опасностями — иначе вас завалят кандидаты. Прочитали? Теперь порадуйтесь, что только алгоритмические задачки, а не плыть в бассейне наперегонки с живым крокодилом…

К счастью, с крокодилом -- это не последняя доступная вакансия на рынке, где-то и формошлепов берут только за сам факт явки на собес :)

уйдет глубоко под корку

Под какую корку? ) Наверное всё-таки "уйдёт в подкорку", это же про вполне конкретные отделы мозга выражение, которые в обиходе "подкоркой" именуют.

А если изучить квантовую физику, то вы сможете понять как работает квантовый компьютер...

Это тоже сделает ваш мозг более эффективным.

Но вы не бросаетесь на это.

Думаю тут просто выбор каждого... Кому то алгоритмы по душе, кому то нет.

Так то оно так, только не надо забывать, что алгоритм, по определению, - это последовательность операций для решения задачи. И программисты, пишущие код, вообще-то, как не крути, именно алгоритмы реализуют (в большинстве случаев), пусть зачастую и не шибко сложные. А раз так, то и тренировка мозга решением алгоритмических задачек явно лишней не будет. А то иногда случается такое, что некоторые программисты задачки условно уровня fizzbuzz не могут адекватно решить (или решают, но настолько переусложнённо и запутанно, что диву даёшься).

В 90% используется библиотека языка, в которой работа с коллекциями встроена.

Другое дело что если потребуется прямо еще быстрее и эффективнее чем то что уже есть... Но часто ли у вас такое бывает

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

Стандартную библиотеку так-то тоже нужно уметь использовать, чтобы не было list.sorted().first()

Та ну мне кажется достаточно голой математики, чтобы понимать как он работает.

Несколько раз видел, что программисты в своей ежедневной работе в упор не замечают, что у них получается сложность решения O(N^2) или вообще O(N^3). Так что автоматически понимать прямо в процессе написания кода, какая сложность у него получается, и насколько это критично на твоих размерах данных - это сам по себе ценный результат изучения алгоритмов и прорешивания задач.

Зачастую проще не заморачиваться и пройтись по списку из 5 элементов несколько раз в разных местах, чем переложить в мапу и обеспечить себе 0(1)

Какие то моменты игры в перекладывания в разные структуры хранения для оптимизации норм...

Но на литкоде часто откровенно задротные алгоритмы на харде... И вероятность такое встретить в реале весьма низка.

Поэтому если вам нравится в этом копаться и разбираться это хорошо, ваше хобби в рабочей стезе, но это не обязательно.

Есть тех команды, там вот такое только в путь, весьма, полезно.

Но большая часть команд бизнесовая (в мире java по крайней мере) и там это просто приятное дополнение, не боле.

Зачастую проще не заморачиваться и пройтись по списку из 5 элементов несколько раз в разных местах, чем переложить в мапу и обеспечить себе 0(1)

Это всё ещё сложность O(N), и учитывая гарантированно малое количество элементов (5), можно считать её близкой к O(1). Повторю, что я писал о сложности O(N^2) и выше, при этом время выполнения стремительно растёт даже для сравнительно небольших размерностей списков/коллекций/etc., которые легко могут встретиться в продакшне. Очень важно понимать такое прямо в процессе написания кода. И по моим наблюдениям, у программистов без опыта литкода такое понимание затруднено.

Но на литкоде часто откровенно задротные алгоритмы на харде... И вероятность такое встретить в реале весьма низка.

Да, есть такое. Подавляющее большинство из них я никогда не применю на практике. Но вероятность не равна нулю. Всё-таки круто, встретив в реальной работе аналогичную задачу, сказать "Я помню с литкода, что здесь есть оптимальный алгоритм за O(N). На наших данных это поднимет нам RPS/снизит нагрузку на CPU на ... процентов."

В разных языках по разному, в Питоне очень приятный API для словарей и порой правильный ход будет не сложнее простого алгортма. По производительности на 5 элементов там сущая лотерея, логически это не доказать, только измерение. Да и то с новой версией языка всё может поменться.

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

Поэтому да, если какой-то программист в США хочет сменить работу на бигтех, сколько бы у него не было опыта, он садится и начинает готовиться к собеседованию. И порой процесс подготовки занимает 5-6 месяцев, включая различные сервисы и персональных тренеров, которые подтягивают его по каким-то моментам собеседования. Например, вот целый сервис, который учит тебя правильно вести на собеседовании и правильно обсуждать зарплату

Проблема в том, что иногда галеры начинают вести такие собеседования, как будто они бигтех, нередко еще предлагая и зарплату ниже рынка. Вот как раз это и вызывает недоумение- я иду на позицию миддл+ на 2-3к$, а они требуют знания и умения как в фаанг.

Потому что такие галеры продают вас заказчикам как Senior+

Это у вас как аналогия с этими старшими консультантами и специалистами, которые на самом деле обычные операторы в call-центрах?

UFO just landed and posted this here

И вот после того, как вы прочитали 2-3 книги, которые могут у вас занять порядка 3-4 месяцев

Читаю первую вот уже 8 месяцев по полтора часа каждый день. Дошёл только до 4-й главы (делаю все упражнения). 3-4 месяца на две книги — очень нереалистичный прогноз.

"Академиком может стать каждый. Но некоторым для этого нужно 200 лет." :)

Это тот самый случай, когда профильные вузы оказываются нужными. Конечно, как мы видим, есть и книжки с курсами, но ни одна книжка не заменит работу с преподавателем (опять же, смотря с каким ещё). Подавляющее большинство направлений, связанных с разработкой ПО, имеет в своём арсенале одну или две дисциплины, связанные с алгоритмами и обработкой данных. А LeetCode — отличная возможность попрактиковать обретённые знания ;)

Если говорить про реалии РФ, и не про топовые вузы, то преподают это, как правило, очень странные люди, с разработкой ПО знакомые только по книжкам.

У нас на втором курсе дисциплину "Анализ комбинаторных алгоритмов" преподавал местный гений - начальник вузовского отдела АСУ, бывший олимпиадник и будущий директор одной из ведущих местных компаний, разрабатывающих ПО.

С тех пор на всю жизнь осталась привычка оптимизировать абсолютно все, что видишь, вплоть до приготовления завтрака)

А у нас программирование вел Василий Юрьевич Б, админ из одной крупной аутсорс-компании на L; пришел он на лекцию с книжкой по плюсам, книжка была древняя и хэллоуворлд из нее не компилировался, что нужно исправить он сам не знал. Благо я за пару лет до этого начал самостоятельно изучать кресты и догадался, что нужно было исправить инклуд stdio.h на cstdio или что-то в этом духе. А то пришлось бы нашей группе изучать basic или паскаль)

Однозначно полезно решать литкод.

Как минимум в голове освежаются структуры данных, да и в целом в работе меньше начинаешь бояться алгоритмических каких-то штук.

Но лень. Премиум помогает два месяца в году - за месяца до экспайра и месяц после продления премиума :) Приходится себя заставлять, но это уже не к литкоду вопросы.

Внезапно, но самое эффективное решение не всегда оказывается самым читаемым. 

Но часто случается и наоборот. Например, динамическое программирование в 3 простых вложенных цикла и одно присвоение внутри оказываются гораздо более читабельнее рекурсивного полного перебора. Конечно, при условии, что читающий хотя бы статью в википедии про динамическое программирование читал.


Лично код переписывал с перебора на ДП — вместо двух сотен строк получилось 30 (с комментариями и объяснениями).


Как правило, в работе не нужны все алгоритмы, нужна какая-то узкая область

Вот только вы не знаете, что это за область. Вот, например, разработка библиотеки webrtc. Даже не кодеки с их математикой, а вот вся эта обертка — засунуть пиксели в энкодер, передать сжатые данные на другой конец, засунуть в декодер. Вот очевидно вам, что там понадобятся:
линейная регрессия, теория чисел, динамическое программирование, moving window max (прямо задачка на литкоде такая есть), фильтр калмана.


Потом, литкод и не учит же Алгоритмам, как таковым. Там только самые базовые вещи же и применяются: ДП, какие-то трюки с сортированными массивами, стеками, обход вширину/глубину. Ни алгоритмов дейкстры, ни блюма-флойда-пратта-ривеста-тарьяна, ни кнутра-морриса-пратта там не используется. Даже сортировки как таковые там ограничиваются вызовом функции sort() и пониманием, что оно рабоатет за n log n.


Вторая часть проблемы в том, что очень многие задачи имеют простое в понимании, медленное наивное решение. Если вы не знаете, что вот есть такие вот алгоритмы, то у вас даже мысли не появится, что вот тут надо не пройтись по спискам туда-сюда несколько раз, а можно динамическое програмимрование впендюрить.


Поэтому алгоритмы лучше знать. Хуже от этого точно не станет, а вот пригодится может (и пригождается).


в условную функцию может прийти какой-то узкий набор данных предсказуемой длины.

А через пол года данных в базе становится все больше и все начинает тормозить.


не так уж много задач, где сложность той или иной функции, как-то влияла на пользовательский опыт юзера софта.

10% замедления вот тут, 200% вот там, 10000% еще где-то. Оно все складывается и накпливается или у пользователей вылезают внезапные тормоза в непонятном месте.

Ни алгоритмов дейкстры

https://leetcode.com/problems/network-delay-time

кнутра-морриса-пратта

https://leetcode.com/problems/longest-happy-prefix

Даже сортировки как таковые там ограничиваются вызовом функции sort() и пониманием, что оно рабоатет за n log n.

https://leetcode.com/problems/sort-an-array/

Признайтесь, вы литкод в жизни не открывали, верно?

В первой очень простые ограничения. Там Беллман-Форд заходит, а пишется он, имхо, легче.

Иррелевантно, поскольку исходный тезис был "Потом, литкод и не учит же Алгоритмам, как таковым". Будет Беллман-Форд вместо Дейкстры, какая разница.

Первая задача слишком мелкие ограничения. Во второй можно не только KMP, но и хешами решать.


Признайтесь, вы литкод в жизни не открывали, верно?

~730 задач, 260 hard, Top 0.56% в рейтинге каком-то там.


Но эти три задачи мимо меня прошли. Все-таки это капля в общем море задачек на списки, массивы и использование hash-map'ов.


Я был не совсем прав, но все-равно утверждаю, что можно прорешать почти весь литкод не изучая никаких сложных алгоритмов. Плюс на интервью всяких их тоже спрашивать не будут.

Первая задача слишком мелкие ограничения. Во второй можно не только KMP, но и хешами решать.

Понятно что можно, но обычно люди после решения идут в Solutions и смотрят, как еще можно было. Особенно если твое решение по скорости/памяти где-то в самом низу (если вообще не свалится с таймаутом).

https://leetcode.com/problems/top-k-frequent-elements - хочешь быстро? Разбирайся в Quick select'e.

Но эти три задачи мимо меня прошли.

Это тупо те, которые гугл выдал первой строкой. Так там только на Дийкстру в том или ином виде десяток задач.
https://leetcode.com/list/53js48ke/

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

Можно и в универе 5 лет отучиться и выйти полным дубом. На литкоде есть отличные study plans, есть мини-курсы по разным разделам. Практически все средние/продвинутые из них трогают вещи посложнее BFS/binary search. Ясен пень это не замена четырёхтомнику Кнута, но я бы не сказал, что мой универовский курс по тем же графам мне дал сильно больше.

Хорошо, Дейкстру вычеркиваем.

Спор из разряда «нужна ли программисту математика».

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

И вот после того, как вы прочитали 2-3 книги, которые могут у вас занять порядка 3-4 месяцев, можно приступать к решению задач на Leetcode.

Как же это неэффективно...

Я не решал никогда задачи с литкода, пару месяцев назад начал ради интереса. До этого никогда не учил алгоритмы и структуры данных специально.

Да, иногда я решаю задачи топорно и не оптимально, но к счастью есть вкладка Solutions с сотнями разборов задачи на любой вкус. Ознакомление с одним-двумя приводит к полному понимания решения. На всё уходит 2 часа максимум (для уровня hard), если не решаешь упороереться и придумать решение сам. В итоге голова сразу пополняется практическими навыками. Так я освоил динамическое программирование, кучу и много другого.

Книги как мне кажется как раз более для "развития когнетивных способностей". То есть из литкода вполне себе можно понять те или иные алгоритмы, а книги это скорее "а почему этот алгоритм работает? а как это доказать строго математически? а вот квиксорт n * log(n) в среднем, а давайте докажем с помощью теорвера что это так" и так далее. Тут конечно кому что интересно так как редко кому в работе это пригодится. Ну и в книгах алгоритмы более структурированны по темам обычно и идут в более-менее логичном порядке.

Особенное удовольствие на Литкоде мне доставляют не «эталонные» решения, кои можно посмотреть и в других местах, а красивые «хакерские» штучки. Там в обсуждении к каждой задаче любой может выложить своё решение, и на некоторые вещи смотришь, как на «Мона Лизу», или там «Лебединое озеро». Вроде все операторы понятны, но КАК это можно было придумать?
делает ли это тебя лучше – безусловно,
как программиста – кто знает,
будет ли полезным для работы – вероятно нет, но какая разница?

Эти задачки тренируют писать чистый и понятный код, который легко анализируется и развивается. Иначе можно зависнуть в трёх соснах даже на относительно простой задаче и так и остаться с прототипом.

Мне больше нравится возможность знакомства с другими языками.

UFO just landed and posted this here

Без грамотной архитектуры что-то уровня hard с несколькими структурами данных не написать. Олимпиадники, действительно, страдают плохими именованиями переменных и функций. Но в индустрии это лечится за одну неделю, если, конечно, в процессе есть код-ревью (а без него в любом случае будет хреново).

Олимпиадники, действительно, страдают плохими именованиями переменных и функций.

Это проблема вообще не связана с олимпиадничеством и есть почти у всех новичков в промышленном программировании.

У олимпиадников это усугублено необходимостью писать код быстро. И привычка выработана. Вот если я всю олимпиадную карьеру обзывал вершину графа v, то поначалу мне бы хотелось также называть и человека в графе друзей, например. Ну, потому что это понятное, говорящее (мне) название. Плюс, олимпиадники, хоть и новички в промышленном программировании, часто имеют весомый опыт собственно программирования. И за исключением коротких имен переменных часто могут сразу стать мидлом.

Тут зависит от того как использовать литкод. Если тупо адаптироваться под систему и фигачить write only, тогда да, может и во вред пойти. А можно писать нормально, с юнит тестами ИТП. В фаангах на интервью обращают внимание на то как код написан, олимпиадный код получит жирный минус несмотря на эффективность.

Может я такого мнения, потому что в основном на codingame зависаю. А там хорошее решение обычно и хорошее приложение в полном смысле. От архитектуры в целом, до оптимизации частностей.

И потом, если у вас уровень высокий, то конечно вы можете писать код любого вида. А новичок на грязном коде далеко не уедет, закопается.

P.S. Олимпиады это хорошо, но многодневные контесты лучше.

Вы не могли бы, пожалуйста, обрисовать разницу между codingame и leetcode? Разные типы задач? Разная аудитория?

Для начала приведу в пример вот такую задачку

Coding Games and Programming Challenges to Code Better (codingame.com)

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

cost = -1 / m * (np.dot(Y, np.log(Y_hat).T) + np.dot(1 - Y, np.log(1 - Y_hat).T))

то поищи, где ошибся =) (мораль простая, нечего лезть в питон без опыта :) )

А вообще Codingame это в первую очередь соревнование. В итоге все упирается в MCTS, генетический алгоритм и т.п. Последний контест шел 20+ дней. Прототип решения на C# у меня 1000 строк, который я так и не довел до ума, а там довольно простенький генетический алгоритм + A*. По сути единственная проблема именно в том, чтобы не утонуть в грязном коде. Банальные магические константы могут на пол дня в аут отправить.

А на C++ там вообще страшно. Случайно вылез за границы массива (или просто использовал указатель в нитуда) и получаешь сообщение "Time out", иди ищи где что случилось. Здорово дисциплинирует.

UFO just landed and posted this here

Тут же всё как всегда - если вы 10 лет посвятили конькобежному спорту, то на выхлопе у вас останется только пара перекаченных ног, которые, внезапно, не помогут вам стать быстрым бегуном.

Поэтому любой человек щелкающий как орешки алгоритмические задачи - останется тем, кто - умеет алгоритмические задачи. Всё.

Так же как знание всех операторов, команд, макросов наизусть ни на каплю вас не приблизит к тому, чтобы вы стали программистом-богом.

Поэтому такие задачи при приёме на работу - это бред, только если человек не ищется на позицию, где эти алгоритмы и нужно применять.

Я знаю-знаю, вы тут же возразите, что тест проверяет способности человека к решению задач в целом и т.д. и т.п., но тогда и тест должен быть не только из алгоритмических задач и потом, я хорошо пишу на ассемблере, но не умею вообще в ООП, то есть я могу написать код на C#, но процедурный. Делает ли это меня плохим программистом или всё же это делает меня узкоспециализированным, но не плохим?

PS: мой брат успешно работает за границей в геймдеве, но он никогда не писал сортировку пузырьком и не знает что такое коды Элиаса XD а я знаю, только у него зарплата в 20 раз больше.

Тут же всё как всегда - если вы 10 лет посвятили конькобежному спорту, то на выхлопе у вас останется только пара перекаченных ног, которые, внезапно, не помогут вам стать быстрым бегуном.

Если вы 10 лет гоняли на коньках, то у вас будут отличная дыхалка, тренированное сердце и адекватно развитая мускулатура. Отличное преимущество на старте перед конкурентами, которые до этого вообще спортом не занимались. Плохой пример, негодный.

то есть я могу написать код на C#, но процедурный

К вопросу решения алгоритмических задач это отношения не имеет никакого.

UFO just landed and posted this here

...в конькобежном спорте или околсмежными дисциплинами, но такое себе если вы устраиватесь автослесарем.

Тут же всё как всегда - если вы 10 лет посвятили конькобежному спорту, то на выхлопе у вас останется только пара перекаченных ног, которые, внезапно, не помогут вам стать быстрым бегуном.

Тред не читай @ сразу отвечай, правда?

Алсо

в конькобежном спорте или околсмежными дисциплинами

В любом спорте/любой деятельности, подразумевающим регулярные физические нагрузки. Даже бухать и сексом заниматься легче.

UFO just landed and posted this here

Судя по тому, что вы не стали дочитывать даже первое предложение до конца — видимо, правда.

Я-то дочитал, но любая аналогия, подобно сове, имеет пределы растяжимости. Подменять в полёте исходный тезис - дурной тон.

Раскрою свою мысль в этих терминах: ваша деятельность подразумевает регулярные алгоритмические нагрузки (цикл for и прочее за нагрузку не считаем)?

Написание программы - это и есть составление алгоритмов, на секундочку.

АЛГОРИТМ, -а, м. (спец.). Совокупность действий, правил для решения данной задачи. А. извлечения корня. II прил. алгоритмический, -ая,-ое.

Раскрою свою мысль в этих терминах: ваша деятельность подразумевает регулярные алгоритмические нагрузки (цикл for и прочее за нагрузку не считаем)? Если да, то для работы вам нужны алгоритмы. Если нет, то для работы они вам —как и 90% всех ИТ-специалистов — не нужны.

С такой логикой мы сейчас дойдём до того, что ИТ-специалистам очень много чего не нужно: начиная знанием, что такое TCP и HTTPS, и заканчивая "что такое видеокарта" и каким проводом втыкать монитор в ноутбук. Я не готов называть таких Митрофанушек специалистами.

Алсо замечу, что вы с ОПом ветки мешаете в кучу два связанных, но не эквивалентных навыка:

  1. академические знания - когда человек может рассказать, как устроен квиксорт, что такое свертка матрицы, O(N) vs O(N^2) и т.д.;

  2. практические умения - способность построить для конкретной задачи алгоритм решения.

Для решения easy/medium задач с литкода в среднем больше нужны практические навыки, чем академические знания. Давать их кандидату чтобы убедиться, что он банально умеет программировать - вполне резонно.

UFO just landed and posted this here

А реальность индустрии такова, что ИТ-специалистам не только не нужно зазубривать решения абстрактных проблем

Верно, не нужно. Специалисту нужен кругозор, в противном случае шаг влево-вправо - и "специалист" превращается в тыкву, потому что вообще не сечёт, что происходит.

программирование — это где решаются проблемы бизнеса

Если у бизнеса ложится критический сервис в горячий период и деньги перестают капать - это проблема. Если у бизнеса утекли данные юзеров и прилетит штраф по GDPR в 4% годового оборота - это проблема.

даже в такие критичные области типа самолетостроения начинают пролезать клятые аутсаффные индусы с их "хеллё май дир френд"

Ну если вам норм конкурировать с индусами, которые вчера сидели в колл-центре, а сегодня прослушали курс на ютубе и стали программистами - я ничего против не имею, вам не нужно ничего из перечисленного.

UFO just landed and posted this here

Факт в том, что современное ИТ это ремесло для индусов из колл-центра,

Тогда тем более нет проблемы брать литкод - кандидатов много, времени у собеседующих мало (и стоит оно дорого), отсеиваем 90%, а c самыми прокачанными работаем. Идеально же.

>Так и должно быть, в общем случае. Кардиохирурги операции по лазерной коррекции зрения не делают.

Плохой пример, негодный. И те, и другие проходят кучу общих предметов вплоть до акушерства и дерматологии. Но по вашей логике первому нужно знать только где у человека сердце, а второму - какие кнопки жать на LASIK-аппарате.

База, разумеется, должна быть, но какие-то базовые знания не включают в себя зазубренность тонны алгоритмов, которые некоторые тут хотят проверять чуть ли не с религиозным рвением.

А я этого и не предлагаю, и даже осуждаю.

То Ажур все сам поднимет и заскейлит, ты только плати (меньше, чем "правильным" программистам).

Если у вас квадратично растёт сложность, то и время (а значит, стоимость) растёт так же. Алсо толку от скейлинга, если у вас каждый инстанс по две минуты тупит и падает, потому что внутри наговнокожено?

Данные юзеров к алгоритмам никакого отношениями не имеют

Не имеют, но они требуют знания правил работы с ними/OWASP, общего понимания законодательства, понимания основных принципов ИБ и криптографии (например, почему нельзя хранить пароли плейн текстом, или для чего нужна соль в хеше), и так далее. Все те вещи, которые, по вашей-же опять таки логике, им не нужны, ведь они формочки клепают.

Вы и ваш оппонент оба правы. Мне, безусловно, приятнее работать с человеком, который мыслит как вы, но я отдаю себе отчёт, что, скажем, можно нанять "девопса", который знает ноль целых, хрен десятых про айти и линуксы в широком смысле, но он решит 99% проблем разработки, которые сводятся к какой-нибудь банальщине, типа "ошибся с отступами в ямл-файле" и бизнесу будет норм.

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

Оно так, к сожалению, плохо работает. Если полгода разводить срач, то пришедший специалист посмотрит потом на ваши конюшни и скажет:"***тесь сами".

Мне лично кажется, что с нынешним курсом в сторону SaaS/PaaS фокус вообще будет смещаться в сторону того, чтобы вместо найма начинающих/низкоквалифицированных специалистов просто купить готовое.

UFO just landed and posted this here

Во-вторых, вы путаете интеллект и память. Что такое TCP — это ближе к памяти. Уметь решить алгоритмическую задачу — это ближе к какому-то подвижному интеллекту. Хотя, может, кто-то пытается заучить все алгоритмы, хз.

Не путаю, я буквально написал то же самое другими словами в последних 4 абзацах. И да, некоторые прям ставят вопрос так - "мы хотим от кандидата знание вот таких-то алгоритмов". Пришел на собес - расскажи, нарисуй и станцуй.

типчики ковырять.

Вы дисквалифицированы из обсуждения как overqualified. Знание математики выше 5го класса не нужно IT-специалисту /s

UFO just landed and posted this here
Раз в 5 лет написать решение проблемы рюкзака за 8-16 часов вы уж как-нибудь сможете по туториалам с Интернета, а чаще и быстрее вам и не надо.

Не сможете. Потому что вы не знаете, что такое DP, при чем тут рюкзаки и что вообще надо гуглить.


Есть ли в этом практический смысл для работы? Нет.

Есть. Многие, как уже писали выше, даже не понимают, что они квадраты пишут и не замечают проблемы.


Бред ли спрашивать их на собесах? Бред

На собесе вас просят решить какую-нибудь небольшую задачу, чтобы посмотреть, как вы ее будете решать. Смысл именно в этом.

UFO just landed and posted this here
Все эти проблемы

Какие эти проблемы? Вам нужно решить вашу проблему, про которую в интернете ничего не написано.


Если проблемы не видно — значит, ее нет.

Проблему увидят пользователи, но будет поздно.


Проверяя зазубренность алгоритимов

А вы точно программист? Как вы работаете, если не можете осилить пару предложений на родном языке? Я проверяю, как человек решает задачу, а не зазубренность алгоритмов. Именно это написано в комментарии, на который вы отвечали. Я, например, даже код не прошу писать, просто прошу рассказать, что и как он будет делать.

UFO just landed and posted this here
Ваша проблема это частный случай общей проблемы.

Но, чтобы заметить что эта ваша задача — частный случай вот той, разобранной везде, надо про эту разобранную знать! Вот, допустим, у вас задача битстрим h264 порезать на пакеты, не разбивая всякие фрагменты h264 между пакетами (из личной практики). Откуда тут вылезает слово "рюкзак"? А тут ДП вроде рюкзака как раз и применимо.


Т.е. про все эти стандартные задачи надо знать, знать что у них могут быть более эффективные решения, чем полный перебор, нужно уметь свою задачу формализировать. Это уже 80% этих "ненужных программистам алгоритмов".

UFO just landed and posted this here

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

UFO just landed and posted this here

Переформулирую: Есть буфер данных, его надо презать на куски, не превосходящие X. Кусков должно быть как можно меньше, максимальный кусок должен быть как можно меньше. Резать можно только по заданным позициям.

О, у меня на одну вакуху было очень похожее тестовое задание - равномерная разбивка текста на строки с лимитом ширины. Открыл для себя ДП. Эх, где же ты, лето 2016..

Весьма похожая задача, да.

А зачем делать пакет как можно меньше, чтобы лаг уменьшить за счёт времени передачи?

Это требование приходит из pacer'а. Ему маленькими пакетами легче битрейт выдерживать. Ну и задержку поменьше делать тоже хорошо.

Сможем

Как вы можете знать что надо загуглить, если не знаете о существовании проблемы?
Я видел код от адептов "я всегда могу загуглить, мне не нужны алгоритмы" и они писали:
* поиск 3-х максимальных элементов в массиве за O(n log n)через сортировку;
* поиск ноды в дереве по заданному пути (где ребёнка можно получить за O(1) из словаря по имени) за O(n^2) памяти и O(n^2) времени от токенов в пути - сеньор-помидор с 13 лет опыта;
* нужно было в дереве раскрасить ноды; раскраска ноды зависит от цветов детей. Другой сеньор-помидор каждый раз переобходил всё дерево рекурсивно без кэширования. Я исправил только это и прога стала стартовать быстрее на 15 секунд;
* есть кэш на чисто вычисляемое от некоторого класса, кэш хранится в хэшмапе. Зачем-то решили, что будет круто сделать класс ключа без переопределения equals и hashCode. Кэш был, обвязка вокруг него была. Всё равно всё вокруг тормозило. Там же была уверенность, что поиск по значению в хэшмапе тоже O(1).


и таких историй могу ещё принести. Люди не натренировали свой мозг оценивать сложность алгоритмов и писать решения, которые доказано (через инварианты, а не только тесты) работают на всех возможных входных данных.

На самом деле, здесь же истории: давайте долбанём много гигантских switch case потому что я не знаю о существовании паттерна visitor. Не зная о его существовании - невозможно пойти и загуглить его описание. Автор, которые принёс на ревью эти свитчи реально был уверен, что его реализация эффективна.

UFO just landed and posted this here

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

Не уходили они скорее по причине почти полного отсутствия конкурентов, но новые версии запросто могли перестать покупать, если они тормозят.

мне не нужны алгоритмы

К копилку примеров:


  • Ikea при занесении в корзину товаров больше чем 13-15 начинала безумно тормозить. Куда они там умудрились O(n^3) запихать у меня фантазии не хватает
  • enzyme (мега-популярный тест-фреймворк для react от airbnb) умудрились реализовать "обход в ширину" за O(n^2), что страшно негативно сказывалось на не-shallow тестах. Хотя должно было работать мгновенно.
  • какой-то очень популярный jQuery calendar widget адски тормозил на IE6 тупо потому что неадекватно часто перекладывал объекты в объекты посредством Object.assign. Это замедляло то что должно работать за 0.5с до 1мин+.

Человек не понимающий основ не сможет понять, в чём проблема. С какой стороны к ней подходить. По каким словам гуглить. Как проверять результат. У него просто "ну оно тормозит, потому что ему нужно много считать". Многие вообще живут с мантрой "оно там внутри умное, оптимизировано в гугле"… и этим оправдывают лютую дичь в коде.

"оно там внутри умное, оптимизировано в гугле"

У меня про это есть классная история про потроха Андроида версии около 4.1, где какая-то светлая голова  написала что-то вроде Method.equals() = this.toString() == other.toString(). А toString() вместо кеширования значения каждый раз с нуля собирал полное каноническое имя метода: со всеми именами пакетов, всеми возможными квалификаторами и так далее. А, и еще этот equals массово вызывался при работе с рефлексией, в частности, с аннотациями.

В итоге reflection-based парсеры всяких эксемелей генерировали буквально десятки мегабайт мусора в секунду (при лимите памяти в 50 метров на процесс и общем объеме памяти в 512 метров), что делало stop the world GC и ставило раком всё устройство. Код, который на десктопе отрабатывал за 2 секунды, планшет насиловал 2-3 минуты.

P.S. Даже не поленился и нашёл это чудо: https://cs.android.com/android/platform/superproject/+/android-4.1.1_r1:libcore/luni/src/main/java/java/lang/reflect/Method.java;l=382;drc=a0ee76b0850774edeb0c67204070b89d117573bc

Ikea при занесении в корзину товаров больше чем 13-15 начинала безумно тормозить. Куда они там умудрились O(n^3) запихать у меня фантазии не хватает

чтобы на 20 элементах тормозило, O(n^3) не хватит, должно быть что-то экспоненциальное

Если вы 10 лет гоняли на коньках, то у вас будут отличная дыхалка, тренированное сердце и адекватно развитая мускулатура. Отличное преимущество на старте перед конкурентами, которые до этого вообще спортом не занимались.

Преимущество в борьбе с новичками, но гарантированное поражение в конкуренции с теми, кто эти 10 лет занимался бегом.

Так и с литкодом. Условный год на литкоде лучше чем ничего, но хуже, чем год работы над реальными проектами. Думаю, что месяц-другой можно потратить на литкод для общего ознакомления с какими-то азами. Но тратить на него больше времени - это уже лишнее.

Поэтому любой человек щелкающий как орешки алгоритмические задачи — останется тем, кто — умеет алгоритмические задачи. Всё.

Это человек, который обладает развитым алгоритмическим мышлением, умеет писать код, знает структуры данных, когда и как их применять, умеет решать задачи. Что из этого не нужно в программировании?


Поэтому такие задачи при приёме на работу — это бред, только если человек не ищется на позицию, где эти алгоритмы и нужно применять.

Но алгоритмы надо применять почти везде! Не 100% времени, а эпизодически, но вы не можете наперед сказать, что вот тут вот они понадобятся, а вот тут — нет. Вот какой-то знак дорожный встречается редко. Значит ли что в экзамене на ПДД его не должно быть?


Вот мои примеры. Разработка библиотеки webrtc. Даже не кодеки с их математикой, а вот вся эта обертка — засунуть пиксели в энкодер, передать сжатые данные на другой конец, засунуть в декодер. Вот очевидно вам, что там понадобятся:
линейная регрессия, теория чисел, динамическое программирование, moving window max (прямо задачка на литкоде такая есть), фильтр калмана?


Более того, проблема с алгоритмами в том, что почти любая алгоритмическая задача допускает тупое наивное решение. Даже не литкоде многие задачи сформулированы "Дано вот это, сделайте с ним вот это". Казалось бы, что тут решать — ведь в условии сказано, что надо делать. И, не зная алгоритмов, вы даже не задумаетесь, что вот тут оказывается нужны были алгоритмы. Поэтому нельзя, например, нанять в команду отдельного алгоритмиста. Потому что ему придется ревьювить вообще весь код. Продуктивнее требовать знание алгоритмов при найме у всех.


тест проверяет способности человека к решению задач в целом и т.д. и т.п., но тогда и тест должен быть не только из алгоритмических задач

Ладно бы там были математические какие-нибудь задачки. Но тут задачи именно запрограммировать.


но не умею вообще в ООП, то есть я могу написать код на C#, но процедурный. Делает ли это меня плохим программистом

Нет. И любое интервью вы пройдете таким кодом. Более того, почти никто нигде не испольует ООП на таких интервью.


мой брат успешно работает за границей в геймдеве, но он никогда не писал сортировку пузырьком и не знает что такое коды Элиаса XD а я знаю, только у него зарплата в 20 раз больше.

Ключевые слова "за границей". Уверен, что существует человек из вашего региона россии, который выучил алгоритмы и получает в той же стране, что ваш брат, в 2-3 раза больше, работая в гугле.

Ключевые слова "за границей". Уверен, что существует человек из вашего региона россии, который выучил алгоритмы и получает в той же стране, что ваш брат, в 2-3 раза больше, работая в гугле.

Я бы воспринимал исходный пассаж с некой долей сомнения. Геймдев в средним как раз требует больше академических знаний от программиста: поиск путей - это, считай, работа на графах, графоний - векторная алгебра, и так далее.

Геймдев в средним как раз требует больше академических знаний от программиста

Эх…
К сожалению, самый прибыльный геймдев — донатные мобильные помойки, не требует ничего особо. Жаль, что этот рак на самом деле является нынче "средним геймдевом". Для условные три-в-ряд и подобных казуальных игр больше нужны художники и специалисты по агрессивной монетизации.


А ведь геймдев, действительно, раньше был острием высокопроизводительных алгоритмов. Даже если использовать готовый движок надо было понимать всякие тонкости.

UFO just landed and posted this here

А какие вообще тогда вопросы то были, если теоретическая часть вообще была?

UFO just landed and posted this here

И что, даже не было ни одного вопроса, "можно ли тут туда ехать" или что-то вроде "кто вот тут может проехать первым"? Я вот что-то не верю, что не зная ни одного знака можно этот quiz пройти. Наверняка в видео знаки-то мелькали.

UFO just landed and posted this here

Но это все равно не оправдывает тезис "знак X должен быть исключен из экзамена, потому что он редко встречается".

UFO just landed and posted this here

То, что тест простой, не значит, что какие-то знаки там вообще никому не попадаются.

Это человек, который обладает развитым алгоритмическим мышлением, умеет писать код, знает структуры данных, когда и как их применять, умеет решать задачи. Что из этого не нужно в программировании?

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

Но алгоритмы надо применять почти везде! Не 100% времени, а эпизодически, но вы не можете наперед сказать, что вот тут вот они понадобятся, а вот тут — нет. Вот какой-то знак дорожный встречается редко. Значит ли что в экзамене на ПДД его не должно быть?

Да бросьте, я программирую с 1987 года и мне ни разу не понадобилось самому что-то писать (ассемблер на 6502 не в счёт). Всё что нужно давно есть в либах и если у вас не какой-то проект по управлению ядерным реактором на QNX+C, то достаточно написать _sort(A) и всё.

Касательно ПДД - момент в том что 99% как оголтелые изучают разборы дорожных ситуаций читая толстенные книжки. когда проще выучить тонюсенькую книжку ПДД.

Ну а недостающие знания в программировании можно наверстать позже, если они потребуются.

Вот очевидно вам, что там понадобятся:линейная регрессия, теория чисел, динамическое программирование, moving window max (прямо задачка на литкоде такая есть), фильтр калмана?

Вы столько умных слов наговорили, что я в смущении. Я вообще не понимаю что это и мне это никогда не пригодится, как и сам webrtc, я не собираюсь его переписывать или дописывать. С чего же вы решили что человек, которому интересно работать с СУБД вдруг подорвётся программировать кодеки? Даже у программиста так или иначе есть своя специализация. Невозможно знать и уметь всё профессионально, это вне рамок человеческих возможностей.

Более того, проблема с алгоритмами в том, что почти любая алгоритмическая задача допускает тупое наивное решение.

С моей точки зрения полезнее тот программист, который умеет пользоваться стандартными инструментами C# например и не пишет днями и ночами свои реализации алгоритмов, которые потом еще и некому будет поддерживать или модифицировать. Я как-то на гитхабе нашел класс по работе с изображениями определенного формата (вообще на Си две функции code/decode занимали пару экранных страниц), всё было оформлено отлично, но беда, размеры этого класса были страниц на 300.

Продуктивнее требовать знание алгоритмов при найме у всех

Абсолютно непродуктивно, так вы легко отсеиваете тех, кто никакими алгоритмами никогда не занимается, и в них не умеет, зато отлично например пишет что-то другое. Вы себя загоняете в рамки.

У меня в карьере масса примеров когда сообразительный "вася" оказывался лучше, чем дипломированный "федя",и на собеседовании "васю" я приметил как раз задавая простые ничего не значащие вопросы, так скажем - житейские. Начальник был против его найма, но я уговорил. В итоге "вася" сейчас работает за пятерых, я "федя" давно ушел, так как "не видит для себя перспектив".

Но тут задачи именно запрограммировать.

Когда задача типовая, то и решение типовое. Вы проверяете на типовые решения. А в разработке ПО (если конечно вам не нужен "тупой" кодер) нужен творческий подход и задачи не типовые появляются и решение нетиповое нужно искать. Поэтому лучше творческий и сообразительный программист, который в состоянии прочитать что такое O(N) при необходимости, нежели тот, кто кроме O(N) ничего и не знает.

Нет. И любое интервью вы пройдете таким кодом. Более того, почти никто нигде не испольует ООП на таких интервью.

Ну пройду, а как работать в команде буду?

Ключевые слова "за границей". Уверен, что существует человек из вашего региона россии, который выучил алгоритмы и получает в той же стране, что ваш брат, в 2-3 раза больше, работая в гугле.

Ну и пусть получает, видимо он пригодился на своем месте. Вопрос-то в том, что умение в алгоритмы ничего не определяет если вам эти умения некуда применять.

Да бросьте, я программирую с 1987 года и мне ни разу не понадобилось самому что-то писать (ассемблер на 6502 не в счёт). Всё что нужно давно есть в либах и если у вас не какой-то проект по управлению ядерным реактором на QNX+C, то достаточно написать _sort(A) и всё.

Без обид, но если вы с 35 годами опыта работаете за 300 баксов "без знаний алгоритмов" - то это лучшая реклама их учить.

В итоге "вася" сейчас работает за пятерых, я "федя" давно ушел, так как "не видит для себя перспектив".

Если учесть озвученную зп, то Вася работает за пятерых за копейки, а Федя с ненулевой вероятностью может себе позволить нормальные продукты, отпуск, технику и медицину. Так кто из них умнее-то в итоге?

Без обид, но если вы с 35 годами опыта работаете за 300 баксов "без знаний алгоритмов" - то это лучшая реклама их учить.

Чем плох интернет - все думают что жизнь всех людей идёт по возрастающей и абсолютно у всех одинаковая, как в семье так и в карьере. Я нигде не написал что я программист сейчас, нигде не написал что 300 баксов это моя зарплата за программирование. Я вам рассказал о том, что за то время пока я программировал, мне знания алгоритмов никак не пригождались, совсем. И моя максимальная зарплата за карьеру была 2500 баксов в 2008 году, если вы позволите, я вам не стану показывать свою медкарту и объяснять причины, по которым я сегодня рад и 300 баксов, но уверен, что "федя со знанием алгоритмов" в моей ситуации, тоже не остался бы при своих.

Если учесть озвученную зп, то Вася работает за пятерых за копейки

во-первых это было очень давно и за копейки работали оба, только вася работал, а федя страдал и отлынивал, как недооценённое чудо. Мы не знаем что сейчас с васей и с федей, финалы их карьер могут быть самые разные, но за пример взят конкретный момент и полезность конкретного человека с конкретными регалиями.

Я нигде не написал что я программист сейчас, нигде не написал что 300 баксов это моя зарплата за программирование.

То есть вы тут

PS: мой брат успешно работает за границей в геймдеве, но он никогда не писал сортировку пузырьком и не знает что такое коды Элиаса XD а я знаю, только у него зарплата в 20 раз больше.

сознательно умолчали о важной детали, которая нивелирует всё сравнение, и тем самым попытались ввести всех в заблуждение? Ну, у вас получилось, чем вы недовольны?

сознательно умолчали о важной детали

и в чем её важность? я озвучил своё мнение о том, что НЕзнание алгоритмов не мешает карьере программиста, как и знание алгоритмов. То что вы прямы как лом в чтении по диагонали - я не виноват.

Очевидно в том, что вы использовали это сравнение для подтверждения своего тезиса, при этом сравнение было абсолютно некорректно, а значит, не может подтверждать тезис.

Давайте я тоже сейчас скажу, что НЕзнание анатомии не мешает карьере хирурга, потому что мой знакомый учился, а я балду пинал, а теперь получаю в 20 раз больше него, умолчав, что учились мы на разных специальностях, и я вообще не врач (да и он тоже, так-то, я его придумал).

Маленький нюанс, как говорится.

Ну нет. Ваш комментарий можно было интерпретировать только так. Зачем вы вообще про свою зарплату что-то сказали, если вы не программированием занимаетесь, да и маленькая она у вас по причинам вообще никак к заниням алгоритмов не относящейся?

То есть я зная алгоритмы и теоретически (с ваших слов) обязательно должен получать больше, но сознательно отказался от этого в пользу другой работы? Что-то не сходится.

В смысле? Не обязательно, конечно. Индивидуальные обстоятельства индивидуальны. Но имея больше знаний, у вас больше возможностей. Да, банально, интервью в фаанги зная алгоритмы пройти легче.

Так мой изначальный пост как раз об этом. Больше половины ответивших мне почти дословно пытаясь мне доказать необходимость знания алгоритмов в итоге пишут ту же самую мысль что озвучиваю и я. Всё же знание алгоритмов не помогает вам читать и понимать написанное :) Если вам всё же непонятно разберу ваши же слова:

Индивидуальные обстоятельства индивидуальны

Абсолютно верно, именно поэтому нет никакой прямой зависимости от знаний алгоритмов и уровня оплаты труда.

Но имея больше знаний, у вас больше возможностей

Несомненно, но возможность нужно уметь реализовать. То есть мы опять упираемся в тезис выше по тексту - ваши возможности никак не влияют на ваш уровень дохода напрямую. Скажу чуть больше - нужно так же уметь выбирать работу на перспективу, это тоже серьезный скилл и неправильно выбранная работа сегодня, пусть и с хорошим доходом, может привести вас к потере времени, а возможно и утрате веры в себя, когда крах проекта из-за горе-стартаппера, вы почему-то примете на свой счёт и просто уйдя в жёсткую депрессию уничтожите себя как специалиста. Рассуждать так можно бесконечно ибо "индивидуальные обстоятельства индивидуальны".

Да, банально, интервью в фаанги зная алгоритмы пройти легче

Мы говорим о всех людях сразу, о всех индивидуальных обстоятельствах сразу, мои слова охватывают всё множество возможных программистов на планете и со всеми уровнями скиллов. А вы загоняете разговор в какие-то конкретные рамки. Хорошо, давайте сведём в одну таблицу общее число ИТ специалистов, общее число программистов в них, общее число программистов знающих алгоритмы хоть немного, общее число программистов знающих алгоритмы весьма профессионально и основательно и общее число программистов проходящих тесты фаанг (я не знаю что такое фаанг, поэтому пишу повторяя за вами).

У меня нет таких чисел, но интуитивно я уверен что последние две позиции весьма малочисленны, но так как ни вы ни автор статьи даже не пытаетесь в разговоре обозначать весьма малочисленную группу людей, а оперируете общими значениями всех-всех-всех программистов, то и мои комментарии будут с вами несогласны.

Надеюсь мой комментарий достаточно фактологичен, рационален и понятен?

Абсолютно верно, именно поэтому нет никакой прямой зависимости от знаний алгоритмов и уровня оплаты труда.

Нет. Каждый конкретный мужчина имеет свои шансы найти себе жену, но высоким это удается гораздо легче. Несмотря на индивидуальные истории великанов-красавцев-одиночек и карликов-любимцев-всех-девушек, тут есть зависимость.


ваши возможности никак не влияют на ваш уровень дохода напрямую.

Ну перечитайте это ваше утверждение! Мне оно кажется очевидно ложным. Как возможности могут не влиять на уровень дохода?

но высоким это удается гораздо легче

давно подмечено что высокие мужчины и женщины чаще закомплексованы и находят себе в пару не человека мечты, а того кто придётся, поэтому пары для обоих гендеров выглядят как высокий + мелкий дрыщ. Пардон что не смогу привести пруф в виде статьи, читал об этом давно и не знал что придется её цитировать.

Ну и вопрос - как это связано с нашим разговором?

Как возможности могут не влиять на уровень дохода?

Потому что сами по себе возможности это статичное состояние, а вот реализация этих возможностей - это уравнение на X переменных. Сложность именно в их реализации, так как часто просто абсурдная ситуация - человек не осознает что имеет какую-то возможность.

Как пример - на вещевых рынках в 90-е был минимум людей с высшим образованием, так же как сегодня малый бизнес состоит преимущественно из людей с базовым образованием. Так как например я не знаю как я могу продать свои знания теории относительности или умение программировать МК, а они не обременены такими терзаниями и муками выбора, они сдают металл оптом, участвуют в гостендерах, гоняют бригады из таджиков на ремонт кровли, вот так и живут на свой 1%. то есть они не только умеют реализовать то что им дано природой, но и способны найти возможности там, где их, казалось бы, и вовсе нет.

Поэтому сам факт знания алгоритмов ни на что не влияет, это просто факт. Если так не понятно, можно придумать миллион примеров, например факт наличия у меня двух удочек и спиннинга тоже никак не влияет на мои доходы, потому что я не рассматриваю даже их как средство для заработка. Ну или так - если ко мне придёт человек и скажет - пойдем к нам работать, будешь применять свои знания программирования МК, зарплата 10000 зеленых - я откажусь, так как я не хочу этим заниматься совсем (как показывает практика, то что интересно мне в МК вообще не продаётся, так как у бизнеса совсем другие запросы, в свою очередь то что бизнес продаёт и за что был бы мне готов заплатить, я вообще не рассматриваю как работу). То есть наличие возможности никак не меняет доход, её обязательно нужно уметь/хотеть реализовать. Если вы в своей жизни руководствуетесь сугубо тем что вы всегда хотите всё что бы вам не предложили (лишь бы платили) и вы считаете что все на планете обязательно видят возможности и априори их умеют применять - то вы уникум.

Например я очень хороший оратор и в жизни много говорю (и пишу, вы наверное заметили), но я и говорю и пишу только когда мне это действительно хочется. Поэтому например я никогда не читаю лекций и не веду занятия дольше короткой фазы с одной группой, так как я не могу повторять одно и то же годами или в неделю прочитать одну и ту же лекцию 4 группам например в разные дни - я лучше застрелюсь. Поэтому я и не состоялся как программист-работник, я не хочу программировать кому-то что-то мне неинтересное. А то что интересно мне - я не умею продавать.

я программирую с 1987 года и мне ни разу не понадобилось самому что-то писать

Т.е. вам за всё время не пригодился ни LRU, ни binary search, ни обхода графа в ширину, ни каких-нибудь очередей, никаких DSL, никаких интерпретаторов, сложных парсеров? Чем вы занимались эти 35 лет?


"федя" давно ушел, так как "не видит для себя перспектив".

"Федя хорош. Будьте как Федя". Если в вашей конторе в месяц платят столько сколько на фрилансе платят за 3ч, странно что Федю к вам вообще занесло.

Т.е. вам за всё время не пригодился ни LRU

даже не представляю что это

ни binary search

кажется пользовался таким в 90-е из какой-то стандартной либы

ни обхода графа в ширину

Про графы знаю только то, что они есть, а что это и как работает - представления не имею. Возможно какая из функций стандартных либ и использует их, но я не имею привычки изучать внутренности чужого кода.

ни каких-нибудь очередей

Писал двунаправленную очередь на ASM 8088 на лабораторной году в 1993, больше никогда не пользовался (за исключением каких-то стандартных списков TList или чего-то подобного на их основе, я знаю что это не LIFO/FIFO, я в целом о потребностях).

никаких DSL

Не представляю что это

никаких интерпретаторов

BASIC, если вы о чем-то другом, то я не в курсе

сложных парсеров

делал как-то разбор JSON на awk стандартными средствами, делал разбор xml на Си, но это под конкретную узкую задачу, по принципу "посчитал и выкинул"

Чем вы занимались эти 35 лет?

Очевидно что всем чем угодно, но только не перечисленным вами.

Встречный вопрос - с чего вы взяли, что вами перечисленное используется всеми программистами мира во всех задачах? Я ни когда не писал ничего для обработки сигналов, потоков видео, tcp/udp и т.д. и т.п. Я вообще не представляю как с такими вещами работать и какие там технологии, библиотеки, фреймворки, железо и т.п. И почему собственно я обязательно должен всё это знать? Потому что кто-то в интернета так считает?

Если в вашей конторе в месяц платят столько сколько на фрилансе платят за 3ч, странно что Федю к вам вообще занесло

Вы путаете палец и сами знаете что. Если Федя не способен решить простую задачу, то и сложную он не решит и вопрос тут не в деньгах. Федю к нам занесло как студента-отличника, он хотел набраться опыта, прошел собеседование, но не прошел проверку временем. Тут опять же скорее всего эффект регионального вуза, я за Москву вообще говорить не стану, возможно там ситуация с отличниками и медалистами как-то отличается, но думаю не сильно, так как олимпиады и реальность вообще никак не пересекаются.

Уж не знаю насколько хороший пример, но я был круглым отличником с 3 по 5 курс, диплом на 5. НО!!!! И ЭТО ВАЖНО! Я самокритичен и я знаю каковы реально мои знания и умения, я себя оцениваю на 2-3 балла. А отличником я был, потому что получение оценки 5 вообще никак не связано со знаниями и умениями. Мы были "переселенцами из республик" и для меня была важна повышенная стипендия, я смог её получить, просто за первые курсы я понял как работает система и "хакнул" её. Преподаватели - это просто люди, и если ты всё делаешь по их шаблону отличника, то 5 тебе гарантировано. Была только одна преподавательница по менеджменту, которая проверяла именно знания, но это был один экзамен - согласитесь, выучить один предмет не составит труда, когда остальные у тебя на 80% стоят автоматом. И я нигде и никогда не скажу, что я великий программист, ну или хотя бы синьор или лид, я порой даже на джуниора не гожусь, но, отмечаю еще раз, в статье указываются просто программисты, нигде не указан какого уровня, с каким дипломом и какими навыками и, как для вас не парадоксально, я тоже попадаю в число программистов.

Поэтому если где-то есть программист которому алгоритмы нужны ежесекундно, то всегда найдется такой, которому они не понадобятся никогда в жизни. Это неоспоримый факт. И уж если вы себя считаете умным, то спорить с ним ГЛУПО.

Встречный вопрос — с чего вы взяли, что вами перечисленное используется всеми программистами мира во всех задачах?

Ну почему же. Есть ведь программисты которым нельзя поручить ничего кроме перекладывания JSON-а. А есть те кто пишут либы, занимается архитектурой сложных приложений, занимаются оптимизацией, ну и т.д… Не очень понимаю, почему первые считают себя программистами. Но коли им так нравится, пусть.


олимпиады и реальность вообще никак не пересекаются.

Про графы знаю только то, что они есть, а что это и как работает — представления не имею.

Ох. Графы и Олимпиады…


Нет, серьёзно, человек который за 35 лет не познал графов и связывающий их с олимпиадами рассказывает нам истории о Федях, которые не смогли в разработку. Это какой-то фарс.


Даже перекладывание вложенных JSON-чиков это уже графы. Условно получили вы откуда-нибудь структуру вида:


{ 
  "users": { 
    "123": { 
       "name": "Fedya", 
       "userGroup": { "id": 321, "name": "Admins" } 
    }
  }
}

и хотите нормализовать её в:


{ 
  "users": { "123": { "name": "Fedya", "userGroupId": 321 }, 
  "userGroups": { "321": { "name": "Admins" } }
}

Это уже обход графа. Графы окружают нас везде. И немалая часть нашей работы заключается в различных фильтрациях, трансформациях, поисках и пр. по графам.


Даже вот это древо комментариев, которые вы сейчас читаете, это алгоритмы на графах. Их, как минимум, нужно выгрузить из базы, и привести в удобоваримое для рендера вида. А потом ещё и частичные апдейты таргетно подгружать.


Пожалуйста, не надо больше историй про Федь, олимпиадников и медалистов.

Не очень понимаю, почему первые считают себя программистами. Но коли им так нравится, пусть

Я давно уже понял что профессиональный шовинизм это ярко-выраженная черта на хабре, но делает ли это вам чести и заслуживает ли рассмотрения?

не познал графов и связывающий их с олимпиадами

И вот как на вас в принципе реагировать? Вы себя считаете самым умным, выпячиваете своё превосходство и при этом не в состоянии читать и понимать собеседников, а сейчас вообще скатились до вранья. Где я графы связал с олимпиадами? Вы написали о графах, я ответил что не в курсе что это. Всё.

рассказывает нам истории о Федях, которые не смогли в разработку

В какую разработку? Где вы такое вычитали? Вы живёте в своем выдуманном мире, научитесь читать и адекватно вести беседу.

Это уже обход графа. Графы окружают нас везде

Ну и славно, как это связано с тем что незнание алгоритмов (или знание) на что-то явно влияет?

Вот я ничего не знаю про графы и вполне успешно пишу софт когда мне это требуется, не вижу связи.

И немалая часть нашей работы заключается в различных фильтрациях, трансформациях, поисках и пр. по графам.

Я рад за вас и вашу работу где так много всего интересного, только к разговору это не относится.

Пожалуйста, не надо больше историй про Федь, олимпиадников и медалистов.

При всём богатстве своего ума вы совсем не умеете в аналогии, не умеете читать написанное и не вникаете в суть беседы. Эгоцентризм в высшей стадии.

Я давно уже понял что профессиональный шовинизм это ярко-выраженная черта на хабре

… но зачем-то продолжаю приходить к этим шовинистам и просвещать их. Паладин.


и вполне успешно пишу софт когда мне это требуется

Важное уточнение: по вашему собственному мнению.


Эгоцентризм в высшей стадии

Аминь. Медальку мне.

но зачем-то продолжаю приходить к этим шовинистам и просвещать их

Я не к вам пришёл и не к шовинистам и я не сказал что тут только шовинисты. С чтением и логикой у вас плохо.

Важное уточнение: по вашему собственному мнению

А все мнения - чьи-то собственные, ваше тоже, автора статьи и оно ничем не отличается от моего, поэтому не нужно себе приписывать уникальность и безапелляционность.

Аминь. Медальку мне

За что? Ну разве что медаль "Шовинист первой степени"

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

Не верю. Как можно зарабатывать медали и при этом: не уметь решать задачи, не уметь писать код и алгоритмически мыслить? Техника программирования внесением случайных изменений в код и проверкой результата слишком неэффективна, чтобы на олимпиадах что-то там получать. Ваше утверждение звучит как "сколько олимпийских спортсменов по легкой атлетике не встречал, никто на 3-ий этаж по лестнице без одышки поднятся не может".


я программирую с 1987 года и мне ни разу не понадобилось самому что-то писать

Во-первых, вы, не зная алгоритмов, скорее всего даже просто не заметили, что где-то можно на порядки ускорить ваши программы, применив "алгоритм". Во-вторых, эти самые алгоритмы на практике часто не про написать структуру данных с нуля, а допереть, что вот тут вместо списка можно в hash_map вот те штуки сложить, а вот тут надо вызвать next_permutation из стандартной библиотеки. Так что даже если и совсем редко требуется писать "что-то самому", знать алгоритмы надо, что бы понять, что из стандартной библиотеки и когда применять.


Я вообще не понимаю что это и мне это никогда не пригодится, как и сам webrtc, я не собираюсь его переписывать или дописывать.

А мне надо. Я работаю в гугле и этот самый webrtc пишу. Но смысл моего текста не в том, что нужно конкретно мне на конкретно этом проекте, а в том, насколько обширно и неожиданно вылезают алгоритмы. Ну вот как "взять видео с камеры, передать библиотеке-кодеку, распилить на пакеты" может быть связанно с линейными регрессиями и динамическим программированием? Но вот вылезает оно как-то.

У меня в карьере масса примеров когда сообразительный "вася" оказывался
лучше, чем дипломированный "федя",и на собеседовании "васю" я приметил
как раз задавая простые ничего не значащие вопросы, так скажем -
житейские. Начальник был против его найма, но я уговорил. В итоге "вася"
сейчас работает за пятерых, я "федя" давно ушел, так как "не видит для
себя перспектив".

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

PS: мой брат успешно работает за границей в геймдеве, но он никогда не
писал сортировку пузырьком и не знает что такое коды Элиаса XD а я знаю,
только у него зарплата в 20 раз больше.

20 раз? Урежте осетра.

у меня $300, у него $6000 - что не так?

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

А вот если вы пойдёте на более-менее стандартную роль, то вас на интервью завернут и правильно сделают.

В целом согласен, но некоторые пассажи вызывают недоумение:

А как мы знаем, хороший код - это код, который может понять даже начинающий разработчик.

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

Вы настраиваете валидацию, смотрите примеры данных в базе, смотрите бизнес-правила, и понимаете, что в условную функцию может прийти какой-то узкий набор данных предсказуемой длины.

очень точно подмечено, но

И чаще всего не имеет значение, обработаются эти данные  O(1), O(N) или O(N*N) и так далее.

Этот как вообще? Не важно, обработаются данные быстро или медленно?

Если спросить программистов, что пишут бизнес-логику приложений, то не так уж много задач, где сложность той или иной функции, как-то влияла на пользовательский опыт юзера софта. Они есть, но их ничтожно мало в современных реалиях доступного железа.

Это те самые прекрасные люди из-за которых word 365 на i7 работает с той же скоростью, что и word xp на core 2 duo, который в свою очередь работает с той же скоростью, что и word 95 на первом пне? Единственный вопрос который можно им задать, это: "Как вам спится по ночам? Бесцельно сожжённые мегаватт*часы во снах не приходят?"

Однако, если мы обратимся к опытным программистам и it-архитекторам, то они явно скажут вам, что решение задач на leetcode не сделает из вас хорошего программиста

Сами по себе не сделают, но кое-чему научат. Это я вам как опытный программист скажу явно.

> И чаще всего не имеет значение, обработаются эти данные  O(1), O(N) или O(N*N) и так далее.

Этот как вообще? Не важно, обработаются данные быстро или медленно?

Речь идёт о случаях, когда для ожидаемого объема данных асимптотика не дает сколь-нибудь заметной разницы во времени ответа от приложения. Например, когда приложение вытаскивает данные по REST API за 100мс, а затем обрабатывает их за 2мс или 1мс в зависимости от алгоритмических навыков программиста.

Лично мой взгляд - алгоритмические задачи слабо связаны с реальной практикой разработки. У меня 15 лет опыта, работал в телекоме, автопроме, финтехе, сейчас в одной из букв FAANG. Алгоритмические задачи я нахожу чудовищно скучными и никогда не решаю их вне подготовки к интервью. Когда готовлюсь, каждый раз отмечаю, что мой рабочий опыт помогает в лучшем случае в половине задач сложности Medium, и почти никогда в задачах Hard. Для меня это иллюстрация того, что эти задачи - вещь в себе. Чтобы их успешно решать, нужно выучить ряд приёмов, которые скорее всего вы никогда не встретите за пределами Leetcode.

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

Из моего опыта:

1) на собеседованиях в Г чаще можно встретить Литкод Хард чем например в Амазон

2) в Амазоне вопросы явно с Литкода брать не рекомендуется, но многим влом думать-искать

3) все проблемы которые были у меня в вопросах на интервью в Амазоне встретились впоследствии в реальной работе

4) непосредственно навык скоростного решения таких проблем - не нужен. Но нужно уметь быстро писать хороший и тестируемый код и быстро распознавать алгоритмические паттерны, чтобы не велосипедить и не плодить тормозной код.

На самом деле это только часть навыков software engineer, и эффективность принятого формата интервью - вопрос спорный, но... Как то работает, а лучшего способа не придумали. "Гитхаб" и "поговорить за проекты" для бигтеха очевидно не вариант.

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

Существует ли зависимость между типом себеседования и возможностью для саморазвития я не знаю, думаю что если есть, то не очень сильная.

Весь оутсорс, где алгоритмических задачек почти ее бывает, я для себя закрыл. Один раз попробовал, было очень полезно, но больше не хочу. А вот в продуктовых команиях задачки втсречаются.

Простите за странный комментарий,
а сейчас россиян вообще рассматривают в разные Фаанги?

Уточнение - если да, то какого уровня я должен быть?
То есть они чаще берут на позицию Джуниор или выше?

Рассматривают, им пофиг.

Джуниор вряд-ли, миддл тоже под сомнением. Есть иногда интернские позиции, но больше для местных студентов.

Чтобы пройти интервью нужно уметь хорошо в алгоритмы, структуры данных и системный дизайн.

Хотя даже фаанг иногда не верх адовости интервью - я последний раз когда менял работу прошёл в одной компании раунд из 8 собеседовний, кажется. Но и платят они почти как фаанг, и кешем, без стоков.

то есть фаанги берут выше мидла?

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

8? хм. Я прошёл (по отзывам — отлично) отборных 4 собеса, в том числе пара алгоритмических и архитектурное, а потом 10 финалов с разными командами. Поскольку не собеседовался до этого я примерно лет 8, мне был интересен и процесс, и прокачка скилла собеса.
По итогу финалов мне предложили на выбор 4 команды, но итоговый оффёр сильно меньше моего озвученного минимума, и не превышал текущего уровня. Когда я хмыкнул и отказался, начались заходы «а давайте ещё поговорим», но мне было уже не интересно.

Как ни крути, но проработка этих задач точно не будет лишней при собесе в фанги-манги. Мне заниматься такой деятельностью в свободное время совсем не интересно (хватает работы), но если надумаю пойти в место, где будут очень много платить, задумаюсь о штудировании литкода.

У меня было примерно такое же мнение (нафига оно мне, за 17 лет не пригодилось особо, всё есть в стандартной библиотеке, ...)

Потом, когда начал мучать литкод - втянулся. Реально затягивает, ну и начинаешь понимать как работают те или иные вещи, которые принимал как данность (те же OSPF с Дейкстрой, сортировки, хипы и прочие LRU)

С женой до сих пор решаем периодически, соревнуемся кто быстрее осилит 😀

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


Что касается основной работы, компилятора Котлина, то в нем изредка попадаются алгоритмические задачи, но по ощущениям у меня чаще возникают проблемы из-за софт-скиллов, когда не достаточно коммуницирую с другими членам команды, делаю лишнее или не совсем то. Что касается хард-скиллов, то нужно уметь быстро понимать что делает код, искать баги, извлекать минимальные примеры.

Польза есть на начальном этапе, когда ты изучаешь профессию, просто что-бы знать что там "под капотом", а не тупо, в режиме мартышки, дергать за рычаги всевозможных фреймворков, удивляясь потом, почему оно работает так медленно либо вовсе падает по памяти.

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

Говорят, что платным аккаунтам на Leetcode как-то дают пощупать задачки с прицелом на определённых работодателей, но как именно это работает не знаю.

LeetCode знает, какие задачи спрашивают на интервью в тех или иных компаниях. За деньги он делится этой информацией с вами.

На платном аккаунте:


  1. Доступны все солюшены.
  2. Даже для "бесплатных" задач (коих большинство) указано в каких компаниях они попадались на собесах.
  3. Задач больше, есть "платные задачи".
  4. Списки задач можно отфильтровать по компаниям.
  5. Режим "интервью" можно потренировать по задачам конкретной компании.
  6. Меньше стоишь в очереди при отправке решения.

Но, понятное дело, все эти списки они весьма условные. никто ничего не гарантирует, что вам попадется задача из списка.

Понятно, спасибо. Я просто видел посты "Заведите платный аккаунт на Leetcode, сможете посмотреть подборку задач, которые спрашивают на собеседовании в Google" в англоязычном интернете, но вот варианты реализации этого всего могут быть разные.

Платный аккаунт даст только подборки, их в ощем и так по коментам можно вытащить. А рещать всё равно вам. Решения от литкода с объяснениями могут быть скрыты за оплатой, но там можно пойти в секцию решений пользователей и найти много интересного.

Очень странная статья, похоже описана работа программиста недоучки. Что-то в описании решения задач слабо прослеживается формализация, математическое моделирование, алгоритмические модели, применимости в технологическом процессе. В основном, ищем в гугле, ютубе, лопатим литературу, так и хочется задать вопрос, а до этого полноценно обучиться не судьбы?

А почему нет варианта — принудительно заставляли в институте? А в институте программа обучения на программиста одними алгоритмами внезапно не ограничивается.

А как устроиться на работу в FAANG?

Теперь уже никак. Только в MAANG!

Полезно. Плюсы:

  • Узнал про интересные алгоритмы

  • Изучил синтаксис и основные типы нового для себя языка (Rust)

  • Научился быстро придумывать и реализовывать решение задачи, проговаривая свои действия

  • Привильные решения и их скорость (быстрее 100%, ~0 мс) приносят большое удовлетворение

  • Как результат - устроился в "M" из т. н. MANGA

Минусы

  • На новом проекте не применяю все эти изученные алгоритмы. Большинство их быстро забыл

  • На работе не программирую на Rust

В былые времена помню читали
Никлаус Вирт: Алгоритмы и структуры данных
Дональд Кнут: Искусство программирования, 4 тома

Интересно, как они теперь в сравнении с книгами из статьи.

Каким бы профессиональным программистом вы не были, если вам дать случайную задачу уровня middle+ из Leetcode, то вы с большой вероятностью не сможете решить её эффективным способом.

Middle, блин? Мне стыдно, но у меня даже одна easy со скрипом пролезла. И здесь я согласен с некоторыми из участников Leetcode, которые, например, пишут
LeetCoder_Hashmap: I must admit, this «easy» problem confused the hell out of me :) I had hard problems solved like a breeze, but this one… gush :)

Я за сложные не берусь пока, но некоторые задачи среднего уровня действительно для меня оказываются легче, чем простые.

«Алгоритмы — Руководство по разработке» — Стивена Скиена.
Книга тяжко читается даже на русском. Возможно, потому что я старый и бестолковый :)

А ещё у меня сложилось впечатление, что некоторым из участников Leetcode незнакомо слово «отладка».

P.S. И «писькомер» (пардон) там странный. Можно засабмиттить один и тот же код и получить сильно разные показатели на графиках.

P.S. И «писькомер» (пардон) там странный. Можно засабмиттить один и тот же код и получить сильно разные показатели на графиках.

Вы видели разницу в скорости? 1 мс или 100кб в памяти дают огромный орыв. Я, конечно, не гуру, но кажется, что это вообще в пределах погрешности и время выполнения зависит от фаз луны. Решения в 0мс вызывают легкое недоумение. Буду рад, если кто-нибудь объяснит подобное поведение.

Вы видели разницу в скорости? 1 мс или 100кб в памяти дают огромный орыв. Я, конечно, не гуру, но кажется, что это вообще в пределах погрешности и время выполнения зависит от фаз луны.

Смотрите, у меня 2 одинаковых сабмита на C#:
1. 96ms - beats 77,87% / 49,3Mb - beats 53,85%
2. 124ms - beats 13,38% / 39,5Mb - beats 90,37%
Total time range: 68ms - 171ms
Total memory range: 36.6Mb - 51Mb

Во-первых, видеть разницу 13,38% супротив 77,87% — уже само по себе удивляет и удручает. Во-вторых, разница между 96мс и 124мс, может, и находится в рамках погрешности, но она составляет почти 30%. Ну, и десяток мегабайт (20%) — тоже не абы что. В-третьих, учитывая ширину диапазонов, можно вообще предположить, что все решения примерно одинаково эффективны. Какой смысл тогда в этих графиках? Лишь сбивают с толку.

Решения в 0мс вызывают легкое недоумение. Буду рад, если кто-нибудь объяснит подобное поведение.

Если пофантазировать, то можно предположить, что определённого рода задачи (математические, например) можно решить парочкой операций, а можно какой-нибудь долгой рекурсией. Например, число фибоначчи. Возможно, пример не самый удачный, но в качестве иллюстрации, думаю, годится.

Сомневаюсь, что литкод гоняет тесты на действительно больших данных, где была бы заметна разница в скорости работы и замер скорости был бы более точен.

Во-первых, видеть разницу 13,38% супротив 77,87% — уже само по себе удивляет и удручает. Во-вторых, разница между 96мс и 124мс, может, и находится в рамках погрешности, но она составляет почти 30%.

Так я о том же. Не могу ничего о c# сказать, но, скажем для java - 20мб это ниочем. Т.е. Во время первого запуска может gc запуститься, а на втором нет. Разница в коде будет показательна на большом объеме данных, но сомневаюсь, что leetcode позволят забить пол гектара озу. Поэтому статистика, на мой взгляд так, для галочки.

Я на плюсах решения посылал и у меня замена int на size_t "дало" ускорение на 20%. Не, ну это не серьёзно.

Если пофантазировать, то можно предположить, что определённого рода задачи (математические, например) можно решить парочкой операций, а можно какой-нибудь долгой рекурсией. Например, число фибоначчи. Возможно, пример не самый удачный, но в качестве иллюстрации, думаю, годится.

Убрал пару лиших переменных, нигде не использующихся и моё решение выполнилось за 0мс. Чудеса.

Only those users with full accounts are able to leave comments. Log in, please.

Articles