Пожалуй каждый программист, который сталкивался с вопросом: "А как устроиться на работу в FAANG?" - получал ответ, что ему нужно разобраться с алгоритмами, со структурами данных и прорешать порядка 300-400 задач на leetcode по алгоритмам.
Однако вслед за этим советом тут же появляются люди, которые говорят, что это никоим образом не делает тебя лучше, как программиста. Да и вообще - просто пустая трата времени.
Поэтому, в этой статье я постараюсь дать ответ, насколько это может быть полезным для работы и развития, и как может сказаться на карьере.
Как обычно приступают к изучению алгоритмов
Каким бы профессиональным программистом вы не были, если вам дать случайную задачу уровня middle+ из Leetcode, то вы с большой вероятностью не сможете решить её эффективным способом. И эта ситуация обуславливается не тем, что вы слабый программист, а тем что для решения подобных задач нужно набить руку и познакомиться с определёнными понятиями и приемами.
Чаще всего советуют начать с двух книг, которые помогут познакомиться с базовыми понятиями и настроить свою голову на нужный образ мышления:
"Алгоритмы - Руководство по разработке" - Стивена Скиена.
"Карьера программиста (Cracking the coding interview)" - ЛакманМакДауэлл.
И если первая книга, как говорит сам автор, является учебником по базовому курсу по введению в алгоритмы, который разбавлен примерами из жизни, где автор описывает пользу от применения того или иного алгоритма, то вторая является фактически руководством по тому, как нужно вести себя на алгоритмических интервью, и как решать базовые типы задач, что вам могут попасться.
Так же, если у вас нет хорошего бекграунда (например, профильного университета), то неплохо бы ознакомиться с базовым computer science перед тем, как начинать читать книги по алгоритмам. Для этого так же есть неплохая книга, которую я могу вам рекомендовать:
"Гид по Computer Science" - Вильям Спрингер
И вот после того, как вы прочитали 2-3 книги, которые могут у вас занять порядка 3-4 месяцев, можно приступать к решению задач на Leetcode.
Как правило, нет смысла просто открывать список задач и начинать их решать подряд, рекомендуется открывать либо специальные подборки от самого Литкода, либо от ребят, которые их составили на основе опыта интервью в FAANG (например, от автора Neetcode - https://neetcode.io/practice)
Как выглядит процесс решения каждой алгоритмической задачи
1) Открывается задача - читается описание. Нужно понимать, что далеко не всегда задача поставлена очевидно. Чем выше номер задачи, тем более синтетической может оказаться ситуация. Поэтому, если не получается понять, что же от нас требуется - прибегаем к помощи гугла и Youtube.
2) Пытаемся решить задачу наиболее прямолинейным способом. Этот шаг нужен для того, чтобы подтвердить понимание задачи, поймать пограничные кейсы, упереться в timelimit, и получить решение, если оно возможно таким способом.
3) После этого нужно задать вопрос: "А можно ли сделать решение более эффективным?" Если ничего на ум не приходит, то сначала следует открыть подсказки внизу каждой задачи литкода. Там, как правило, проставлены теги по тем приемам, которые можно использовать (Два указателя, Бинарный поиск, Битовые операции и так далее). Это отличная возможность, чтобы загуглить данные приемы и познакомиться с тем, как их следует использовать, и на каких типах задач они помогают. Например, есть неплохой канал с объяснениями - https://www.youtube.com/@WilliamFiset-videos/videos
4) Если и после этого ничего не приходит в голову, то либо открываем официальное решение (если у вас есть премиум, либо смотрим пользовательские решения, либо ищем инструкцию на Youtube по данной задаче). Как правило, если вы до этого не решали задачи на Leetcode, то вы можете обнаружить настоящую магию, как например, описали в этой статье - Трюк с XOR для собеседований и не только.
5) После этого нужно обязательно ручками написать решение, убедиться, что оно работает и занести это решение в какой-то свой справочник. Алгоритмические задачи по большей части достаточно синтетические, поэтому их сложно держать в голове, поэтому нужно обязательно записывать.
И как правило, решение одной задачи без подготовки, знакомство с приёмами, знакомство с другими решениями и подходами - занимает порядка 2 часов. После того, как появляется опыт и знакомство с приемами, решение подобных задач занимает гораздо меньше времени.
Что дает нам решение задач от LeetСode?
После того, как мы ознакомились с тем, как идет подготовка к решению задач на Leetcode (долго) и как проходит решение каждой задачи (долго), давайте подумаем, что мы получим за свои труды:
1) Мы проходим базовый курс по алгоритмам и структурам данных.Пониманием, что не всегда задачи ограничиваются парсингом JSON и складыванием его в ту или иную базу данных. Многие типы задач, которые вы думали, что невозможно решить как-то просто, на самом деле решаются достаточно элементарными способами. Мы понимаем, что для некоторых задач уже созданы специальные алгоритмы, которые можно загуглить и применить. Однако если бы вы не прочитали книги и не прорешали задачи, то вы бы не понимали что нужно гуглить.
2) Мы знакомимся с определенными приемами, которые можно использовать в своей работе, если нужно сделать решение более эффективным. Те самые два указателя, бинарный поиск, поиск в ширину, поиск в глубину и так далее. Плюс мы не просто с ними знакомимся, но и набиваем руку при решении задач.
3) Мы учимся видеть сложность того или иного куска кода, что помогает нам в работе писать более эффективные решения. Думаю работодатель с хайлоад-проекта будет сильно этому рад.
4) Мы доказываем себе и потенциальным работодателям, что мы не легкомысленно относимся к работе, если нам хватило усидчивости, чтобы пройти через три учебника и несколько сотен задач, которые нагревают нашу голову и заставляют усиленно тратить мыслетопливо.
5) Пройти собеседование в компанию, которая требует от вас алгоритмы и получить работу мечты. Если у вас, конечно, есть такая цель.
Применим ли подход с Leetcode в настоящей работе?
1) Внезапно, но самое эффективное решение не всегда оказывается самым читаемым. Например, в ряде решений использовался такой код, который бы точно не прошел ревью. Следующий программист, что получил этот код, потратил бы значительное время, чтобы понять, что он там по итогу делает. А как мы знаем, хороший код - это код, который может понять даже начинающий разработчик.
2) Как правило, в работе не нужны все алгоритмы, нужна какая-то узкая область, которая осваивается при знакомстве с проектом. Поэтому, большая часть информации, что была выучена в течение курса решения Leetcode уйдет глубоко подкорку, либо совсем выветрится из головы. Поэтому так важно записывать все решения задач, что вы сделали, так как уже буквально через пару месяцев вы их вряд ли вспомните.
3) Так же, как Ливерпуль никогда не останется один, так же и задачи никогда не приходят без контекста. Как правило, вам не нужно готовить свое решение для какого-то непредсказуемого набора данных. Вы настраиваете валидацию, смотрите примеры данных в базе, смотрите бизнес-правила, и понимаете, что в условную функцию может прийти какой-то узкий набор данных предсказуемой длины. И чаще всего не имеет значение, обработаются эти данные O(1), O(N) или O(N*N) и так далее.
4) Если спросить программистов, что пишут бизнес-логику приложений, то не так уж много задач, где сложность той или иной функции, как-то влияла на пользовательский опыт юзера софта. Они есть, но их ничтожно мало в современных реалиях доступного железа.
Так делает ли LeetСode тебя более лучшим программистом, чем ты есть?
Определено тренировка по работе с различными структурами данных не самыми очевидными способами - это хорошая тренировка тому, как вы мыслите и как вы пишите код. Так же это хороший способ пробиться в Tier-1 компании сквозь алгоритмическое интервью, где более опытные коллеги смогут передать вам свой опыт, что сделает вас лучше.
Однако, если мы обратимся к опытным программистам и it-архитекторам, то они явно скажут вам, что решение задач на leetcode не сделает из вас хорошего программиста. Потому, что решение алгоритмических задач и воплощение задач бизнеса в жизнь - редко пересекаются. И реально, есть множество талантливых и успешных программистов из топовых компаний, которые никогда не решали алгоритмические задачи.
Так же стоит обратиться к словам Стивена Скиена из книги по алгоритмам. Он смеялся и говорил, что очень рад тому, что FAANG пропускают людей через алгоритмическое интервью, так как это увеличивает тираж его книг и приносит дополнительную копеечку, а есть ли польза от алгоритмов или нет - покажет время.
Поэтому, если у вас есть время, то на алгоритмические задачи определенно можно потратить свое время, это откроет для вас новый образ мышления, а также позиции в некоторых компаниях. Но и без этого можно стать успешным программистом.
Но все же, почему именно алгоритмические задачи?
Чтобы понять, почему Бигтех спрашивает у каждого человека алгоритмические задачи, нужно немного погрузиться в контекст найма в Бигтех. Если на рынке РФ разница между предложениями "обычных" компаний и tier-1 компаний не сильно отличаются по денежке и количеству бенефитов, то в США Бигтех делает офферы, которые в разы перекрывают предложения от обычных компаний. Поэтому, количество людей, которые хотят работать в бигтехе просто колоссальное (люди едут со всего мира, чтобы работать в Гугле, Фейсбуке, Майкрософте и так далее).
Имея огромный поток людей высокой квалификации, которые хотят у тебя работать, можно поставить барьер, который отсеет тех, кто не готовился к собеседованию именно в твою компанию. Зачем нанимать просто опытных, если можно нанимать опытных, усердных и мотивированных. Именно поэтому появляются различные истории типа той, где на работу не взяли создателя homebrew, потому что он не смог сделать вайтбоард в гугле: Логично ли, что Гугл отклонил кандидатуру Макса Хауэлла, автора Homebrew, за неумение инвертировать двоичные деревья?
Поэтому да, если какой-то программист в США хочет сменить работу на бигтех, сколько бы у него не было опыта, он садится и начинает готовиться к собеседованию. И порой процесс подготовки занимает 5-6 месяцев, включая различные сервисы и персональных тренеров, которые подтягивают его по каким-то моментам собеседования. Например, вот целый сервис, который учит тебя правильно вести на собеседовании и правильно обсуждать зарплату:
В РФ такой поток кандидатов есть лишь у нескольких компаний по причине их сильного технобренда, поэтому такой практике у нас нет повсеместно. И многие программисты даже считают за оскорбление, если их просят подготовиться к собеседованию как-то специально. Однако, возможно времена поменяются, и уже кандидатам придется конкурировать за места, а не местам за программистов.
Комментарии (154)
AKiNO
09.01.2023 09:55+3Тут все конечно зависит от ваших целей в IT - если интересные проекты в дружном коллективе, то алгозадачи вам пригодятся. А если просто хочется денег заработать, то лучше избегать компаний, где на собеседованиях присутствует LeetCode-секция
NeoNN
09.01.2023 10:15+2Внезапно, сейчас она присутствует почти во всех ведущих компаниях.
AKiNO
09.01.2023 11:41не подскажете, это в каких?
siziyman
09.01.2023 11:49+4Да начиная от FAANG'ов с майкрософтами (которые, кстати, платят сильно выше среднего по рынку) и заканчивая всякими HFT-конторами.
F0iL
09.01.2023 12:18+2с майкрософтами
платят сильно выше среднего по рынку
Ну такое. В моей локации есть R&D-офис майков, и судя по офферам и народной молве платят они не то чтобы выше среднего.
Лучше всех по зарплатам предлагают офферы один большой инвестиционный банк и одна средних размеров продуктовая компания, и ни там, ни там на собеседованиях не дают задачки с литкода, а если и дают, то такие, которые без можно решать без подготовки.
0xd34df00d
09.01.2023 18:32Я, если честно, вообще так и не понял, для каких именно задач на литкоде нужна какая-то особая подготовка вне решения обычных задач в ходе обычной работы программистом.
Andrey_Solomatin
09.01.2023 23:53+5Я, например, никогда не использовал бэктрекинг и динамическое программирование в реальных проектах. Когда первый раз сталкиваешься подзависаешь.
AngusMetall
09.01.2023 13:01+1Так у хфт и гугла это хотя бы оправдано, а зачем такое у условного банка, где ты будешь 99% времени писать бизнес логику, вообще не очень понятно
siziyman
09.01.2023 16:13+5Я не обсуждал осмысленность (спойлер - в фаангах с т.з. реальных задач это в 90% случаев оправдано ничуть не больше), я обсуждал факт наличия. :)
wataru
09.01.2023 13:02+2А если просто хочется денег заработать, то лучше избегать компаний, где на собеседованиях присутствует LeetCode-секция
Если не считать очень везучих стартапов, то условные FAANG, с котрых эти leetcode интервью и пошли — это одни из самых высокооплачиваемых позиций в IT.
AKiNO
09.01.2023 13:17думаю, что это заблуждение (но пруфов конечно не будет, основано на отзывах знакомых кто там работает)
wataru
09.01.2023 14:19+2Ну есть же levels.fyi и glassdoor.com. Это можно же посмотреть.
По личному опыту говорю. По крайней мере в Швеции Гугл платит повыше рынка.0xd34df00d
09.01.2023 18:40+6Ну то Швеция :]
В финтехе платят сильно выше фаангов, и живым кэшем вместо стоков. Правда, там и интервью посложнее, чем задачки с литкода порешать.
wataru
09.01.2023 19:06+2Именно поэтому я написал "faang… это одни из самых высокооплачиваемых позиций в IT". Не самые-самые, но уж точно не ниже рынка.
Hixon10
10.01.2023 00:33+1А что спрашивают на сложных финтех интервью? Или под финтехом речь идёт про HFT, где идёт борьба за каждую нс?
0xd34df00d
10.01.2023 02:34+3Ну, например,
- написать свой std::any, походя, как один из вопросов на 45-минутном раунде,
- придумать свой raft (я тогда не знал про raft) и обосновать его корректность, тоже на 45-минутном раунде,
- написать свой, короче, парсер на монадических комбинаторах, но на шаблонах C++, ну вы поняли, за 45 минут.
Но да, это всё было либо в HFT, либо очень близко к HFT-подобным контекстам (где латенси может быть и похуже, но throughput должен быть близким к максимальному).
В фаанге лично у меня была мегахалява уровня сбалансировать скобки разных видов (со звёздочкой — породить их), найти попарно наиболее близкие велосипеды к людям, или написать хрень, которой отдаёшь
std::function, а оно проксирует вызовы к ней и вызывает её не чаще N раз в секунду. Может, повезло так, не знаю.
ikostruba
10.01.2023 00:34+2Возможно, зависит от страны, но в Германии финтех существенно ниже FAANG по зарплатам.
0xd34df00d
10.01.2023 02:37Это всё про Штаты, да. Ну и я там зря не уточнил, конечно — финтех разный бывает, у меня опыт в основном со всякими HFT и им подобными.
MentalBlood
09.01.2023 10:01+4Внезапно, но самое эффективное решение не всегда оказывается самым читаемым
Чтобы избежать противоречий, можно говорить о разных аспектах решения:
- корректность
- потребление памяти и процессорного времени
- легкость чтения/изменения/дополнения
victor-homyakov
09.01.2023 18:30+3Несколько раз встречал такое в своей работе. Самое эффективное по скорости решение было самым сложно читаемым. Следующее по эффективности решение (чаще всего имеющее ту же сложность в O-нотации, но отличающееся коэффициентами - например, вычисляющее результат не за два прохода по массиву, а за три) было намного более читабельно и компактно. Выбирали более читабельное.
wataru
09.01.2023 19:08А самое неэффективное, какой-нибудь полный перебор, вы в это сравнение даже не включаете. Скорее всего оно там есть и будет еще хуже решения с двумя проходами.
ivanovdev
09.01.2023 19:53вот совсем не факт, с одной стороны теоретически обоснованный алгоритм, с другой - реальное приложение, где на выполнение вашего алгоритма влияет куча различных параметров.
Andrey_Solomatin
10.01.2023 00:01Этоже классика, производельность против простоты. Читаемость обычно свзяана с простотой. Хотя именно в опубликованных здачах на литкоде часть читаемость ужастная. Там свой особенный стиль.
Если говорить о Питоне то читаемость и производительность часто идут рядом. Чем болше ты используешь стандартную библиотеку и меньше кода пишешь, тем Питон быстрее работает.
Artyomcool
12.01.2023 02:33Всё-таки производительность лучше мерить не в О-нотации, а в профайлере на реальных данных в проде)
ruomserg
09.01.2023 10:09+8Почитайте старое (1960-е) сатирическое эссе Сирила Паркинсона о том, как правильно нанимать людей на работу: бенефиты должны уравновешиваться сложностями и опасностями — иначе вас завалят кандидаты. Прочитали? Теперь порадуйтесь, что только алгоритмические задачки, а не плыть в бассейне наперегонки с живым крокодилом…
KongEnGe
09.01.2023 18:56К счастью, с крокодилом -- это не последняя доступная вакансия на рынке, где-то и формошлепов берут только за сам факт явки на собес :)
stackjava
09.01.2023 10:25+11А если изучить квантовую физику, то вы сможете понять как работает квантовый компьютер...
Это тоже сделает ваш мозг более эффективным.
Но вы не бросаетесь на это.
Думаю тут просто выбор каждого... Кому то алгоритмы по душе, кому то нет.
Rio
09.01.2023 10:56+2Так то оно так, только не надо забывать, что алгоритм, по определению, - это последовательность операций для решения задачи. И программисты, пишущие код, вообще-то, как не крути, именно алгоритмы реализуют (в большинстве случаев), пусть зачастую и не шибко сложные. А раз так, то и тренировка мозга решением алгоритмических задачек явно лишней не будет. А то иногда случается такое, что некоторые программисты задачки условно уровня fizzbuzz не могут адекватно решить (или решают, но настолько переусложнённо и запутанно, что диву даёшься).
stackjava
09.01.2023 11:13+1В 90% используется библиотека языка, в которой работа с коллекциями встроена.
Другое дело что если потребуется прямо еще быстрее и эффективнее чем то что уже есть... Но часто ли у вас такое бывает
Cfyz
09.01.2023 12:05+2Библиотека языка это совсем базовые кирпичики. Знание алгоритмов в данном случае подразумевает понимание какие кирпичики в каком порядке надо составить, чтобы построить надёжный фундамент для дальнейшей логики программы.
WraithOW
09.01.2023 13:11+9Стандартную библиотеку так-то тоже нужно уметь использовать, чтобы не было
list.sorted().first()
domix32
09.01.2023 11:49Та ну мне кажется достаточно голой математики, чтобы понимать как он работает.
victor-homyakov
09.01.2023 18:39+4Несколько раз видел, что программисты в своей ежедневной работе в упор не замечают, что у них получается сложность решения
O(N^2)или вообщеO(N^3). Так что автоматически понимать прямо в процессе написания кода, какая сложность у него получается, и насколько это критично на твоих размерах данных - это сам по себе ценный результат изучения алгоритмов и прорешивания задач.stackjava
09.01.2023 22:02+1Зачастую проще не заморачиваться и пройтись по списку из 5 элементов несколько раз в разных местах, чем переложить в мапу и обеспечить себе 0(1)
Какие то моменты игры в перекладывания в разные структуры хранения для оптимизации норм...
Но на литкоде часто откровенно задротные алгоритмы на харде... И вероятность такое встретить в реале весьма низка.
Поэтому если вам нравится в этом копаться и разбираться это хорошо, ваше хобби в рабочей стезе, но это не обязательно.
Есть тех команды, там вот такое только в путь, весьма, полезно.
Но большая часть команд бизнесовая (в мире java по крайней мере) и там это просто приятное дополнение, не боле.
victor-homyakov
09.01.2023 22:32+2Зачастую проще не заморачиваться и пройтись по списку из 5 элементов несколько раз в разных местах, чем переложить в мапу и обеспечить себе 0(1)
Это всё ещё сложность
O(N), и учитывая гарантированно малое количество элементов (5), можно считать её близкой кO(1). Повторю, что я писал о сложностиO(N^2)и выше, при этом время выполнения стремительно растёт даже для сравнительно небольших размерностей списков/коллекций/etc., которые легко могут встретиться в продакшне. Очень важно понимать такое прямо в процессе написания кода. И по моим наблюдениям, у программистов без опыта литкода такое понимание затруднено.Но на литкоде часто откровенно задротные алгоритмы на харде... И вероятность такое встретить в реале весьма низка.
Да, есть такое. Подавляющее большинство из них я никогда не применю на практике. Но вероятность не равна нулю. Всё-таки круто, встретив в реальной работе аналогичную задачу, сказать "Я помню с литкода, что здесь есть оптимальный алгоритм за O(N). На наших данных это поднимет нам RPS/снизит нагрузку на CPU на ... процентов."
Andrey_Solomatin
10.01.2023 00:15В разных языках по разному, в Питоне очень приятный API для словарей и порой правильный ход будет не сложнее простого алгортма. По производительности на 5 элементов там сущая лотерея, логически это не доказать, только измерение. Да и то с новой версией языка всё может поменться.
Среди задротных алгоритмно были такие как написать свой движок для регулярных выражений и нечёткий поиск. В жизни я их кончено не буду писать, но прикольно понимать как серьёзные штуки работают.
anone18236
09.01.2023 10:33+1Поэтому да, если какой-то программист в США хочет сменить работу на бигтех, сколько бы у него не было опыта, он садится и начинает готовиться к собеседованию. И порой процесс подготовки занимает 5-6 месяцев, включая различные сервисы и персональных тренеров, которые подтягивают его по каким-то моментам собеседования. Например, вот целый сервис, который учит тебя правильно вести на собеседовании и правильно обсуждать зарплату
Проблема в том, что иногда галеры начинают вести такие собеседования, как будто они бигтех, нередко еще предлагая и зарплату ниже рынка. Вот как раз это и вызывает недоумение- я иду на позицию миддл+ на 2-3к$, а они требуют знания и умения как в фаанг.
alexdevyatov
09.01.2023 12:47+9Потому что такие галеры продают вас заказчикам как Senior+
PaveTranquil
09.01.2023 12:53Это у вас как аналогия с этими старшими консультантами и специалистами, которые на самом деле обычные операторы в call-центрах?
Sixshaman
09.01.2023 11:52+9И вот после того, как вы прочитали 2-3 книги, которые могут у вас занять порядка 3-4 месяцев
Читаю первую вот уже 8 месяцев по полтора часа каждый день. Дошёл только до 4-й главы (делаю все упражнения). 3-4 месяца на две книги — очень нереалистичный прогноз.
PaveTranquil
09.01.2023 12:47Это тот самый случай, когда профильные вузы оказываются нужными. Конечно, как мы видим, есть и книжки с курсами, но ни одна книжка не заменит работу с преподавателем (опять же, смотря с каким ещё). Подавляющее большинство направлений, связанных с разработкой ПО, имеет в своём арсенале одну или две дисциплины, связанные с алгоритмами и обработкой данных. А LeetCode — отличная возможность попрактиковать обретённые знания ;)
AWE64
09.01.2023 12:54+6Если говорить про реалии РФ, и не про топовые вузы, то преподают это, как правило, очень странные люди, с разработкой ПО знакомые только по книжкам.
Ioanna
09.01.2023 15:59+2У нас на втором курсе дисциплину "Анализ комбинаторных алгоритмов" преподавал местный гений - начальник вузовского отдела АСУ, бывший олимпиадник и будущий директор одной из ведущих местных компаний, разрабатывающих ПО.
С тех пор на всю жизнь осталась привычка оптимизировать абсолютно все, что видишь, вплоть до приготовления завтрака)
AWE64
09.01.2023 16:28А у нас программирование вел Василий Юрьевич Б, админ из одной крупной аутсорс-компании на L; пришел он на лекцию с книжкой по плюсам, книжка была древняя и хэллоуворлд из нее не компилировался, что нужно исправить он сам не знал. Благо я за пару лет до этого начал самостоятельно изучать кресты и догадался, что нужно было исправить инклуд stdio.h на cstdio или что-то в этом духе. А то пришлось бы нашей группе изучать basic или паскаль)
artemlight
09.01.2023 12:52+1Однозначно полезно решать литкод.
Как минимум в голове освежаются структуры данных, да и в целом в работе меньше начинаешь бояться алгоритмических каких-то штук.
Но лень. Премиум помогает два месяца в году - за месяца до экспайра и месяц после продления премиума :) Приходится себя заставлять, но это уже не к литкоду вопросы.
wataru
09.01.2023 13:00+4Внезапно, но самое эффективное решение не всегда оказывается самым читаемым.
Но часто случается и наоборот. Например, динамическое программирование в 3 простых вложенных цикла и одно присвоение внутри оказываются гораздо более читабельнее рекурсивного полного перебора. Конечно, при условии, что читающий хотя бы статью в википедии про динамическое программирование читал.
Лично код переписывал с перебора на ДП — вместо двух сотен строк получилось 30 (с комментариями и объяснениями).
Как правило, в работе не нужны все алгоритмы, нужна какая-то узкая область
Вот только вы не знаете, что это за область. Вот, например, разработка библиотеки webrtc. Даже не кодеки с их математикой, а вот вся эта обертка — засунуть пиксели в энкодер, передать сжатые данные на другой конец, засунуть в декодер. Вот очевидно вам, что там понадобятся:
линейная регрессия, теория чисел, динамическое программирование, moving window max (прямо задачка на литкоде такая есть), фильтр калмана.Потом, литкод и не учит же Алгоритмам, как таковым. Там только самые базовые вещи же и применяются: ДП, какие-то трюки с сортированными массивами, стеками, обход вширину/глубину. Ни алгоритмов дейкстры, ни блюма-флойда-пратта-ривеста-тарьяна, ни кнутра-морриса-пратта там не используется. Даже сортировки как таковые там ограничиваются вызовом функции sort() и пониманием, что оно рабоатет за n log n.
Вторая часть проблемы в том, что очень многие задачи имеют простое в понимании, медленное наивное решение. Если вы не знаете, что вот есть такие вот алгоритмы, то у вас даже мысли не появится, что вот тут надо не пройтись по спискам туда-сюда несколько раз, а можно динамическое програмимрование впендюрить.
Поэтому алгоритмы лучше знать. Хуже от этого точно не станет, а вот пригодится может (и пригождается).
в условную функцию может прийти какой-то узкий набор данных предсказуемой длины.
А через пол года данных в базе становится все больше и все начинает тормозить.
не так уж много задач, где сложность той или иной функции, как-то влияла на пользовательский опыт юзера софта.
10% замедления вот тут, 200% вот там, 10000% еще где-то. Оно все складывается и накпливается или у пользователей вылезают внезапные тормоза в непонятном месте.
WraithOW
09.01.2023 13:23+3Ни алгоритмов дейкстры
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/
Признайтесь, вы литкод в жизни не открывали, верно?
wataru
09.01.2023 14:17Первая задача слишком мелкие ограничения. Во второй можно не только KMP, но и хешами решать.
Признайтесь, вы литкод в жизни не открывали, верно?
~730 задач, 260 hard, Top 0.56% в рейтинге каком-то там.
Но эти три задачи мимо меня прошли. Все-таки это капля в общем море задачек на списки, массивы и использование hash-map'ов.
Я был не совсем прав, но все-равно утверждаю, что можно прорешать почти весь литкод не изучая никаких сложных алгоритмов. Плюс на интервью всяких их тоже спрашивать не будут.
WraithOW
09.01.2023 14:55+2Первая задача слишком мелкие ограничения. Во второй можно не только KMP, но и хешами решать.
Понятно что можно, но обычно люди после решения идут в Solutions и смотрят, как еще можно было. Особенно если твое решение по скорости/памяти где-то в самом низу (если вообще не свалится с таймаутом).
https://leetcode.com/problems/top-k-frequent-elements - хочешь быстро? Разбирайся в Quick select'e.
Но эти три задачи мимо меня прошли.
Это тупо те, которые гугл выдал первой строкой. Так там только на Дийкстру в том или ином виде десяток задач.
https://leetcode.com/list/53js48ke/Я был не совсем прав, но все-равно утверждаю, что можно прорешать почти весь литкод не изучая никаких сложных алгоритмов.
Можно и в универе 5 лет отучиться и выйти полным дубом. На литкоде есть отличные study plans, есть мини-курсы по разным разделам. Практически все средние/продвинутые из них трогают вещи посложнее BFS/binary search. Ясен пень это не замена четырёхтомнику Кнута, но я бы не сказал, что мой универовский курс по тем же графам мне дал сильно больше.
victor-homyakov
09.01.2023 18:51Ещё вот здесь было собрание интересных кейсов: https://accidentallyquadratic.tumblr.com/, хотя с 2019 года оно уже не пополняется
Finesse
09.01.2023 13:09+3Спор из разряда «нужна ли программисту математика».
В статье почему-то ничего не говорится про развитие когнитивных способностей. Мне кажется, это главный смысл решения задач.
И вот после того, как вы прочитали 2-3 книги, которые могут у вас занять порядка 3-4 месяцев, можно приступать к решению задач на Leetcode.
Как же это неэффективно...
Я не решал никогда задачи с литкода, пару месяцев назад начал ради интереса. До этого никогда не учил алгоритмы и структуры данных специально.
Да, иногда я решаю задачи топорно и не оптимально, но к счастью есть вкладка Solutions с сотнями разборов задачи на любой вкус. Ознакомление с одним-двумя приводит к полному понимания решения. На всё уходит 2 часа максимум (для уровня hard), если не решаешь уп
ороереться и придумать решение сам. В итоге голова сразу пополняется практическими навыками. Так я освоил динамическое программирование, кучу и много другого.
nameless323
10.01.2023 00:46Книги как мне кажется как раз более для "развития когнетивных способностей". То есть из литкода вполне себе можно понять те или иные алгоритмы, а книги это скорее "а почему этот алгоритм работает? а как это доказать строго математически? а вот квиксорт n * log(n) в среднем, а давайте докажем с помощью теорвера что это так" и так далее. Тут конечно кому что интересно так как редко кому в работе это пригодится. Ну и в книгах алгоритмы более структурированны по темам обычно и идут в более-менее логичном порядке.
s_f1
09.01.2023 14:12+8Особенное удовольствие на Литкоде мне доставляют не «эталонные» решения, кои можно посмотреть и в других местах, а красивые «хакерские» штучки. Там в обсуждении к каждой задаче любой может выложить своё решение, и на некоторые вещи смотришь, как на «Мона Лизу», или там «Лебединое озеро». Вроде все операторы понятны, но КАК это можно было придумать?
делает ли это тебя лучше – безусловно,
как программиста – кто знает,
будет ли полезным для работы – вероятно нет, но какая разница?
gybson_63
09.01.2023 14:37+2Эти задачки тренируют писать чистый и понятный код, который легко анализируется и развивается. Иначе можно зависнуть в трёх соснах даже на относительно простой задаче и так и остаться с прототипом.
Мне больше нравится возможность знакомства с другими языками.F0iL
09.01.2023 14:45+6Эти задачки тренируют писать чистый и понятный код, который легко анализируется и развивается.
Как именно?
При решении подобных задач обычно о гибкости и расширяемости кода не думают обычно вообще, там это не требуется, и то что на выходе в большинстве случаев никак иначе как "прототипом" не назовешь :)
Точно так же как программисты-олимпиадники зачастую пишут write-only-код, на который без слез не взглянешь. Рабочий - да, предельно оптимизированный - да, но уж точно не "легко анализируемый" и "легко развиваемый".wataru
09.01.2023 14:48Без грамотной архитектуры что-то уровня hard с несколькими структурами данных не написать. Олимпиадники, действительно, страдают плохими именованиями переменных и функций. Но в индустрии это лечится за одну неделю, если, конечно, в процессе есть код-ревью (а без него в любом случае будет хреново).
Alexandroppolus
09.01.2023 19:27Олимпиадники, действительно, страдают плохими именованиями переменных и функций.
Это проблема вообще не связана с олимпиадничеством и есть почти у всех новичков в промышленном программировании.
wataru
09.01.2023 19:35+1У олимпиадников это усугублено необходимостью писать код быстро. И привычка выработана. Вот если я всю олимпиадную карьеру обзывал вершину графа v, то поначалу мне бы хотелось также называть и человека в графе друзей, например. Ну, потому что это понятное, говорящее (мне) название. Плюс, олимпиадники, хоть и новички в промышленном программировании, часто имеют весомый опыт собственно программирования. И за исключением коротких имен переменных часто могут сразу стать мидлом.
VFaland
09.01.2023 15:42+1Тут зависит от того как использовать литкод. Если тупо адаптироваться под систему и фигачить write only, тогда да, может и во вред пойти. А можно писать нормально, с юнит тестами ИТП. В фаангах на интервью обращают внимание на то как код написан, олимпиадный код получит жирный минус несмотря на эффективность.
gybson_63
10.01.2023 13:53Может я такого мнения, потому что в основном на codingame зависаю. А там хорошее решение обычно и хорошее приложение в полном смысле. От архитектуры в целом, до оптимизации частностей.
И потом, если у вас уровень высокий, то конечно вы можете писать код любого вида. А новичок на грязном коде далеко не уедет, закопается.P.S. Олимпиады это хорошо, но многодневные контесты лучше.
Arastas
10.01.2023 16:44Вы не могли бы, пожалуйста, обрисовать разницу между codingame и leetcode? Разные типы задач? Разная аудитория?
gybson_63
10.01.2023 18:33Для начала приведу в пример вот такую задачку
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", иди ищи где что случилось. Здорово дисциплинирует.
0xd34df00d
10.01.2023 20:54Сейчас вот впервые об этом codingame услышал, но ключевая разница в том, что в codingame можно писать на хаскеле, а в leetcode — нет. Приз моих зрительских симпатий однозначно за ним.
Zara6502
09.01.2023 15:02+1Тут же всё как всегда - если вы 10 лет посвятили конькобежному спорту, то на выхлопе у вас останется только пара перекаченных ног, которые, внезапно, не помогут вам стать быстрым бегуном.
Поэтому любой человек щелкающий как орешки алгоритмические задачи - останется тем, кто - умеет алгоритмические задачи. Всё.
Так же как знание всех операторов, команд, макросов наизусть ни на каплю вас не приблизит к тому, чтобы вы стали программистом-богом.
Поэтому такие задачи при приёме на работу - это бред, только если человек не ищется на позицию, где эти алгоритмы и нужно применять.
Я знаю-знаю, вы тут же возразите, что тест проверяет способности человека к решению задач в целом и т.д. и т.п., но тогда и тест должен быть не только из алгоритмических задач и потом, я хорошо пишу на ассемблере, но не умею вообще в ООП, то есть я могу написать код на C#, но процедурный. Делает ли это меня плохим программистом или всё же это делает меня узкоспециализированным, но не плохим?
PS: мой брат успешно работает за границей в геймдеве, но он никогда не писал сортировку пузырьком и не знает что такое коды Элиаса XD а я знаю, только у него зарплата в 20 раз больше.
WraithOW
09.01.2023 15:23+9Тут же всё как всегда - если вы 10 лет посвятили конькобежному спорту, то на выхлопе у вас останется только пара перекаченных ног, которые, внезапно, не помогут вам стать быстрым бегуном.
Если вы 10 лет гоняли на коньках, то у вас будут отличная дыхалка, тренированное сердце и адекватно развитая мускулатура. Отличное преимущество на старте перед конкурентами, которые до этого вообще спортом не занимались. Плохой пример, негодный.
то есть я могу написать код на C#, но процедурный
К вопросу решения алгоритмических задач это отношения не имеет никакого.
nullptr
09.01.2023 15:32Отличное преимущество на старте перед конкурентами
...в конькобежном спорте или смежных дисциплинах, но такое себе если вы устраиватесь автослесарем.
О чем, я думаю, и речь — алгоритмы надо решать, если вы реально по работе пишете нетривиальные (ого!) новые (ого!) алгоритмы. Тогда вы станете лучше решать алгоритмы и, благодаря этому, лучше работать и больше зарабатывать.
Если вы по работе этим не занимаетесь, то вы станете лучше решать алгоритмы. И все. А лучше работать и больше зарабатывать будет тот, кто занимался более полезными, в случае этой конкретной работы, вещами.
WraithOW
09.01.2023 15:39+1...в конькобежном спорте или околсмежными дисциплинами, но такое себе если вы устраиватесь автослесарем.
Тут же всё как всегда - если вы 10 лет посвятили конькобежному спорту, то на выхлопе у вас останется только пара перекаченных ног, которые, внезапно, не помогут вам стать быстрым бегуном.
Тред не читай @ сразу отвечай, правда?
Алсо
в конькобежном спорте или околсмежными дисциплинами
В любом спорте/любой деятельности, подразумевающим регулярные физические нагрузки. Даже бухать и сексом заниматься легче.
nullptr
09.01.2023 15:46+2Тред не читай @ сразу отвечай, правда?
...в конькобежном спорте или околсмежными дисциплинами...
Судя по тому, что вы не стали дочитывать даже первое предложение до конца — видимо, правда.
В любом спорте/любой деятельности, подразумевающим регулярные физические нагрузки.
Раскрою свою мысль в этих терминах: ваша деятельность подразумевает регулярные алгоритмические нагрузки (цикл for и прочее за нагрузку не считаем)? Если да, то для работы вам нужны алгоритмы. Если нет, то для работы они вам —как и 90% всех ИТ-специалистов — не нужны. Раз в 5 лет написать решение проблемы рюкзака за 8-16 часов вы уж как-нибудь сможете по туториалам с Интернета, а чаще и быстрее вам и не надо.
А если оно вам и не надо то,
Можно ли решать алгоритмы? Можно.
Полезно? Полезно.
Есть ли в этом практический смысл для работы? Нет.
Бред ли спрашивать их на собесах? Бред.
Лучше ли тратить это время на конькобежный спорт, что бы потом легче бухать и сексом заниматься? Лучше, ведь жизнь коротка, а смерть — внезапна.WraithOW
09.01.2023 16:17Судя по тому, что вы не стали дочитывать даже первое предложение до конца — видимо, правда.
Я-то дочитал, но любая аналогия, подобно сове, имеет пределы растяжимости. Подменять в полёте исходный тезис - дурной тон.
Раскрою свою мысль в этих терминах: ваша деятельность подразумевает регулярные алгоритмические нагрузки (цикл for и прочее за нагрузку не считаем)?
Написание программы - это и есть составление алгоритмов, на секундочку.
АЛГОРИТМ, -а, м. (спец.). Совокупность действий, правил для решения данной задачи. А. извлечения корня. II прил. алгоритмический, -ая,-ое.
Раскрою свою мысль в этих терминах: ваша деятельность подразумевает регулярные алгоритмические нагрузки (цикл for и прочее за нагрузку не считаем)? Если да, то для работы вам нужны алгоритмы. Если нет, то для работы они вам —как и 90% всех ИТ-специалистов — не нужны.
С такой логикой мы сейчас дойдём до того, что ИТ-специалистам очень много чего не нужно: начиная знанием, что такое TCP и HTTPS, и заканчивая "что такое видеокарта" и каким проводом втыкать монитор в ноутбук. Я не готов называть таких Митрофанушек специалистами.
Алсо замечу, что вы с ОПом ветки мешаете в кучу два связанных, но не эквивалентных навыка:
академические знания - когда человек может рассказать, как устроен квиксорт, что такое свертка матрицы, O(N) vs O(N^2) и т.д.;
практические умения - способность построить для конкретной задачи алгоритм решения.
Для решения easy/medium задач с литкода в среднем больше нужны практические навыки, чем академические знания. Давать их кандидату чтобы убедиться, что он банально умеет программировать - вполне резонно.
nullptr
09.01.2023 18:04Я не готов называть таких Митрофанушек специалистами.
В этом и заключается настоящая причина существования подобных обсуждений, которая почему-то подменяется якобы объективной необходимостью, продиктованной реальностью индустрии.
А реальность индустрии такова, что ИТ-специалистам не только не нужно зазубривать решения абстрактных проблем, им, как вы совершенно верно заметили, вообще очень много чего не нужно: «начиная знанием, что такое TCP и HTTPS, и заканчивая "что такое видеокарта" и каким проводом втыкать монитор в ноутбук».
Мы с вами можем сколько угодно лелеять мысль о том, что программирование — это где крутые спецы решают крутыми средствами реально крутые проблемы, но, увы, невидимая рука проклятого рынка сказала, что программирование — это где решаются проблемы бизнеса.
А бизнес сказал "срочно нужно дешево сервис который вот завтра начнет впаривать мои продукты и услуги максимальному количеству народа". Требований к надежности, производительности и эффективности вообще не стоит: «Патчами допилим если че, а там уже и новое поколение выкатится, опять все перепишем». 90% современной ИТ-индустрии состоит именно из этого. Более того, даже в такие критичные области типа самолетостроения начинают пролезать клятые аутсаффные индусы с их "хеллё май дир френд", с известными последствиям, но целом бизнесу норм.
Поэтому нет — объективно, современному специалисту алгоритмы не нужны.
Субективно-то можно много каких требований понавешать, я бы вот умение грамотно писать и говорить на английском добавил от себя, для начала. Но отношения к реальности это имеет мало поэтому я статьи, полных праведного гнева и притянутых за ушей аругемнтов, и не пишу.WraithOW
10.01.2023 13:07+3А реальность индустрии такова, что ИТ-специалистам не только не нужно зазубривать решения абстрактных проблем
Верно, не нужно. Специалисту нужен кругозор, в противном случае шаг влево-вправо - и "специалист" превращается в тыкву, потому что вообще не сечёт, что происходит.
программирование — это где решаются проблемы бизнеса
Если у бизнеса ложится критический сервис в горячий период и деньги перестают капать - это проблема. Если у бизнеса утекли данные юзеров и прилетит штраф по GDPR в 4% годового оборота - это проблема.
даже в такие критичные области типа самолетостроения начинают пролезать клятые аутсаффные индусы с их "хеллё май дир френд"
Ну если вам норм конкурировать с индусами, которые вчера сидели в колл-центре, а сегодня прослушали курс на ютубе и стали программистами - я ничего против не имею, вам не нужно ничего из перечисленного.
nullptr
10.01.2023 13:30-1Ну если вам норм конкурировать с индусами, которые вчера сидели в колл-центре, а сегодня прослушали курс на ютубе и стали программистами - я ничего против не имею, вам не нужно ничего из перечисленного.
Ну вот мы с вами и согласились. Факт в том, что современное ИТ это ремесло для индусов из колл-центра, даже вожделенные ФААНГИ занимаются в основном клепанием хреновых формочек, один гмейл чего только стоит.
Профессионалам, конечно, зарплата все так же навалом и им все так же платят «за проигрыш и за ничью», но их нужно пять человек на весь ФААНГ и мерять по ним всю индустрию было бы неправильно.
"специалист" превращается в тыкву, потому что вообще не сечёт, -что происходит.
Так и должно быть, в общем случае. Кардиохирурги операции по лазерной коррекции зрения не делают.
База, разумеется, должна быть, но какие-то базовые знания не включают в себя зазубренность тонны алгоритмов, которые некоторые тут хотят проверять чуть ли не с религиозным рвением.
Если у бизнеса ложится критический сервис в горячий период
То Ажур все сам поднимет и заскейлит, ты только плати (меньше, чем "правильным" программистам). А вот настройкой абажуров занимаются девопсы, которым алгоритмы тоже в целом по барабану. Данные юзеров к алгоритмам никакого отношениями не имеют (если только вам не приходится лично реализовывть какой-нибудь AES, что показатель того, что у вас уже что-то пошло очень не так) — умение правильно настраивать окружение и пользоваться фреймворком не требуют применения пузырьковой сортировки.
WraithOW
10.01.2023 14:02Факт в том, что современное ИТ это ремесло для индусов из колл-центра,
Тогда тем более нет проблемы брать литкод - кандидатов много, времени у собеседующих мало (и стоит оно дорого), отсеиваем 90%, а c самыми прокачанными работаем. Идеально же.
>Так и должно быть, в общем случае. Кардиохирурги операции по лазерной коррекции зрения не делают.
Плохой пример, негодный. И те, и другие проходят кучу общих предметов вплоть до акушерства и дерматологии. Но по вашей логике первому нужно знать только где у человека сердце, а второму - какие кнопки жать на LASIK-аппарате.
База, разумеется, должна быть, но какие-то базовые знания не включают в себя зазубренность тонны алгоритмов, которые некоторые тут хотят проверять чуть ли не с религиозным рвением.
А я этого и не предлагаю, и даже осуждаю.
То Ажур все сам поднимет и заскейлит, ты только плати (меньше, чем "правильным" программистам).
Если у вас квадратично растёт сложность, то и время (а значит, стоимость) растёт так же. Алсо толку от скейлинга, если у вас каждый инстанс по две минуты тупит и падает, потому что внутри наговнокожено?
Данные юзеров к алгоритмам никакого отношениями не имеют
Не имеют, но они требуют знания правил работы с ними/OWASP, общего понимания законодательства, понимания основных принципов ИБ и криптографии (например, почему нельзя хранить пароли плейн текстом, или для чего нужна соль в хеше), и так далее. Все те вещи, которые, по вашей-же опять таки логике, им не нужны, ведь они формочки клепают.
lllamnyp
12.01.2023 08:05Вы и ваш оппонент оба правы. Мне, безусловно, приятнее работать с человеком, который мыслит как вы, но я отдаю себе отчёт, что, скажем, можно нанять "девопса", который знает ноль целых, хрен десятых про айти и линуксы в широком смысле, но он решит 99% проблем разработки, которые сводятся к какой-нибудь банальщине, типа "ошибся с отступами в ямл-файле" и бизнесу будет норм.
А для реально важных вещей можно раз в полгода привлечь достойного спеца, который ни за что в ваше болото работать не пойдёт, но по старой дружбе выручит советом.
0xd34df00d
09.01.2023 18:59+1С такой логикой мы сейчас дойдём до того, что ИТ-специалистам очень много чего не нужно: начиная знанием, что такое TCP и HTTPS, и заканчивая "что такое видеокарта" и каким проводом втыкать монитор в ноутбук. Я не готов называть таких Митрофанушек специалистами.
Во-первых, специалистам действительно это может быть не нужно. Я знаю только, что HTTPS — это когда типа секурно, а TCP — это когда пакеты с гарантиями доставки (но это неточно), что не мешает мне писать инфру для трейдинга, заниматься мышиным обучением или типчики ковырять.
Во-вторых, вы путаете интеллект и память. Что такое TCP — это ближе к памяти. Уметь решить алгоритмическую задачу — это ближе к какому-то подвижному интеллекту. Хотя, может, кто-то пытается заучить все алгоритмы, хз.
WraithOW
10.01.2023 12:59Во-вторых, вы путаете интеллект и память. Что такое TCP — это ближе к памяти. Уметь решить алгоритмическую задачу — это ближе к какому-то подвижному интеллекту. Хотя, может, кто-то пытается заучить все алгоритмы, хз.
Не путаю, я буквально написал то же самое другими словами в последних 4 абзацах. И да, некоторые прям ставят вопрос так - "мы хотим от кандидата знание вот таких-то алгоритмов". Пришел на собес - расскажи, нарисуй и станцуй.
типчики ковырять.
Вы дисквалифицированы из обсуждения как overqualified. Знание математики выше 5го класса не нужно IT-специалисту /s
0xd34df00d
10.01.2023 20:57Вы дисквалифицированы из обсуждения как overqualified. Знание математики выше 5го класса не нужно IT-специалисту
Для подавляющего большинства задач это неиронично так, и какого-то особого математического образования ИМХО не нужно.
Dolios
10.01.2023 11:37+3Раз в 5 лет написать решение проблемы рюкзака за 8-16 часов вы уж как-нибудь сможете по туториалам с Интернета, а чаще и быстрее вам и не надо.
Не сможете. Потому что вы не знаете, что такое DP, при чем тут рюкзаки и что вообще надо гуглить.
Есть ли в этом практический смысл для работы? Нет.
Есть. Многие, как уже писали выше, даже не понимают, что они квадраты пишут и не замечают проблемы.
Бред ли спрашивать их на собесах? Бред
На собесе вас просят решить какую-нибудь небольшую задачу, чтобы посмотреть, как вы ее будете решать. Смысл именно в этом.
nullptr
10.01.2023 13:09-2Не сможете. Потому что вы не знаете, что такое DP, при чем тут рюкзаки и что вообще надо гуглить.
Сможем. Все эти проблемы уже 300 раз разобраны везде, от википедии со стаковерфловом до спираченной копии Essential Algorithms, и гуглятся уже почти что по запросу "а как мне сделать быстра жаваскрипт я новичек".
Есть. Многие, как уже писали выше, даже не понимают, что они квадраты пишут и не замечают проблемы.
Если проблемы не видно — значит, ее нет. Word '97 конечно летал на первом пентиуме, а Word 2019 не шибко торопливо заводится на топовом i7 при таком же наборе функций — но, с точки зрения бизнеса и пользователей, "работает — и ладно".
Смысл именно в этом.
Проверяя зазубренность алгоритимов вы проверяете только то, насколько человек зазубрил бесполезные в его работе алгоритмы. В этом нет смысла.
А задачки давать можно, конечно. Но не в духе "напишите мне поиск по произвольному массиву за О(1) за 2 минуты без Интернета, подсказок, компьютера, мозга, сердцебиения ах не смогли ну до свидания тогда".
Dolios
10.01.2023 13:16+4Все эти проблемы
Какие эти проблемы? Вам нужно решить вашу проблему, про которую в интернете ничего не написано.
Если проблемы не видно — значит, ее нет.
Проблему увидят пользователи, но будет поздно.
Проверяя зазубренность алгоритимов
А вы точно программист? Как вы работаете, если не можете осилить пару предложений на родном языке? Я проверяю, как человек решает задачу, а не зазубренность алгоритмов. Именно это написано в комментарии, на который вы отвечали. Я, например, даже код не прошу писать, просто прошу рассказать, что и как он будет делать.
nullptr
10.01.2023 13:41-2Вам нужно решить вашу проблему, про которую в интернете ничего не написано.
Ваша проблема это частный случай общей проблемы. Я не знаю, как это может быть для вас сюрпризом, но люди могут обобщать и проводить аналогии. Иначе никакое знание алгоритмов вам все равно не помогло бы, если только этот алгоритм уже не написан под вашу конкретную проблему.
Проблему увидят пользователи, но будет поздно.
Кому "поздно"? Сможете перечислить бизнесы, которые навернулись или потеряли позици из-за неэффективного написания кода?
Я проверяю, как человек решает задачу, а не зазубренность алгоритмов.
Тогда что вы делаете в треде про необходимость знания алгоритмов?
wataru
10.01.2023 16:40Ваша проблема это частный случай общей проблемы.
Но, чтобы заметить что эта ваша задача — частный случай вот той, разобранной везде, надо про эту разобранную знать! Вот, допустим, у вас задача битстрим h264 порезать на пакеты, не разбивая всякие фрагменты h264 между пакетами (из личной практики). Откуда тут вылезает слово "рюкзак"? А тут ДП вроде рюкзака как раз и применимо.
Т.е. про все эти стандартные задачи надо знать, знать что у них могут быть более эффективные решения, чем полный перебор, нужно уметь свою задачу формализировать. Это уже 80% этих "ненужных программистам алгоритмов".
0xd34df00d
10.01.2023 20:58Вот, допустим, у вас задача битстрим h264 порезать на пакеты, не разбивая всякие фрагменты h264 между пакетами (из личной практики). Откуда тут вылезает слово "рюкзак"? А тут ДП вроде рюкзака как раз и применимо.
Чисто из интереса — а там разве порядок не важен?
wataru
10.01.2023 21:12Важен порядок, да. Надо минимизировать количество пакетов. И тут бы и тупая жадность работала, если бы не дополнительное условие: сделать максимальный пакет как можно меньше.
0xd34df00d
10.01.2023 21:14Я про это ваше видео ничего не знаю, так что эти вот h264-фрагменты — они произвольного и потенциально отличающегося друг от друга размера, но для данной «сессии связи» их размеры известны наперёд?
wataru
10.01.2023 21:43Переформулирую: Есть буфер данных, его надо презать на куски, не превосходящие X. Кусков должно быть как можно меньше, максимальный кусок должен быть как можно меньше. Резать можно только по заданным позициям.
Alexandroppolus
10.01.2023 21:55О, у меня на одну вакуху было очень похожее тестовое задание - равномерная разбивка текста на строки с лимитом ширины. Открыл для себя ДП. Эх, где же ты, лето 2016..
rblaze
10.01.2023 23:48А зачем делать пакет как можно меньше, чтобы лаг уменьшить за счёт времени передачи?
wataru
10.01.2023 23:52Это требование приходит из pacer'а. Ему маленькими пакетами легче битрейт выдерживать. Ну и задержку поменьше делать тоже хорошо.
T-D-K
10.01.2023 13:38+3Сможем
Как вы можете знать что надо загуглить, если не знаете о существовании проблемы?
Я видел код от адептов "я всегда могу загуглить, мне не нужны алгоритмы" и они писали:
* поиск 3-х максимальных элементов в массиве за O(n log n)через сортировку;
* поиск ноды в дереве по заданному пути (где ребёнка можно получить за O(1) из словаря по имени) за O(n^2) памяти и O(n^2) времени от токенов в пути - сеньор-помидор с 13 лет опыта;
* нужно было в дереве раскрасить ноды; раскраска ноды зависит от цветов детей. Другой сеньор-помидор каждый раз переобходил всё дерево рекурсивно без кэширования. Я исправил только это и прога стала стартовать быстрее на 15 секунд;
* есть кэш на чисто вычисляемое от некоторого класса, кэш хранится в хэшмапе. Зачем-то решили, что будет круто сделать класс ключа без переопределения equals и hashCode. Кэш был, обвязка вокруг него была. Всё равно всё вокруг тормозило. Там же была уверенность, что поиск по значению в хэшмапе тоже O(1).
и таких историй могу ещё принести. Люди не натренировали свой мозг оценивать сложность алгоритмов и писать решения, которые доказано (через инварианты, а не только тесты) работают на всех возможных входных данных.
На самом деле, здесь же истории: давайте долбанём много гигантских switch case потому что я не знаю о существовании паттерна visitor. Не зная о его существовании - невозможно пойти и загуглить его описание. Автор, которые принёс на ревью эти свитчи реально был уверен, что его реализация эффективна.nullptr
10.01.2023 13:49-2Как вы можете знать что надо загуглить, если не знаете о существовании проблемы?
Ответил тут. В двух словах — по симптомам (не работает, пользователи жалуются). По ним найдется проблема, по проблеме — ее решение. Да, медленно и неэффективно, но работает же, а мы это и не каждый день делаем: раз в 5 лет можно потерпеть.
и таких историй могу ещё принести.
У меня таких историй тоже полно, в том числе за собственным авторством.
Это все понятно — непонятен негативный эффект такого кода на бизнес, а не на уязвленное чувство прекрасного. Были ли случаи, когда именно из-за неэффективного кода пользователи вставали и говороли "Слишком медленно, уходим к конкурентам"?
T-D-K
10.01.2023 13:54+3Все эти истории я распутывал именно из-за того, что пользователи писали в саппорт о тормозах, которые невозможно терпеть. После одного из ускорений один пользователь написал, что больше не надо синхронизировать походы в туалет с запуском программы.
Не уходили они скорее по причине почти полного отсутствия конкурентов, но новые версии запросто могли перестать покупать, если они тормозят.
faiwer
10.01.2023 14:47+5мне не нужны алгоритмы
К копилку примеров:
- Ikea при занесении в корзину товаров больше чем 13-15 начинала безумно тормозить. Куда они там умудрились
O(n^3)запихать у меня фантазии не хватает - enzyme (мега-популярный тест-фреймворк для react от airbnb) умудрились реализовать "обход в ширину" за
O(n^2), что страшно негативно сказывалось на не-shallow тестах. Хотя должно было работать мгновенно. - какой-то очень популярный jQuery calendar widget адски тормозил на IE6 тупо потому что неадекватно часто перекладывал объекты в объекты посредством
Object.assign. Это замедляло то что должно работать за 0.5с до 1мин+.
Человек не понимающий основ не сможет понять, в чём проблема. С какой стороны к ней подходить. По каким словам гуглить. Как проверять результат. У него просто "ну оно тормозит, потому что ему нужно много считать". Многие вообще живут с мантрой "оно там внутри умное, оптимизировано в гугле"… и этим оправдывают лютую дичь в коде.
WraithOW
10.01.2023 15:06+3"оно там внутри умное, оптимизировано в гугле"
У меня про это есть классная история про потроха Андроида версии около 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
Alexandroppolus
10.01.2023 16:09Ikea при занесении в корзину товаров больше чем 13-15 начинала безумно тормозить. Куда они там умудрились O(n^3) запихать у меня фантазии не хватает
чтобы на 20 элементах тормозило, O(n^3) не хватит, должно быть что-то экспоненциальное
- Ikea при занесении в корзину товаров больше чем 13-15 начинала безумно тормозить. Куда они там умудрились
wataru
09.01.2023 15:53+2Поэтому любой человек щелкающий как орешки алгоритмические задачи — останется тем, кто — умеет алгоритмические задачи. Всё.
Это человек, который обладает развитым алгоритмическим мышлением, умеет писать код, знает структуры данных, когда и как их применять, умеет решать задачи. Что из этого не нужно в программировании?
Поэтому такие задачи при приёме на работу — это бред, только если человек не ищется на позицию, где эти алгоритмы и нужно применять.
Но алгоритмы надо применять почти везде! Не 100% времени, а эпизодически, но вы не можете наперед сказать, что вот тут вот они понадобятся, а вот тут — нет. Вот какой-то знак дорожный встречается редко. Значит ли что в экзамене на ПДД его не должно быть?
Вот мои примеры. Разработка библиотеки webrtc. Даже не кодеки с их математикой, а вот вся эта обертка — засунуть пиксели в энкодер, передать сжатые данные на другой конец, засунуть в декодер. Вот очевидно вам, что там понадобятся:
линейная регрессия, теория чисел, динамическое программирование, moving window max (прямо задачка на литкоде такая есть), фильтр калмана?Более того, проблема с алгоритмами в том, что почти любая алгоритмическая задача допускает тупое наивное решение. Даже не литкоде многие задачи сформулированы "Дано вот это, сделайте с ним вот это". Казалось бы, что тут решать — ведь в условии сказано, что надо делать. И, не зная алгоритмов, вы даже не задумаетесь, что вот тут оказывается нужны были алгоритмы. Поэтому нельзя, например, нанять в команду отдельного алгоритмиста. Потому что ему придется ревьювить вообще весь код. Продуктивнее требовать знание алгоритмов при найме у всех.
тест проверяет способности человека к решению задач в целом и т.д. и т.п., но тогда и тест должен быть не только из алгоритмических задач
Ладно бы там были математические какие-нибудь задачки. Но тут задачи именно запрограммировать.
но не умею вообще в ООП, то есть я могу написать код на C#, но процедурный. Делает ли это меня плохим программистом
Нет. И любое интервью вы пройдете таким кодом. Более того, почти никто нигде не испольует ООП на таких интервью.
мой брат успешно работает за границей в геймдеве, но он никогда не писал сортировку пузырьком и не знает что такое коды Элиаса XD а я знаю, только у него зарплата в 20 раз больше.
Ключевые слова "за границей". Уверен, что существует человек из вашего региона россии, который выучил алгоритмы и получает в той же стране, что ваш брат, в 2-3 раза больше, работая в гугле.
WraithOW
09.01.2023 16:53Ключевые слова "за границей". Уверен, что существует человек из вашего региона россии, который выучил алгоритмы и получает в той же стране, что ваш брат, в 2-3 раза больше, работая в гугле.
Я бы воспринимал исходный пассаж с некой долей сомнения. Геймдев в средним как раз требует больше академических знаний от программиста: поиск путей - это, считай, работа на графах, графоний - векторная алгебра, и так далее.
wataru
09.01.2023 18:21+1Геймдев в средним как раз требует больше академических знаний от программиста
Эх…
К сожалению, самый прибыльный геймдев — донатные мобильные помойки, не требует ничего особо. Жаль, что этот рак на самом деле является нынче "средним геймдевом". Для условные три-в-ряд и подобных казуальных игр больше нужны художники и специалисты по агрессивной монетизации.А ведь геймдев, действительно, раньше был острием высокопроизводительных алгоритмов. Даже если использовать готовый движок надо было понимать всякие тонкости.
0xd34df00d
09.01.2023 19:00Вот какой-то знак дорожный встречается редко. Значит ли что в экзамене на ПДД его не должно быть?
Вы будете смеяться, но у меня на экзамене по теории ЕМНИП вообще знаков особо не было. И ни у кого не было. И в курсе показали только примеры самых частых.
wataru
09.01.2023 19:09А какие вообще тогда вопросы то были, если теоретическая часть вообще была?
0xd34df00d
09.01.2023 19:27+1Теоретическая часть сводится к шести часам видео онлайн и всяким очевидным quiz'ам по видео. Примерно половина видео — про то, что бухать за рулем не нужно, и quiz'ы по этой части сводятся к вопросам «а как звали того бедного парня, которого сбила пьяная женщина и который стал инвалидом?», и это все вопросы, которые я запомнил, если честно.
wataru
09.01.2023 19:29И что, даже не было ни одного вопроса, "можно ли тут туда ехать" или что-то вроде "кто вот тут может проехать первым"? Я вот что-то не верю, что не зная ни одного знака можно этот quiz пройти. Наверняка в видео знаки-то мелькали.
0xd34df00d
10.01.2023 02:38+1Вроде был один вопрос, что делать на нерегулируемом перекрёстке со stop-сигналами.
Не, серьёзно, там были очень простые квизы, цель которых скорее проверить, что ты смотрел в экран, а не что ты на такую-то часть понял правила.
wataru
10.01.2023 20:31Но это все равно не оправдывает тезис "знак X должен быть исключен из экзамена, потому что он редко встречается".
0xd34df00d
10.01.2023 21:02Я не считаю, что он должен (или не должен) быть исключён, я лишь говорю, что есть экзамены, где они на самом деле уже сегодня не включены.
wataru
10.01.2023 21:13То, что тест простой, не значит, что какие-то знаки там вообще никому не попадаются.
Zara6502
10.01.2023 15:29+1Это человек, который обладает развитым алгоритмическим мышлением, умеет писать код, знает структуры данных, когда и как их применять, умеет решать задачи. Что из этого не нужно в программировании?
Это не так. Я преподаю много лет и нет ничего хуже медалистов с регалиями, который на куче олимпиад победил и решает всё отлично и вообще молодец. Из них единицы буквально обладают теми характеристиками что вы указали.
Но алгоритмы надо применять почти везде! Не 100% времени, а эпизодически, но вы не можете наперед сказать, что вот тут вот они понадобятся, а вот тут — нет. Вот какой-то знак дорожный встречается редко. Значит ли что в экзамене на ПДД его не должно быть?
Да бросьте, я программирую с 1987 года и мне ни разу не понадобилось самому что-то писать (ассемблер на 6502 не в счёт). Всё что нужно давно есть в либах и если у вас не какой-то проект по управлению ядерным реактором на QNX+C, то достаточно написать _sort(A) и всё.
Касательно ПДД - момент в том что 99% как оголтелые изучают разборы дорожных ситуаций читая толстенные книжки. когда проще выучить тонюсенькую книжку ПДД.
Ну а недостающие знания в программировании можно наверстать позже, если они потребуются.
Вот очевидно вам, что там понадобятся:линейная регрессия, теория чисел, динамическое программирование, moving window max (прямо задачка на литкоде такая есть), фильтр калмана?
Вы столько умных слов наговорили, что я в смущении. Я вообще не понимаю что это и мне это никогда не пригодится, как и сам webrtc, я не собираюсь его переписывать или дописывать. С чего же вы решили что человек, которому интересно работать с СУБД вдруг подорвётся программировать кодеки? Даже у программиста так или иначе есть своя специализация. Невозможно знать и уметь всё профессионально, это вне рамок человеческих возможностей.
Более того, проблема с алгоритмами в том, что почти любая алгоритмическая задача допускает тупое наивное решение.
С моей точки зрения полезнее тот программист, который умеет пользоваться стандартными инструментами C# например и не пишет днями и ночами свои реализации алгоритмов, которые потом еще и некому будет поддерживать или модифицировать. Я как-то на гитхабе нашел класс по работе с изображениями определенного формата (вообще на Си две функции code/decode занимали пару экранных страниц), всё было оформлено отлично, но беда, размеры этого класса были страниц на 300.
Продуктивнее требовать знание алгоритмов при найме у всех
Абсолютно непродуктивно, так вы легко отсеиваете тех, кто никакими алгоритмами никогда не занимается, и в них не умеет, зато отлично например пишет что-то другое. Вы себя загоняете в рамки.
У меня в карьере масса примеров когда сообразительный "вася" оказывался лучше, чем дипломированный "федя",и на собеседовании "васю" я приметил как раз задавая простые ничего не значащие вопросы, так скажем - житейские. Начальник был против его найма, но я уговорил. В итоге "вася" сейчас работает за пятерых, я "федя" давно ушел, так как "не видит для себя перспектив".
Но тут задачи именно запрограммировать.
Когда задача типовая, то и решение типовое. Вы проверяете на типовые решения. А в разработке ПО (если конечно вам не нужен "тупой" кодер) нужен творческий подход и задачи не типовые появляются и решение нетиповое нужно искать. Поэтому лучше творческий и сообразительный программист, который в состоянии прочитать что такое O(N) при необходимости, нежели тот, кто кроме O(N) ничего и не знает.
Нет. И любое интервью вы пройдете таким кодом. Более того, почти никто нигде не испольует ООП на таких интервью.
Ну пройду, а как работать в команде буду?
Ключевые слова "за границей". Уверен, что существует человек из вашего региона россии, который выучил алгоритмы и получает в той же стране, что ваш брат, в 2-3 раза больше, работая в гугле.
Ну и пусть получает, видимо он пригодился на своем месте. Вопрос-то в том, что умение в алгоритмы ничего не определяет если вам эти умения некуда применять.
WraithOW
10.01.2023 15:37+3Да бросьте, я программирую с 1987 года и мне ни разу не понадобилось самому что-то писать (ассемблер на 6502 не в счёт). Всё что нужно давно есть в либах и если у вас не какой-то проект по управлению ядерным реактором на QNX+C, то достаточно написать _sort(A) и всё.
Без обид, но если вы с 35 годами опыта работаете за 300 баксов "без знаний алгоритмов" - то это лучшая реклама их учить.
В итоге "вася" сейчас работает за пятерых, я "федя" давно ушел, так как "не видит для себя перспектив".
Если учесть озвученную зп, то Вася работает за пятерых за копейки, а Федя с ненулевой вероятностью может себе позволить нормальные продукты, отпуск, технику и медицину. Так кто из них умнее-то в итоге?
Zara6502
11.01.2023 05:32-1Без обид, но если вы с 35 годами опыта работаете за 300 баксов "без знаний алгоритмов" - то это лучшая реклама их учить.
Чем плох интернет - все думают что жизнь всех людей идёт по возрастающей и абсолютно у всех одинаковая, как в семье так и в карьере. Я нигде не написал что я программист сейчас, нигде не написал что 300 баксов это моя зарплата за программирование. Я вам рассказал о том, что за то время пока я программировал, мне знания алгоритмов никак не пригождались, совсем. И моя максимальная зарплата за карьеру была 2500 баксов в 2008 году, если вы позволите, я вам не стану показывать свою медкарту и объяснять причины, по которым я сегодня рад и 300 баксов, но уверен, что "федя со знанием алгоритмов" в моей ситуации, тоже не остался бы при своих.
Если учесть озвученную зп, то Вася работает за пятерых за копейки
во-первых это было очень давно и за копейки работали оба, только вася работал, а федя страдал и отлынивал, как недооценённое чудо. Мы не знаем что сейчас с васей и с федей, финалы их карьер могут быть самые разные, но за пример взят конкретный момент и полезность конкретного человека с конкретными регалиями.
WraithOW
11.01.2023 11:31+2Я нигде не написал что я программист сейчас, нигде не написал что 300 баксов это моя зарплата за программирование.
То есть вы тут
PS: мой брат успешно работает за границей в геймдеве, но он никогда не писал сортировку пузырьком и не знает что такое коды Элиаса XD а я знаю, только у него зарплата в 20 раз больше.
сознательно умолчали о важной детали, которая нивелирует всё сравнение, и тем самым попытались ввести всех в заблуждение? Ну, у вас получилось, чем вы недовольны?
Zara6502
11.01.2023 12:22-1сознательно умолчали о важной детали
и в чем её важность? я озвучил своё мнение о том, что НЕзнание алгоритмов не мешает карьере программиста, как и знание алгоритмов. То что вы прямы как лом в чтении по диагонали - я не виноват.
WraithOW
11.01.2023 12:38+2Очевидно в том, что вы использовали это сравнение для подтверждения своего тезиса, при этом сравнение было абсолютно некорректно, а значит, не может подтверждать тезис.
Давайте я тоже сейчас скажу, что НЕзнание анатомии не мешает карьере хирурга, потому что мой знакомый учился, а я балду пинал, а теперь получаю в 20 раз больше него, умолчав, что учились мы на разных специальностях, и я вообще не врач (да и он тоже, так-то, я его придумал).
Маленький нюанс, как говорится.
wataru
11.01.2023 12:45+1Ну нет. Ваш комментарий можно было интерпретировать только так. Зачем вы вообще про свою зарплату что-то сказали, если вы не программированием занимаетесь, да и маленькая она у вас по причинам вообще никак к заниням алгоритмов не относящейся?
Zara6502
11.01.2023 19:17-1То есть я зная алгоритмы и теоретически (с ваших слов) обязательно должен получать больше, но сознательно отказался от этого в пользу другой работы? Что-то не сходится.
wataru
11.01.2023 19:54+2В смысле? Не обязательно, конечно. Индивидуальные обстоятельства индивидуальны. Но имея больше знаний, у вас больше возможностей. Да, банально, интервью в фаанги зная алгоритмы пройти легче.
faiwer
10.01.2023 17:00+2я программирую с 1987 года и мне ни разу не понадобилось самому что-то писать
Т.е. вам за всё время не пригодился ни LRU, ни binary search, ни обхода графа в ширину, ни каких-нибудь очередей, никаких DSL, никаких интерпретаторов, сложных парсеров? Чем вы занимались эти 35 лет?
"федя" давно ушел, так как "не видит для себя перспектив".
"Федя хорош. Будьте как Федя". Если в вашей конторе в месяц платят столько сколько на фрилансе платят за 3ч, странно что Федю к вам вообще занесло.
wataru
10.01.2023 17:02+1Это не так. Я преподаю много лет и нет ничего хуже медалистов с регалиями, который на куче олимпиад победил и решает всё отлично и вообще молодец. Из них единицы буквально обладают теми характеристиками что вы указали.
Не верю. Как можно зарабатывать медали и при этом: не уметь решать задачи, не уметь писать код и алгоритмически мыслить? Техника программирования внесением случайных изменений в код и проверкой результата слишком неэффективна, чтобы на олимпиадах что-то там получать. Ваше утверждение звучит как "сколько олимпийских спортсменов по легкой атлетике не встречал, никто на 3-ий этаж по лестнице без одышки поднятся не может".
я программирую с 1987 года и мне ни разу не понадобилось самому что-то писать
Во-первых, вы, не зная алгоритмов, скорее всего даже просто не заметили, что где-то можно на порядки ускорить ваши программы, применив "алгоритм". Во-вторых, эти самые алгоритмы на практике часто не про написать структуру данных с нуля, а допереть, что вот тут вместо списка можно в hash_map вот те штуки сложить, а вот тут надо вызвать next_permutation из стандартной библиотеки. Так что даже если и совсем редко требуется писать "что-то самому", знать алгоритмы надо, что бы понять, что из стандартной библиотеки и когда применять.
Я вообще не понимаю что это и мне это никогда не пригодится, как и сам webrtc, я не собираюсь его переписывать или дописывать.
А мне надо. Я работаю в гугле и этот самый webrtc пишу. Но смысл моего текста не в том, что нужно конкретно мне на конкретно этом проекте, а в том, насколько обширно и неожиданно вылезают алгоритмы. Ну вот как "взять видео с камеры, передать библиотеке-кодеку, распилить на пакеты" может быть связанно с линейными регрессиями и динамическим программированием? Но вот вылезает оно как-то.
rblaze
10.01.2023 23:57+1У меня в карьере масса примеров когда сообразительный "вася" оказывался
лучше, чем дипломированный "федя",и на собеседовании "васю" я приметил
как раз задавая простые ничего не значащие вопросы, так скажем -
житейские. Начальник был против его найма, но я уговорил. В итоге "вася"
сейчас работает за пятерых, я "федя" давно ушел, так как "не видит для
себя перспектив".Ну так собеседование в вашей компании решает совсем другие задачи: перед бигтехом не стоит проблема "найти человека, который будет годами работать за еду". Поэтому критерии отбора там другие.
Andrey_Solomatin
10.01.2023 00:58PS: мой брат успешно работает за границей в геймдеве, но он никогда не
писал сортировку пузырьком и не знает что такое коды Элиаса XD а я знаю,
только у него зарплата в 20 раз больше.20 раз? Урежте осетра.
rblaze
10.01.2023 23:45Таких узкоспециализированных людей собеседуют на довольно редкие узкоспециализированные позиции, и дают задачки более подходящие под резюме. Платят как правило меньше, потому что уйти особо некуда.
А вот если вы пойдёте на более-менее стандартную роль, то вас на интервью завернут и правильно сделают.
event1
09.01.2023 21:26+3В целом согласен, но некоторые пассажи вызывают недоумение:
А как мы знаем, хороший код - это код, который может понять даже начинающий разработчик.
Как мы знаем хороший код, это код которые решает проблему для решения которой он был написан. Неплохо, если его сможет понять даже начинающий разработчик. Но очень плохо, если он не решает проблемы.
Вы настраиваете валидацию, смотрите примеры данных в базе, смотрите бизнес-правила, и понимаете, что в условную функцию может прийти какой-то узкий набор данных предсказуемой длины.
очень точно подмечено, но
И чаще всего не имеет значение, обработаются эти данные O(1), O(N) или O(N*N) и так далее.
Этот как вообще? Не важно, обработаются данные быстро или медленно?
Если спросить программистов, что пишут бизнес-логику приложений, то не так уж много задач, где сложность той или иной функции, как-то влияла на пользовательский опыт юзера софта. Они есть, но их ничтожно мало в современных реалиях доступного железа.
Это те самые прекрасные люди из-за которых word 365 на i7 работает с той же скоростью, что и word xp на core 2 duo, который в свою очередь работает с той же скоростью, что и word 95 на первом пне? Единственный вопрос который можно им задать, это: "Как вам спится по ночам? Бесцельно сожжённые мегаватт*часы во снах не приходят?"
Однако, если мы обратимся к опытным программистам и it-архитекторам, то они явно скажут вам, что решение задач на leetcode не сделает из вас хорошего программиста
Сами по себе не сделают, но кое-чему научат. Это я вам как опытный программист скажу явно.
Finesse
10.01.2023 11:59+1> И чаще всего не имеет значение, обработаются эти данные O(1), O(N) или O(N*N) и так далее.
Этот как вообще? Не важно, обработаются данные быстро или медленно?
Речь идёт о случаях, когда для ожидаемого объема данных асимптотика не дает сколь-нибудь заметной разницы во времени ответа от приложения. Например, когда приложение вытаскивает данные по REST API за 100мс, а затем обрабатывает их за 2мс или 1мс в зависимости от алгоритмических навыков программиста.
ikostruba
10.01.2023 00:50+5Лично мой взгляд - алгоритмические задачи слабо связаны с реальной практикой разработки. У меня 15 лет опыта, работал в телекоме, автопроме, финтехе, сейчас в одной из букв FAANG. Алгоритмические задачи я нахожу чудовищно скучными и никогда не решаю их вне подготовки к интервью. Когда готовлюсь, каждый раз отмечаю, что мой рабочий опыт помогает в лучшем случае в половине задач сложности Medium, и почти никогда в задачах Hard. Для меня это иллюстрация того, что эти задачи - вещь в себе. Чтобы их успешно решать, нужно выучить ряд приёмов, которые скорее всего вы никогда не встретите за пределами Leetcode.
При этом, я считаю, что можно многому научиться через эти задачи, понятное дело, для них придется изучить структуры данных и повсеместно используемые вещи вроде сортировки и поиска. Но задачки - не единственный способ их изучить. Поэтому если вам нравится их решать - прекрасно, если не нравится - учитесь так, как вам интереснее.
VFaland
10.01.2023 21:25Из моего опыта:
1) на собеседованиях в Г чаще можно встретить Литкод Хард чем например в Амазон
2) в Амазоне вопросы явно с Литкода брать не рекомендуется, но многим влом думать-искать
3) все проблемы которые были у меня в вопросах на интервью в Амазоне встретились впоследствии в реальной работе
4) непосредственно навык скоростного решения таких проблем - не нужен. Но нужно уметь быстро писать хороший и тестируемый код и быстро распознавать алгоритмические паттерны, чтобы не велосипедить и не плодить тормозной код.
На самом деле это только часть навыков software engineer, и эффективность принятого формата интервью - вопрос спорный, но... Как то работает, а лучшего способа не придумали. "Гитхаб" и "поговорить за проекты" для бигтеха очевидно не вариант.
Andrey_Solomatin
10.01.2023 01:21Не раскрыт еще такой момент умения решать алгоритмические задачи, у вас шире выбор компаний куда вы можете пойти работать.
Существует ли зависимость между типом себеседования и возможностью для саморазвития я не знаю, думаю что если есть, то не очень сильная.
Весь оутсорс, где алгоритмических задачек почти ее бывает, я для себя закрыл. Один раз попробовал, было очень полезно, но больше не хочу. А вот в продуктовых команиях задачки втсречаются.
DIMANVAZ
10.01.2023 02:18Простите за странный комментарий,
а сейчас россиян вообще рассматривают в разные Фаанги?
Уточнение - если да, то какого уровня я должен быть?
То есть они чаще берут на позицию Джуниор или выше?
blind_oracle
10.01.2023 11:22+1Рассматривают, им пофиг.
Джуниор вряд-ли, миддл тоже под сомнением. Есть иногда интернские позиции, но больше для местных студентов.
Чтобы пройти интервью нужно уметь хорошо в алгоритмы, структуры данных и системный дизайн.
Хотя даже фаанг иногда не верх адовости интервью - я последний раз когда менял работу прошёл в одной компании раунд из 8 собеседовний, кажется. Но и платят они почти как фаанг, и кешем, без стоков.
DIMANVAZ
10.01.2023 11:31то есть фаанги берут выше мидла?
blind_oracle
10.01.2023 11:34Ну, учитывая их сложные собеседования, которые совсем не каждый синьёр-помидор, без бэкграунда в алгоритмах, пройдёт - да
KvanTTT
10.01.2023 04:29Как ни крути, но проработка этих задач точно не будет лишней при собесе в фанги-манги. Мне заниматься такой деятельностью в свободное время совсем не интересно (хватает работы), но если надумаю пойти в место, где будут очень много платить, задумаюсь о штудировании литкода.
blind_oracle
10.01.2023 11:30У меня было примерно такое же мнение (нафига оно мне, за 17 лет не пригодилось особо, всё есть в стандартной библиотеке, ...)
Потом, когда начал мучать литкод - втянулся. Реально затягивает, ну и начинаешь понимать как работают те или иные вещи, которые принимал как данность (те же OSPF с Дейкстрой, сортировки, хипы и прочие LRU)
С женой до сих пор решаем периодически, соревнуемся кто быстрее осилит ????
KvanTTT
10.01.2023 17:19Да, забыл еще сказать, что опенсорса хватает. В нем, кстати, есть задачи, где требуются быстрые алгоритмы (ANTLR), хотя вроде и так более менее понятно как их решать, просто на самом деле это не особо критично.
Что касается основной работы, компилятора Котлина, то в нем изредка попадаются алгоритмические задачи, но по ощущениям у меня чаще возникают проблемы из-за софт-скиллов, когда не достаточно коммуницирую с другими членам команды, делаю лишнее или не совсем то. Что касается хард-скиллов, то нужно уметь быстро понимать что делает код, искать баги, извлекать минимальные примеры.
vvbob
10.01.2023 08:18Польза есть на начальном этапе, когда ты изучаешь профессию, просто что-бы знать что там "под капотом", а не тупо, в режиме мартышки, дергать за рычаги всевозможных фреймворков, удивляясь потом, почему оно работает так медленно либо вовсе падает по памяти.
Для уже работающих профессионалов, это полезно примерно так-же как решение математических или геометрических задачек - тренировка для мозгов, в практическом смысле от них польза не слишком большая, если я начну в обычном рабочем проекте писать самописные реализации сортировок или что-либо подобного, то коллеги решат что либо у меня совсем кукуха отъехала, либо что я джун, каким-то способом ухитрившийся закосить на собеседовании под сеньора.
Dimsml
10.01.2023 08:30Говорят, что платным аккаунтам на Leetcode как-то дают пощупать задачки с прицелом на определённых работодателей, но как именно это работает не знаю.
Finesse
10.01.2023 12:02LeetCode знает, какие задачи спрашивают на интервью в тех или иных компаниях. За деньги он делится этой информацией с вами.
Dolios
10.01.2023 12:04На платном аккаунте:
- Доступны все солюшены.
- Даже для "бесплатных" задач (коих большинство) указано в каких компаниях они попадались на собесах.
- Задач больше, есть "платные задачи".
- Списки задач можно отфильтровать по компаниям.
- Режим "интервью" можно потренировать по задачам конкретной компании.
- Меньше стоишь в очереди при отправке решения.
Но, понятное дело, все эти списки они весьма условные. никто ничего не гарантирует, что вам попадется задача из списка.
NikolayNikT
10.01.2023 08:37Очень странная статья, похоже описана работа программиста недоучки. Что-то в описании решения задач слабо прослеживается формализация, математическое моделирование, алгоритмические модели, применимости в технологическом процессе. В основном, ищем в гугле, ютубе, лопатим литературу, так и хочется задать вопрос, а до этого полноценно обучиться не судьбы?
Refridgerator
10.01.2023 09:38А почему нет варианта — принудительно заставляли в институте? А в институте программа обучения на программиста одними алгоритмами внезапно не ограничивается.
Dolios
Голосовалка плохая. Сначала для собеседования решал, а потом уже для души. Это просто напросто интересно, в конце концов.