Comments 370
Штука в том, что ваш "инженер-реализатор" может в силу непонимания каких-то базовых вещей всадить совершенно нелепую ошибку, которая будет создавать неудобства, но видна не будет. А потом придётся искать и чинить, а то и обходить костылями.
Ну там, к примеру, проложить канализационную трубу строго горизонтально. Это примерно то, что в программировании делают люди, не умеющие в подсчёт сложности алгоритмов.
Но да, толковый прораб, следящий за ними, может выправить ситуацию.
Гипотетически, это гадание на кофейной гуще. Олимпиадник-Алгоритмист в силу знания что и какими алгоритмами можно заранее оптимизировать, может понаписать и переусложнить код так, что потом его проще будет выкинуть и полностью переписать, чем поддерживать.
Алгоритмические собеседования - это просто калька с гугла, и стало относительно стандартом в Фаангах и Американском энтерпрайзе.
Ну да, нет резона совсем уж упарываться по алгоритмам. Но уложившиеся в голове знания на уровне "а почему СНиП требует, чтобы труба шла под уклоном" – необходимость.
Нет, речь о том, что инженеру Васе даётся 100 задач обычных, на перекладывание JSON'ов, а 101 случайно попалась такая, что нужно знать про O(n). Без понимания алгоритмов, он накосячит и даже не будет догадываться об этом.
А задачи стандартизовать до конца нельзя — он же не рабочий на конвейере.
Если Вася накосячит и это никто не заметит (например, в виде слишком большой нагрузки), то значит оно и не нужно. А если заметит, то укажет Васе на проблему.
Не факт, что это будет заметно сразу. Скорее всего производительность просто будет потихоньку снижатся, пока пользователи не начнут ругаться и уходить к конкурентам. А потом пойди найди, какой же Вася и где накосячил - потому что если в компании нет алгоритмических интервью, то торомзить с большой вероятностью будет примерно все.
Люди с опытом коммерческой мне тут недавно объясняли, в ответ на вопрос, почему нельзя обойтись без опыта коммерческой разработки, что надо опыт коммерческой разработки учит просто так, шоб було, обязательно вставлять в код отдачу метрик на мониторинг и настороить пороги (и всё это приходит только с опытом), а мониторинг там уж поднимет тревогу задолго до прихода северного пушного зверька.
И я их так понял, что при наличии коммерческого опыта можно на практике алгоритмы и не знать.
Это был я кажется. И не надо перевирать меня.
Алгоритм вы же напишите? Вот чуть ниже неплохой пример того что надо написать за полчасика на собеседовании. Я напишу, если что. И на собеседовании на позицию выше джуна спрошу и то и другое. На джуна только алгоритма даже попроще чем там хватит, не вопрос. А вот на мидла надо и написать что-то такое и поболтать про отвлеченные темы вроде мониторинга.
Это был я кажется.
И вы тоже, но ЕМНИП - не один. И я скорее утрирую, чем перевираю. Впрочем, если хотите, можете высказать свое мнение по поводу того же по смыслу, но более корректно сформулированного утверждения: "в коде, написанном опытным разработчиком, наличие участков излишней сложности, по сравнению с оптимальной, скорее всего, не приведет к фатальным последствиям, потому что опыт подскажет такому разработчику по-любому заблаговременно позаботиться о наблюдаемости своего кода и ведении его мониторинга". То есть, что цель избежать кризиса можно достичь другими средствами помимо знания всеми и каждым разработчиком деталей (таких, как асимптотик) алгоритмов.
Алгоритм вы же напишите?
Лично я - совершенно нестандартный случай, сильно не похожий на массовго соискателя, поэтому не хочу заострять внимание на своей персоне. Предпочитаю рассматривать сценарии вне зависимости от личностей, личность же я считаю важным учитывать, разве что, только в плане наличия у нее достаточных оснований для своих высказываний.
Но если вам так интересно лично про меня (непонятно, правда зачем) - то за полчаса напишу (впрочем, это из моего комментария к тому посту, наверное, понятно), но проверить это экспериментально уже не получится.
По поводу того алгоритма, точнее, задачи, я уже высказался в том самом своем более раннем комментарии: что это, скорее - задача на готовность к проверке и обработке граничных условий, т.е. - скорее, таки на опыт: сам алгоритм переворачивания цифр тривиален, особенно - в варианте "по тупому"(что это означает - см. тот комментарий). Если вы считаете, что такие задачи, с подводными какмнями, надо справшивать на мидла, то тут я ничего не скажу - за полным незнанием ваших требований.
PS Если вы хотите узнать, писал ли лично я квадраты - таки писал (и ЕМНИП, тоже где-то в каментах про это отвечал). Хотя и с полным пониманием, что это квадрат, и почему ему там место. И лет пять тот код таки прожил по итогу, впрочем, там был далеко не хайлоад и даже не близко.
Случай из реальной жизни:
Вот на то чтобы поймать вот такое в реальном продакшен коде я потратил больше недели. Потом исправил меньше за день вместе с выкаткой релизов, лол. Мониторинги звенели, все как полагается. Но толку, если починить не выходит? Поставить заплатку которую надо все время поддерживать получилось, пользователи ничего не заметили. Идея заплатки понятна. Была сильно ограничена пачка читаемых данных, которые потом уходили в большой хороший батч процессинг. И сверху это все было залито железом чтобы работало в неоптимальных условиях под большой нагрузкой.
Мониторинги отработали как надо? Да. Они четко показали проблему производительности влияющую на пользователей. Помогли ли они ее решить? Нет, но это и не их задача. Защитили мониторинги продакшен от факапа? Да, они показали что есть проблема и дали время на поиск и внедрение обходного варианта чтобы пользователи не страдали.
Лично я - совершенно нестандартный случай, сильно не похожий на массовго соискателя, поэтому не хочу заострять внимание на своей персоне
Это так не работает. Мы все особые случаи. У нас у всех особый опыт. Нет коробки с дефолтными мидлами или тем более дефолтными сеньорами. Чтобы у них были дефолтные навыки и дефолтный опыт.
Но если вам так интересно лично про меня (непонятно, правда зачем) - то за полчаса напишу
Лайк. Это лично для меня критерий что с человеком можно говорить о разработке софта.
Если вы считаете, что такие задачи, с подводными какмнями, надо справшивать на мидла, то тут я ничего не скажу - за полным незнанием ваших требований.
Надо. Потому что большая часть пришедших "мидлов по резюме" это не напишет. Их надо отфильтровать. Если бы каждый мидл такое мог написать, то и спрашивать бы не стоило. Но увы.
Если вы хотите узнать, писал ли лично я квадраты - таки писал (и ЕМНИП, тоже где-то в каментах про это отвечал). Хотя и с полным пониманием, что это квадрат, и почему ему там место. И лет пять тот код таки прожил по итогу, впрочем, там был далеко не хайлоад и даже не близко.
Это нормально. Если понимаешь что и зачем пишешь, то можно писать все. В этом нет проблем.
У меня в проде тоже есть квадраты. Они там обоснованны. И перед ними стоит ассерт на количество пришедших данных. Лучше упасть сразу, а не тормозить вечность.
Мониторинги звенели, все как полагается. Но толку, если починить не выходит? Поставить заплатку которую надо все время поддерживать получилось, пользователи ничего не заметили. Идея заплатки понятна. Была сильно ограничена пачка читаемых данных, которые потом уходили в большой хороший батч процессинг.
Мои мысли по поводу. Сначала - в рамках сценария: собственно, от нынешнего мидл-разработчика с коммерчеким опытом требуется локализовать проблему - что она в либе. И q. e. d. А дальше решать ее - уже сеньору: не зря же ему столько денег платят.
Если же за пределами сценария:
/starper mode on
Я по жизни работал программистом в давние времена в мелкой фирме, то есть был, подобно "Парню из преисподней" "боевой единицей в самом себе". Причем работал не на Java (единственно что на JDK 1.2 апплет написал), а на C(++) или Delphi. А потому экспертизы у меня нет, но идеи есть. По такой беде мне на ум их несколько приходит, но насколько они к Java да ещё и последующих эпох применимы - не знаю. На C можно было бы использовать его замечательный препроцессор и подменить имя метода removeAll с помощью #define. На Delphi препроцессор был победнее, а потому получился ли бы там этот фокус - уже не скажу. Если таких мест, где вызывается removeAll, считанное количество, то можно попробовать присобачить поверх прокси или декоратор (можно ли такое в Java - не ведаю). Можно заменить вызов removeAll вызовом remove в цикле: сильно хуже не будет. есть и ещё идеи, но все они не для мидла в команде, где синьор прирыть должен, а для программиста кустаря-одиночки.
/starper mode off
Это так не работает. Мы все особые случаи.
Не, у меня - случай совсем особый.
В частности релевантный коммерческий опыт в современных стеках - 0, а опыт вообще есть, и сильно больше: если общепрограммистский - то лет двадцать с лишним, начиная с 15ВСМ-5 (машинные команды), БЭСМ-6(Алгол-60), ДОС ЕС(Фортран 4 и Ассемблер), VM/SP (Ассемблер и PL/1) - и до Delphi с C++ уровня 98/2003 (нет, быть покусанныv Александреску меня участь минула, но метопрограммированием все же побаловался).
В том числе опыт есть и в работе на дядю за деньги, не считая попыток писать и продавать программки в начале 90-х: с конца 90-х до где-то с середины нулевых. И опыт групповой работы есть - вон тут недавно дама написала, что она в некий "Квадратный метр" устроилась, а, я вспомнил, что мы с коллегой на пару для них, ещё в те годы когда это была газета бесплатных объявлений, писали для нее программу приема, приведения в божий вид и вывода текстов объявлений: я - типа, бэк (схема БД и бизнес-логика, типа, потому что от мои интерфейсы пользователям не заходили, зато с SQL и полнотой учета всяких граничных случаев было ОК), а коллега - типа, фронт (потому что у него наоборот). А вдвоем писали, потому что тогда босс в эту газету вложился, чтобы с "Руками" конкурировать, а потому поставл "срочнонах" в качестве дедлайна. Правда конкурировать не вышло, а босс нашел другой предмет для инвестиций. Ну а потом я переполз в администраторы - только не шивой многоруким или, упаси боже, эникейщиком, а целым гллавным администратором "общей практики" инфраструктуры средней фирмы - сначала "по четным", потом - на полную, потом с подчиненными - фирма росла и в одиночку там стало не справится, даже при том, что беготней по пользователям занимался другой отдел. Потом был - администратором AD+Exchange в более крупной конторе и вкусил прелестей кровавого энтепрайза. Но наступила эпоха облаков и импортозамещения, и это направление стало бесперспективным. А скучным оно было всенда - в админство-то я ушел, в основном, ради денег (ну, так вот было в середине нулевых), а так мне код писать всегда нравилось (и да, о том, что код, который не нравится, писать тоже приходится, я, как вы понимаете, я в курсе)
Не, у меня - случай совсем особый.
В частности релевантный коммерческий опыт в современных стеках - 0, а опыт вообще есть, и сильно больше: если общепрограммистский - то лет двадцать с лишним, начиная с 15ВСМ-5 (машинные команды), БЭСМ-6(Алгол-60), ДОС ЕС(Фортран 4 и Ассемблер), VM/SP (Ассемблер и PL/1) - и до Delphi с C++ уровня 98/2003 (нет, быть покусанныv Александреску меня участь минула, но метопрограммированием все же побаловался).
В том числе опыт есть и в работе на дядю за деньги, не считая попыток писать и продавать программки в начале 90-х: с конца 90-х до где-то с середины нулевых. И опыт групповой работы есть - вон тут недавно дама написала, что она в некий "Квадратный метр" устроилась, а, я вспомнил, что мы с коллегой на пару для них, ещё в те годы когда это была газета бесплатных объявлений, писали для нее программу приема, приведения в божий вид и вывода текстов объявлений: я - типа, бэк (схема БД и бизнес-логика, типа, потому что от мои интерфейсы пользователям не заходили, зато с SQL и полнотой учета всяких граничных случаев было ОК), а коллега - типа, фронт (потому что у него наоборот). А вдвоем писали, потому что тогда босс в эту газету вложился, чтобы с "Руками" конкурировать, а потому поставл "срочнонах" в качестве дедлайна. Правда конкурировать не вышло, а босс нашел другой предмет для инвестиций. Ну а потом я переполз в администраторы - только не шивой многоруким или, упаси боже, эникейщиком, а целым гллавным администратором "общей практики" инфраструктуры средней фирмы - сначала "по четным", потом - на полную, потом с подчиненными - фирма росла и в одиночку там стало не справится, даже при том, что беготней по пользователям занимался другой отдел. Потом был - администратором AD+Exchange в более крупной конторе и вкусил прелестей кровавого энтепрайза. Но наступила эпоха облаков и импортозамещения, и это направление стало бесперспективным. А скучным оно было всенда - в админство-то я ушел, в основном, ради денег (ну, так вот было в середине нулевых), а так мне код писать всегда нравилось (и да, о том, что код, который не нравится, писать тоже приходится, я, как вы понимаете, я в курсе)
А теперь возьмите стандартную болванку резюме (хотя бы с hh) и попробуйте все вышенаписанное туда упаковать. Получилось?
Ну, а к остальному мне добавить нечего.
,
Забыл про свой особый случай добавить
что за последние годы освоил современный C# и фреймворк ASP.NET Core в качестве основного инструмента - и это отражено в на моём гитхабе и в статьях на Хабре - и современный JS (вообще-то я с JS работал как админ лет пятнадцать-ldflwfnm назад - был тогда такой WIndows Scripting Ноst для работы с COM Automation, через который в системе было доступно немало, но тогда JS был другим) в качестве дополнительного - это не отражено нигде, однако имеющееся знание JS позволило бы мне, к примеру, если бы описанная ваша проблема с removeAll была бы на JS, поправить ее - там это очень просто, достаточно в условном HashSet.prototype исправить свойство по имени removeAll, и вообще, насколько я понял, такие трюки в JS являются типовыми, так что что про них стоило бы знать даже джуну).
Но это, конечно, ни разу не опыт коммерческой разработки.
Я не об этом. Исправить такую проблему c .removeAll это однострочник. Пишется за минуты. Найти где еще он нужен это тоже минуты. Простой поиск по коду покажет все места.
Настоящая проблема в том чтобы понять что квадрат и тормоза возникают именно в removeAll. Метод всем своим видом показывает что он не квадратичный. Бизнес логика развесистая, кода в ней много разного. Профайлер показывает какую-то чушь. Вызовов всяких в том числе и removeAll много, на флеймграфе ничего не понято. Вот неделя плюс и ушла чтобы понять что надо просто вызов removeAll поменять.
Про устранение я написал потому что не совсем понял, в чем там сложность: думал, что такие вызовы по всему коду раскиданы и и править их по одному в каждом месте обуродуешься.
Изолировать такую ошибку - тут таки да, нужен опыт, "коммерческой разработки" или ещё какой: люди без опыта стандартным библиотекам языка доверяют слепо (сам такой был).
Нет коробки с дефолтными мидлами или тем более дефолтными сеньорами. Чтобы у них были дефолтные навыки и дефолтный опыт.
Но тестируем мы их стандартными задачами и стандартными вопросами, смог решить стандартную задачу - лайк, хороший. Не смог - не лайк, плохой.
Я так понимаю, если привык на каждый чих метрики ставить и их отслеживать – алгоритмы будешь знать уже через несколько месяцев, причём не просто заученные из книги, а с пониманием, зачем они нужны.
а мониторинг там уж поднимет тревогу задолго до прихода северного пушного зверька
Ну вот у вас каждую неделю на 1% процент что-то ухудшается. Ну это в принципе, нормально, ведь новые фичи в код добавляются. А потом эти 1% складываются в пушного зверька.
Дык, у мониторинга, в отличе от лягушки, пороги не адаптивные. Доползло до 70% CPU - он честно предупреждение напишет, до 90% - ошибку. А там уж дело разработчиков, сделать ли "обходное решение" (так в ITSM костыль называют) струтурное ли (т.е. найти и убрать багу) или перепасовать (последнее практикуется в "Реальном ITSM").
Но мониторинг по-любому свое дело сделает: прокукарекает, и приход песца неожиданностью уж всяко не будет.
Если Вася накосячит и это никто не заметит (например, в виде слишком большой нагрузки), то значит оно и не нужно. А если заметит, то укажет Васе на проблему.
Опять, представьте, что у вас нагрузка неравномерна. Если у вас алгоритм с O(n^3), он будет нормально справляться с «обычной» нагрузкой, а когда придёт всего в 10 раз больше, он встанет колом. И как всегда это будет вечером в субботу.
Да, я говорил именно про подобные случаи.
И тут не надо каких-то топовых разрабов. Нужно, чтобы у людей базовые знания алгоритмов были отработаны до автоматизма, чтобы они не всаживали O(n²) на ровном месте.
Ну можно использовать SonarQube, который перечислит вам все места со степенной сложностью, все места, которые сложны в чтении и всё остальное. И не надо будет полагаться на кодревью. Он даже может это сделать в момент отправки кода в репозиторий. И в этот момент программист и познакомится со сложностью алгоритмов.
Если Вася накосячит и это никто не заметит <...> то значит оно и не нужно.
Такое будет только в идеальном мире, с моей точки зрения.
Я вот замечал такую последовательность событий:
Разработчики пишут сложную систему. В ряде случаев они спрямляют углы, плюс тестировщики смотрят только на частные случаи (они же не могут перебрать все, правда?).
Параллельно с этим, систему продают по B2B каналам. Другими словами - продавцы показывают всё управленцам, а не конечным пользователям.
Систему успешно внедряют, и она начинает работать. Показатели поначалу красивые, конечно.
На протяжении времени оказывается, что система работает медленно и неэффективно. Пользователи жалуются. Лет через пять некоторые из них даже становятся управленцами, а потому уже начинают иметь реальную власть, чтобы давить на переход на что-то иное.
Параллельно с этим, служба поддержки терпеливо отвечает клиентам, что Ctrl-V не работает в их html формах, что плашка "загрузка" может действительно висеть минуту, ибо мы же не гугл какой-то, правда? Ну и некоторые отчеты сделать нельзя, и это было на странице 78 контракта.
Из-за пункта 4, клиенты начинают постепенно уходить к конкурентам и систему отправляют в утиль.
то укажет Васе на проблему.
К этому моменту, эффективный менеджер Вася, скорее всего, уже работает в другой компании, так как среднее время работы на одну фирму явно меньше пяти лет. А если нет, то мало кто будет увязывать низкую производительность с уходом клиентов.
Параллельно с этим, систему продают по B2B каналам. Другими словами - продавцы показывают всё управленцам, а не конечным пользователям.
И вот тут вот у хорошего CIO (он же - директор по информационным технологиям, он же - ещё кто нибудь, тут важно не название должности, а роль) в дело вступают эксплуатационщики, задача которых - допросить пресейлов (не сейлзов - с тех толку мало) с пристратием, выяснить нелицеприятные детали и подготовить снятие лапши с ушей ЛПР, если сейлзам ее туда удалось повесить (снимать лапшу - это уже работа CIO, экспоуатационщикам это не по чину). Мне лично в бытность главадмином по инфраструктуре приходилось этим заниматься, и не один раз: да CIO у нас был хороший. Но не всем так везет с CIO, да.
И вот тут вот у хорошего CIO <...> в дело вступают эксплуатационщики
И как они код проверят? Они легко поймут, что react компонент на N элементов получает N уведомлений о новом объекте при старте программы, а потому сваливается в O(N^2)? Или они будут просто квадратики на презентации смотреть? Как они это выяснять будут?
Как будут понимать, что компонент не оптимизирован под следующую версию Java (которая будет через год), даже зная, что безопасники потребуют её обновить?
Мне лично в бытность главадмином по инфраструктуре приходилось этим заниматься
Да, от части проблем получится уйти, если работать добросовестно. Вот только понять, что система будет работать неэффективно после года работы (ибо накопится условная история) - сложно. В презентациях код показывать не будет, да и админ вряд ли будет его смотреть и анализировать. А далее условная форма будет тормозить по 5-10 секунд на каждом поле, что приведет к тому, что люди будут ворчать. И, конечно же, сисадмин не заметит проблемы, ибо ему не надо вбивать эти документы постоянно. Более того, сисадмину опасно замечать проблемы в процессе эксплуатации, так как он же и подписался под этим решением.
Но я соглашусь, что определенную долю проблем можно попытаться отсечь заранее. Именно потому крупные фирмы (те же банки) лет 20 лет назад стали уходить от outsource решений и стали готовить свои команды.
И как они код проверят?
По крайней мере, они зададут нужные вопросы, даже если не знают как работает код - shit, который happens при наличии опыта, даже чисто в экспоуатаци, просматривается. Вопросы, конечно, будут не про код, а типа: "для какого количества пользователей вы тестировали?" (а лучше - "внедряли").
Ну, а лично мне было легче тем, что я из программирования пришел и лет за несколько успел и на чужие ошибки насмотреться, и, тем более - на свои: в те времена основное по времени занятие программиста уровнем хоть чуть выше формошлепа на Delphi было искать свои ошибки (не знаю, как там сейчас, когда сплошь фрейворки да Q&A, да умение быстро печатать, по некоторым слухам, может быть в списке требований).
В реальности на 1 задачу на ассимптотическую сложность будет 10 задач на проверку данных пользователя, от обычных проверок на незаполненое поле до всевозможных SQL-инъекций и XSS. Но по опыту это почему-то спрашивают сильно реже.
Нет, речь о том, что инженеру Васе даётся 100 задач обычных, на перекладывание JSON'ов, а 101 случайно попалась такая, что нужно знать про O(n).
Совсем даже не обязательно она будет необычной, можно поймать такое и во время перекладывания json.
Олимпиадник-Алгоритмист в силу знания что и какими алгоритмами можно заранее оптимизировать, может понаписать и переусложнить код так, что потом его проще будет выкинуть
Эта проблема решена обязательным код-ревью. В том же гугле любой код обязательно проходит ревью коллегами. И если ревьюверу непонятно, или он считает, что можно написать проще, он об этом скажет и олимпиаднику придется все переписывать самому сразу. А если в компании все такие Олимпиадники-Алгоритмисты и "непонятный и зарнее оптимизированный код" друг друга они итак понимают, то никакой проблемы тут нет.
Этим же механизмом лечится единственная, на мой взгляд объективная проблема олимпиадников - плохо читаемый олимпиадный код. Уже через 2 недели новый работник сам пишет хороший, понятный код даже без пинков от коллеги.
У нас после ревью еще будет нагрузочное тестирование на копии промсреды. И оно покажет то, чего на тестовых серверах просто не увидишь (там данных кот наплакал - сотня-другая тысяч записей, ну полмиллиона, а на проме 50 миллионов только по клиентам, а по счетма и клиентским данным - там уже сотни миллионов записей).
И на НТ выдадут по самые помидоры - тут скуль неоптимален (и вообще ту же информацию можно по другой таблице получить, она не такая тяжелая), тут лишнее переоткрытие файлов, тут каждый раз создается временный объект (а это тоже время). Могут даже предъявить за излишнее использование динамической памяти - почему тут 100500 выделяется-освобождается куча мелких кусков постоянно...
Я в другой ветке про это тоже написал. В гугле тоже почти все тоже покрыто performance тестами и если что-то где-то ухудшается, это чинят. В каких-то проектах часть presubmit проверки меряет, например, размер исполняемого файла и это ревьюверам выдается.
И оно покажет то, чего на тестовых серверах просто не увидишь
Всё верно - разработчики тестируют на одном подмножестве сценариев, а вы - на другом. И остается надежда на то, что пользовательский сценарий через месяц будет такой же, как и Вы предсказывали.
Двойное бинго:
код-ревью. В том же гугле любой код обязательно проходит ревью коллегами. И если ревьюверу непонятно, или он считает, что можно написать проще, он об этом скажет и олимпиаднику
Brad Fitzpatrick called the Token API a garbage factory back in 2015, so I’m certainly not the first to make this observation.
Тут тебе и Гугель, и код-ревью, и "звезды" от мира сего. Но всё осталось как есть. Кстати ещё один пример долгосрочных последствий архитектуры (здесь - интерфейса библиотеки, API). (cc в продолжение @BugM)
По вашей ссылке на "garbage factory" нет доступа. Пока понял, что какой-то элемент дизайна стандартной(?) библиотеки в языке go кому-то не нравится и, хоть его и очень удобно использовать, это не самый оптимальный способ что-то там сделать.
Насколько там был непонятный код, или насколько его лучше можно было написать из статьи непонятно. Может, народ там взвесил плюсы и минусы и решил, что удобство использования тут важнее.
Более того, чтобы исправить проблему тут автор изменил АПИ этой библиотеки. Т.е. там не код был кривой и неоптимальный, а дизайн интерфейса наложил ограничения. А вот дизайн интерфейса в стандартной библиотеке, насколько я могу предполагать, утверждался наверно аж целой комиссией. Т.е. это не к программисту вопрос, а к комитету языка.
Гугл чтоли РФ IP забанил?.. А так в целом все верно.
func (dec *Decoder) Token() (Token, error) {Brad Fitzpatrick: this API is a garbage factory :/
Russ Cox: Not the end of the world. A clean API and consistency with encoding/xml's clean API is more important here. I expect people to use it to get to the position they want in the stream and then call Decode.
Короче, суть в том, что каждый символ при парсинге проходит через токенизатор. Сколько людей участвовало в XML API - вопрос открытый (склоняюсь к не-комитету), но очевидно, что Фитцпатрика не было там.
Т.е. там не код был кривой и неоптимальный, а дизайн интерфейса наложил ограничения.
Да, как бы и о том и о другом речь. Соптимизировать автор смог и с сохранением API, но выжать все соки -- только поломав интерфейс.
Удобное АПИ часто важнее скорости работы.
Для очень многих задач есть библиотеки поудобнее или побыстрее. Когда к себе тащишь выбираешь что нужнее. Это нормально.
Что как делать в стандартной библиотеке языка вопрос для комитетов. Все сразу может и не получиться и нужен какой-то компромисс.
Гугл чтоли РФ IP забанил?.. А так в целом все верно.
Нет, но мой впн был забанен. Без него все открывается. Там именно то, что я и предполагал. Контраргумент к "фабрике мусора" - более понятное и простое API тут важнее.
Соптимизировать автор смог и с сохранением API, но выжать все соки -- только поломав интерфейс.
Автор сам пишет, что оптимизация в основном засчет избавление от выделений памяти, которые он там пол статьи объясняет - и что они неизбежны при таком интерфейсе.
Олимпиадник-Алгоритмист в силу знания что и какими алгоритмами можно заранее оптимизировать, может понаписать и переусложнить код так, что потом его проще будет выкинуть и полностью переписать, чем поддерживать.
А откуда противопоставление олимпиадников и прикладных программистов? Получается что если человек понимает алгоритмы, то он автоматически не может разобраться в новом фреймворке и архитектуре?
Алгоритмические собеседования - это просто калька с гугла, и стало относительно стандартом в Фаангах и Американском энтерпрайзе.
В фаанге алгоритмика от силы 10% времени занимает, там проверяют и опыт/тех скилы и алгоритмику, а не что-то одно.
Просто олимпиадников годами натаскивают именно на write-only код
Это какие-то тысячные процента всех программистов. В остальных случаях люди достаточно хорошо понимают и алгоритмы и умеют писать нормальный продакшн код. В Фаанге том же чистых олимпиадников фактически нет. Другое дело что на том же хабре почему-то уже считается обойти дерево или написать сортировку олимпиадным уровнем.
Олимпиадник-Алгоритмист в силу знания что и какими алгоритмами можно заранее оптимизировать, может понаписать и переусложнить код так
Кстати, с этим успешно может справиться и любой другой разработчик. Более того, чаще переусложнение идет от отсутствия опыта или знания: например когда человек плохо понимает, как система работает под капотом, например, но успешно справляется с частными случаями.
Другой пример: ошибка в дизайне проектирования вылезла уже после того, когда всем было бы очевидно, что легче переделывать.
Ну да, в среднем и в целом эти приколы на собеседованиях не нужны. Сама недавно столкнулась, кстати, с другой стороной этой медали, так сказать. Чувак спрашивал меня что и как называется, при том что принимал на сольную работу, где у меня не будет тиммейтов, для которых я должна быть удобной. Такой ужас, я дропнула сразу))
но видна не будет
Потому что мы «не знаем того, чего не знаем» — если мы чего-то не узнали, то о существовании этого мы можем даже не догадываться. Плюс есть определённые выбросы в задачах, которые ставят инженеру — это же не рабочий на конвейере.
Поэтому его знания должны покрывать зону типичных рабочих задач с большим нахлёстом — чтобы на случайно попавших сложных задачах он не накосячил.
Так дело не в среднем образовании "инженеров реализаторов", а конкретно в этом вот инженере, который базовые вещи как раз обязан знать.
Также как и известные проблемы в популярных алгоритмах, которые были допущены "крутыми инженерами"
Так вот, число первых, то есть «технологических» инженеров — сильно меньше, чем вторых.
Потому что позиций меньше
Их квалификация на порядок выше, чем вторых
Как порядки будем считать? Я вот с этим не согласен.
Инженер-алгоритмист не пишет алгоритмы каждый день. Там вообще бывает, что за год пару раз надо придумать алгоритм, который придумывается и анализируется командой, с консультациями. И это делается не за день и не за два. В тему конкретно погружаешься, почитываешь литературу, экспериментируешь.
Это просто инженерная работа. На этой позиции.
Да, конечно на такую позицию лучше собеседовать человека у которого с математикой хорошо еще до приема на работу, но не значит, что он в десять раз умнее. Он просто потратил свое рабочее время на эту задачу, в нее погружался, готовился и делал. От катастрофических ошибок он не застрахован.
Ну да. Алгоритмы в том объёме, в котором они реально нужны – это не rocket science, а просто немного знаний и навыков, только доведённых до автоматизма – когда ты не задумываясь выбираешь алгоритм за O(n log n) вместо алгоритма за O(n²) (и только очень хорошо обдумав можешь остановиться на втором, объяснив причину в комментариях к коду).
Да, блин, самая большая проблема в том, что каждый под мифической "базой" имеет ввиду своё, притом, обычно, чётко не определённое и больше похожее на "то, что я знал, когда работал на схожей позицией".
Есть совсем уж классическая база в виде Кнута. Имеет смысл изучить, не ошибёшься)
А доказатеельства в Кнуте тоже имеет смысл изучить? А то ведь он математик, доказательства любит бескорыстно, а потому их у него много. А обычным работникам они без надобности почти вегда.
Imho можно пренебречь.
Круто, конечно, уметь доказывать и самому всё выводить, но 500 заученных доказательств в этом не сильно помогут.
Есть смысл понять общую идею — так легче «сжать информацию» и запомнить. Люди очень плохо запоминают бессвязную информацию — у нас ассоциативная память, которой нужны связи, связи и связи. Если вы понимаете основную идею доказательства, то легко можете вывести факт сами.
В математике процесс создания доказательства состоит из двух фаз: нахождение идеи и формализация. Вот формализация нужна сильно реже, чем понимание общей идеи.
Нахождения идеи - чего? Если доказательства - то для работы нафиг не нужно. Если идеи свойств алгоритма - типа такого: Heap Sort обычно медленнее Quick Sort, но зато асимотика у него гантированно быстрее квадратичной, а с Quick Sort можно и на квадрат нарваться - то такие вещи надо уметь запоминать. А как именно запоминать, с помощью какого такого мнемонического правила - это индивидуально, дело конкретного человека. Кому-то, может, и идея доказательства полезна будет для этого, но в общем случае это не нужно.
Все так и умение писать субоптимальные алгоритмы важна, но не надо требовать от человека написать полностью правильный алгоритм за 15-30 минут, если такой же в реальной работе пишут и отлаживают дня 3. Имею буквально свежайший опыт. Ну да, не учел кое-чего, не очистил кое-что в одном месте, но суть-то была верная. Хотя буквально через 10 минут после собеседования увидел вче свои недочёты. Но не прошёл.
По крайней мере на тренингах по интервью в фаангах, что я видел, учат не требовать только одно идеальное решение. И вообще там отчет по интервью пишется большой и там куча разных параметров - далеко не "задачу решил без ошибок/не справился". Не учтя что-то где-то вы получите не максимальный бал возможно. А если даже с небольшими подсказками найдете свой недочет попозже, то наоборот получите больше баллов за тестирование кода. Плюс, этих интервью до 5 штук дают. И потом комитет все отчеты смотрит и решает, что делать, чтобы такие казусы устранять.
Конечно, не все интервьюверы - идеальны, а не в фаангах, которые бездумно копируют тренд, может вообще все с ног на голову быть поставлено. Но если вас завернули за мелкие косяки, то это не проблема алгоритмических интервью как таковых, а тараканы конкретного собеседующего.
Я говорил не про "успеть за 15 минут", а про рефлекторное понимание, какой алгоритм или структура данных в данном месте подойдёт. Типа вот здесь дерево, здесь двоичная куча, а здесь и просто массивом обойдёмся, при переполнении будем его удваивать – амортизированная сложность нормальная будет.
Чтобы поменьше было такого, что заложил не то, а когда оно выстрелит – весь в мыле бегаешь и переписываешь полпрограммы (тут, кстати, ещё привычка хорошо изолировать куски кода важна, чтобы если уж заменять – то только маленький кусочек).
Понятное дело, что понимать алгоритмы это заметно лучше чем не понимать)) Но уметь в принципе делать дело намного важнее чем быть крутым алгоритмизатором. Слабый (но не совсем донный, конечно же) алгоритмизатор всё равно решение рано или поздно вымучать сможет. Грубо говоря, IQ не самое важное.
Тут не IQ, и большой объём знаний не нужен – сколько там этих алгоритмов? Оглавление Кнута + краткая справка по каждому поместится в тоненькую брошюрку, а детали реализации всегда подсмотреть можно (если вдруг готовая не подошла).
Тут – представление об алгоритмах, общая насмотренность и выработанные рефлексы типа "нельзя здесь O(n²), есть же дерево/куча/хэш".
Вы правы ... предпоследний проект, который я допиливал, оказался из таких ... проект писался до меня года 3, технически это были несколько инстансов, которые должны были между собой синхронизиравать разные справочники/данные ... в начале кто-то запилил туда алгоритм однонапрвленной синхронизации данных, а через год, как я понял, программисты и аналитики подумали что если все работает, то можно больше не думать и стали задействовать этот же код, ьез модификации для обмена данными в двух направлениях - в результате получилось, что данные просто гоняются по кругу между отдельными инстансами приложения независимо от действий пользователей. И это лепили года 2 - при этом никто особо ничего не замечал (ни аналитики, ни тестеры), а всякие зависы списывали на баги сети... пришлось почти полгода выправлять код, что другие лепили из дерьма и палок года два-три в несколько лиц.
Отвечу на этот коммент, так как интерфейс хабра видимо делали те самые разработчики которые не задумываются об алгоритмах и других вещах и "проложили прямую трубу" в интерфейсе добавления нового комментария.
Делить на две категории - не правильно. Все мы разные. Нет на самом деле никаких высших каст разработчиков ядра, СУБД и т.п., есть такие же люди, которые просто (возможно) немного умнее, наработали себе бэкграунд и экспертизу, может где-то за счёт какой-то черты характера воспринимают мир иначе чем автор поста, или средний работник Сбера с зарплатой x3 от Яндекса (в котором просто адекватно оценили конкретного человека, а с деньгами там у тех кто хорошо проходит ревью всё норм).
Алгоритмы - хороший способ измерить скиллы программиста. Что бы кто не говорил, но программы вообще то из алгоритмов состоят. Даже простой поход в базу, или рендеринг шаблона в html - это всё алгоритмы. Если ваш уровень - код который делает эти два действия последовательно или в цикле, и вы никогда не задумывались о более сложных вещах, то вы на очень низком уровне по этой метрике.
Стоит ли собеседовать дальше такого кандидата - зависит от множества факторов. Если задача - отчитаться что в отдел за месяц наняли триста трактористов, то не обязательно разбираться сколько из них умеют управлять трактором.
Алгоритмы - хороший способ измерить скиллы программиста. Что бы кто не говорил, но программы вообще то из алгоритмов состоят.
"Целое не является суммой своих составных частей" (из игры Civilization IV ;-) ). А потому разработчику надо уметь не только в алгоритмы. А часто - и не столько в алгоритмы, потому что есть библиотеки, в которых эти алгоритмы уже реализованы.
Хотите, доведу вашу мысль до абсурда?
"Кто бы что бы ни говорил, но программы-выообще-то из конструкций конкретного языка программирования состоят, лексических и ситаксических. А потому знание синтаксиса конкретного языка программирования - это само по себе хороший способ измерить скиллы программиста". Согласны?
Да такие вот водопроводчики реализаторы потом делают слив без гидрозамка. Потому что физика не нужна.
Вы таки будете смеяться, но я с этим столкнулся год назад, переехав в Белград. На съёмной квартире хозяин сразу предупредил – мол, закрывай пробку в мойке на кухне, а то пахнет, это тут обычная проблема. Заглядываю под мойку... Ну вы поняли. У него на глазах делаю эрзац-сифон из гофры, проблема решена.
Надеюсь хозяин намотал на ус. Сам тоже так делал и не раз)) Но бывает и не смешно, когда отсутствие гидрозамка, например, вбетонировано в пол - как было у меня на съемной квартире в тайланде. Там слив душа в полу пришлось таки затыкать но это не особо помогало.
Да, это совсем жесть.
У нас в офисе чуть иначе: душевая, в ней гидрозатвор есть – но здание 40-этажное, и проектировщики прошляпили проблему с перепадом давления. В результате при ветре есть неиллюзорный шанс опустошения сифона (его просто высасывает в канализацию) с последующей вонью.
Итог – трубы забили нафиг, пользоваться душем нельзя, сушу там зонтик :-)
Чтобы не проложить канализационную трубу горизонтально технологи описали как это делать правильно и расчитали минимально необходимой уклон в градусах, а чтобы было еще проще и удобнее, то в сантиметрах на метр.
В конце концов, можно докупить больше серверов или поставить немного больше памяти — и это будет гораздо более экономически оправданны решением, нежели тратить годы на разработку «оптимальнейшего» решения
Я бы на месте потребителя оплачивал бы расширение памяти или покупку нового сервера из кармана того разработчика, который реализовал решение, работающее 0.15с вместо возможных 0.1с. Такой подход заставил бы задуматься о том, что необходимо заботиться об эффективности кода, который ты пишешь.
Ну или просто - заказчик получает продукт, который тормозит. Поставщик говорит "у вас сервер слабый, нужен апгрейд". Ок. Вычитаем стоимость апгрейда из стоимость разработки.
Собственно говоря, разработчик не обязан уметь быстро реализовать те алгоритмы, которые уже реализованы во множестве библиотек. Но он обязан знать как они работают и чем отличаются. Когда и где какой более эффективен. И использовать именно его, а не тот, что первым на ум придет или к которому они привык.
Сейчас приходится много кода ревьюить. Иногда вот просто все отлично. А иногда оторопь берет - ну вот как так писать можно? Два цикла там, где все у один укладывается это еще не самое страшное.
В целом - ну вот чуть-чуть мозг включить и сразу будет работать на 15-20% быстрее. При абсолютно тех же затратах времени на разработку.
заказчик получает продукт, который тормозит
А зачем он принимал продукт, не соответствующий требованиям?
В целом - ну вот чуть-чуть мозг включить и сразу будет работать на 15-20% быстрее
Люди ленивые. Если можно сэкономить мозг - сэкономят.
А зачем он принимал продукт, не соответствующий требованиям?
А его убеждают в том, что иначе никак, только так. Хоть это и неправда.
Люди ленивые. Если можно сэкономить мозг - сэкономят.
Ага, при этом на чужое прям все на ... изойдут "тормозное! ресурсы жрет!" Родной, а ты сам-то как пишешь? Вот прям все до такта выжимаешь? Или "херек-херак и в продакшн"?
Вот недавно переписывал модуль... Ну, блин, ну слов нет. Просто, что называется, левой ногой писано. Полностью переписал. Стало компактнее, понятнее и работает в четыре раза быстрее. Не потому что я умный такой, а потому что написано было вообще из рук вон плохо. А написать сразу аккуратно - не пришлось бы сейчас время тратить...
Я понимаю, приходится иногда повозится с оптимизацией, что-то накручивать - кеширование какое-то, еще что-то... Ну там да... И то можно сразу подумать и что-то такое предусмотреть.
Ладно последние пару лет ввели обязательное нагрузочное тестирование на копии промсреды. Там хоть откровенный треш не проходит уже. Все полегче.
Родной, а ты сам-то как пишешь? Вот прям все до такта выжимаешь? Или "херек-херак и в продакшн"?
Кто там все возводит в абсолют - ситхи или сикхи? ;)
Хм... а вдруг этот модуль можно было ещё на 15-20% быстрее сделать?
Вы бы на всякий случай отложили заначку, а то вдруг другой программист сделает быстрее и придётся возвращать деньги заказчику.
Слишком идеализировано. В реальности же нужно учитывать:
Читаемость (иногда лучше пожертвовать производительностью в угоду читаемости)
Простота (иногда лучше пожертвовать производительностью в угоду простоты поддержки)
Дедлайны и давления бизнеса не тратить на это времени
Польза бизнесу (иногда есть альтернативы сэкономить 100 000$ бизнесу и распыляться на экономию на спичках (CPU+RAM) за 500$/мес может быть нерационально с точки зрения финансов)
иногда лучше пожертвовать производительностью в угоду читаемости
не надо противопоставлять. Производительный код может быть читаемым.
иногда лучше пожертвовать производительностью в угоду простоты поддержки
и простым
Дедлайны и давления бизнеса не тратить на это времени
"Вам чтобы быстро, или чтобы рукава одинаковые?" (с)
иногда есть альтернативы сэкономить 100 000$ бизнесу и распыляться на экономию на спичках (CPU+RAM) за 500$/мес может быть нерационально с точки зрения финансов
Если ваш процесс начал в период пиковой нагрузки тормозить так, что по всей стране миллионы клиентов не могу расплатиться картой вашего банка - "нет ответа от банка" - сколько вы потеряете? Реальный, кстати, случай. Именно дефект производительности, проявившийся в период пиковой нагрузки.
Тут кроме прямого финансового ущерба есть еще репутационный + возможны штрафы от регулятора (время недоступности системы нормируется минутами - пара часов это уже серьезное ЧП). А регулятор наш в количестве нулей в штрафах особо не стесняется.... Ладно хоть не подняли вопрос о приостановлении действия лицензии "за неисполнение обязательств перед клиентами" (если на банк уже зуб точат, такое может стать последней каплей запросто).
Подпишусь под каждым словом. Более того! Уже слышал от подобных "сборщиков кубиков" фразу "Программист не должен смотреть в код применямых библиотек" не единожды. Увы, но тотальное и хроническое (за мои 40 лет в ИТ) снижение входного порога становится всё более агрессивным. В моей молодости должность называлось математик(!)-программист и требовало знание не только алгоритмов или оценки сложности, но и целых разделов математики для доказательства(!) корректности примененного аргоритма.
Из недавнего: "У Вас не достаточные знания в Postgres, а наша компания ищет разработчика для .. проектирования новой БД на нем. У Вас в резюме только MySql" А то, что проектирование новой БД требует не столько знания нюансов той или иной реляционной СУБД, сколько знание реляционной алгебры в целом .. то видимо тимлидам команды невдомек ни с какой стороны.. ни в описании вакансии ни в ответе.. :(
И это один из ведущих игроков рынка. Увы.
Увы и ах... У меня стаж в разработке, конечно, поменьше (всего 30+ лет), но практически все время в тех областях, где требовалась высокая эффективность и быстродействие. Ну так получилось. Возможно поэтому от кода, который с первого взгляда неэффективен, просто корежит на ревью.
А для проектирования БД надо да, реляционная алгебра + теория нормализации. На курсах этому не учат, это уже серьезно, там еще и база нужна.
В моей молодости должность называлось математик(!)-программист и
требовало знание не только алгоритмов или оценки сложности, но и целых
разделов математики для доказательства(!) корректности примененного
аргоритма.
Так и сейчас есть сферы где это необходимо: разработка систем искусственного интеллекта, большие данные, программы сложной обработки графики и видео и т.п. низкоуровневые и математически зависимые вещи.
Но это узкие ниши, большинство разработчиков клепают формы, и перекладывают данные с базы на фронт и обратно готовыми библиотеками.
большинство разработчиков клепают формы, и перекладывают данные с базы на фронт и обратно готовыми библиотеками.
При этом они все пользуются готовыми библиотеками, БД и прочим, что разработано "нишевыми программистами" и еще хотят чтобы все это работало быстро и правильно.
БД ещё полбеды.. пользуются чужими пакетами для связи с БД, натыренными с гитхабов, даже не вникая чем тот или иной пакет плох или хорош, для какой специфики и круга задач автор его наклепал .. пофиг! "программист не должен смотреть в кода пакета" .. финиш тут. Главное не код, им важно поддерживается пакет сию или уже нет (sqlx уже полгода без изменений .. блин, а если в нем нет ишью, что - пробельчики в код вставлять что-ли авторам?) и .. сколько звезд насобирал пакет на гитхабе (берем этот пакет, у него звезд больше, а то что "этот" пакет на 3/4 содержит совершенно не нужного кода для вашей задачи .. ну и чО? Не, бизнес раскошелится на новое железо! .. сколько этого раскошеливающегося бизнеса позакрывалось под таким давлением ..).
Вот это - реально грустно.
большинство разработчиков клепают формы, и перекладывают данные с базы на фронт и обратно готовыми библиотеками
Как Вы думаете, сколько лет развития AI ещё потребуется, чтобы надобность в таких разработчиках отпала? А первых из "узких ниш" AI вряд в обозримом будущем заменит. Вывод?
Не знаю. Потому что AI не обладает опытом и здравым смыслом, чтобы отличить те 10-20 случааев, которые стандартны, от одного нестандартного. Проявляется это в склонности AI фантазировать при отсутсвии решения. Как быстро удаствя к AI прикрутить здравый смысл (и получится ли это чисто количественным наращиванием параметров) - это мне неведомо. Возможно, что для успеха внедрения AI придется поменять процессы разработки - как для успеха внедрения машин в промышленности потребовалось поменять процесс изготовления вещей - с ремесленного производства на мануфактуру.
отличить те 10-20 случааев, которые стандартны, от одного нестандартного
Ну так это и не требуется. Мы же говорим сейчас именно о замене только тех программистов, которым "алгоритмы не важны". А здравый смысл есть у аналитиков, которые непосредственно из своей постановки по "перекладыванию данных с базы на фронт и обратно" получат готовый код и смогут его протестировать.
А кто этот поток фильтровать будет и по каким признакам? Сейчас вот, к примеру, фильтровать, похоже, не получается, а потому - высокий порогог вхождения в отрасль, от чего стонут и вайтишники, которые через порог перелезть могут, и бизнес, которому перелезших через порог таки не хватает.
Не понял о каком потоке речь. Если о результатах работы AI - то аналитик, тестируя результат.
Поток - задач, которые надо решить. Постфактум - результат - тоже фильтровать можно. Но я о другом. Сейчас в реально разработке не получается разбить на части задачу так, чтобы ее куски можно было бы поручить джунам (в промышленности это была бы мануфактура) - это видно по состоянию рынка труда. Почему вы уверены, что удастся разбить на части задачу, чтобы поручить части AI
PS Фраза "аналитик, тестируя" у меня в голове как-то не сочетается со знакомыми мне аналитиками. Но, возможно, мне на жизненном пути не попадались хорошие аналитики, которые умеют и в аналитику, и в код.
Ещё раз. Если алгоритмы программисту не нужны, то, AI вполне таких заменит. Если нужны - возвращаемся к теме статьи.
Я, кстати, наоборот, не встречал аналитиков, не способных протестировать результат по своей же постановке. Где Вы таких видели?
А если нужны, но редко, тогда как? Вы тут IMHO ложную дихотомию продвигаете: либо алгоритмы нужны для всех (основной массы) задач, либо не нужны совсем. Жизнь сложнее.
PS Про аналитиков. Это было давно. И в конторах, для которых производство ПО было побочным делом. Аналитики там реально вобще были обычно пятым колесом в телеге. Если вообще были. В реале программисты, которые работали совершенно самостоятельно, каждый над своим проектом, договаривались с заказчиками сами.
Вы тут IMHO ложную дихотомию продвигаете: либо алгоритмы нужны для всех (основной массы) задач, либо не нужны совсем.
Вы ничего не перепутали?
https://habr.com/ru/articles/774682/comments/#comment_26171358
Аналитики там реально вобще были обычно пятым колесом в телеге. Если вообще были.
При чем тут случай, когда аналитики выполняют свои прямые обязанности - не занимаются постановкой задач?
Ещё раз. Если алгоритмы программисту не нужны, то, AI вполне таких заменит.
Не перепутал - см. выделение. И вообще речь я веду идет о таком положении, когда с задачей из реального мира, имеющей ценность для потребителей, целеком AI не справится, и нужно задачу бить на куски, с частью из которых справятся формошлепы/джейсонмуверы сейчас и AI - в ближайшем будущем.
Так вот, индустрия в целом сейчас не умеет так разбивать задачу и выделять из нее куски для обработки их менее квалифицированным персоналом/AI.
Есть, конечно, вариант, что AI сможет целиком решать задачу из реального мира - но что-то я сомневаюсь, что это прекрасное будущее наступит сколь-нибудь скоро.
PS И, похоже, словом аналитики мы тут называем разные вещи. Ну, и бог с ним, тогда, я больше не буду об этом.
Нет давайте все же вернемся к чудовищной для меня логике, которая из фразы "Как Вы думаете, сколько лет развития AI ещё потребуется, чтобы надобность в таких разработчиках отпала? А первых из "узких ниш" AI вряд ли в обозримом будущем заменит. Вывод?" привела к следствию, что
либо алгоритмы нужны для всех (основной массы) задач, либо не нужны совсем.
Или даже из фразы "Если алгоритмы программисту не нужны, то, AI вполне таких заменит. Если нужны - возвращаемся к теме статьи."
Тут явно звучит утверждение об обратном, что алгоритмы в общем случае необходимы. А те задачи, где они не нужны, вполне по силам AI.
Обвинение меня в полном идиотизме и демагогии я так просто не прощу. У меня в лексиконе вообще нет понятий "для всех" и "не нужно совсем".
Обвинение меня в полном идиотизме и демагогии я так просто не прощу.
Дык, значит, я вас неправильно понял. Или вы меня. ОК, уточнение принимается. Но вернемся к нашим баранам - вам и вашему утверждению.
Я утверждал, что индустрия не умеет разделять задачи на простые и сложные, например - на те, где эти самые алгоритмы не нужны и где без них не обойтись. И это утверждение, в отличие от перспектив AI, можно проверить. Можете что-то возразить?
Далее: про все остальное, что там насчет лет развития AI, про это я сказать не могу: "Сегодня не все могут смотреть в завтрашний день. Вернее, не только лишь все - немногие могут"(с). Я - не могу. Ни и вы тоже, наверное, не можете, не так ли? А к чему тогда тот ваш аргумент из будущего, если он в принципе не проверяем?
Единственно что я могу предположить - что простые задачи AI решать сможет быстрее (но это не точно). И, кстати, какие задачи для этого будущего AI окажутся простыми, в частности, как разделения задач на простые для AI и сложные связано с необходимостью применять алгоритмы для решения задач - это я тоже не знаю. Это будет ясно, только когда будет AI.
Так что, кого там заменит AI - я даже рассуждать не хочу.
Однако в скорое наступление эпохи AI-разработчиков я не верю, учитывая нынешнее состояни отрасли разработки, когда никого из мастеров- разработчиков невозможно сколь-нибудь массово заменить подмастерьями-джунами - которых много и которые сильно дешевле: то есть AI в этом нынешнем состоянии отрасли быть способен должен заменять полноценных мастеров, иначе не взлетит.
Короче, если замена разраюотчиков AI станет возможной, то, я полагаю, заменят всех разработчиков, безотносительно знания алгоритмов. Но это проверить, конечно, нельзя.
Я утверждал, что индустрия не умеет разделять задачи на простые и сложные, например - на те, где эти самые алгоритмы не нужны и где без них не обойтись. И это утверждение, в отличие от перспектив AI, можно проверить. Можете что-то возразить?
Любой тимлид, распределяя задачи на доски своей команды, ежедневно разделяет задачи на простые и сложные, специфичные и не очень, требующие разработки алгоритма или нет. Это его обязанность вообще-то.
Единственно что я могу предположить - что простые задачи AI решать сможет быстрее (но это не точно).
Точно то, что он уже их решает. Если постановка, написанная аналитиком, уже является алгоритмом (что норма для простых задача), то дальше AI справится без особых проблем.
никого из мастеров- разработчиков невозможно сколь-нибудь массово заменить подмастерьями-джунами - которых много и которые сильно дешевле: то есть AI в этом нынешнем состоянии отрасли быть способен должен
заменять полноценных мастеров
У Вас самого эта фраза конгнитивный диссонанс не вызывает?
Или Вы искренне считаете, что если лаборант не может заменить профессора, то робот, заменяющий лаборанта должен уметь заменять профессора?
Или все же автоматизация затрагивает, в первую очередь, наиболее простые операции и вытесняет наименее квалифицированный персонал?
Любой тимлид, распределяя задачи на доски своей команды, ежедневно разделяет задачи на простые и сложные, специфичные и не очень, требующие разработки алгоритма или нет. Это его обязанность вообще-то.
Вы как-то читаете, что мной написано, весьма альтернативно. Вы мне тут про процесс зачем-то задвигаете, а я писал чисто про результат. А результат такой, что на практике выделить сколь-нибудь существенную долю кода в постые задачи, посильные специально обученному человеку-джуну, не получается. Вам это разве не очевидно? Зачем тогда про процесс писать, который результата не дает?
Точно то, что он уже их решает. Если постановка, написанная аналитиком, уже является алгоритмом (что норма для простых задача), то дальше AI справится без особых проблем.
В сухом остатке: алгоритмы для AI какой-то дополнительной сложности не представляют. И разработчики будут (или не будут) вытеснены AI вне зависмости от того, знают ли они алгоритмы. Собственно, вы подтвердаете мое предположение выше. А вот ваше утверждение в одном из предыдущих комментариев "Если алгоритмы программисту не нужны, то, AI вполне таких заменит " - получается неверны. Готовы за него покаяться и перестать ездить по ушам за алгоритмы?
У Вас самого эта фраза конгнитивный диссонанс не вызывает?
Нет, я имею привычку восстанавливать очевидные ступени логического рассуждения, а вы - то ли не умеете (вряд ли), то ли не хотите (более вероятно, т.к. вам не хочется признавать себя непраым).
Или все же автоматизация затрагивает, в первую очередь, наиболее простые операции и вытесняет наименее квалифицированный персонал?
Теоретичеки - да, но в данном случае - нет: отсутсвует достаточное количество простых операций, чтобы их имело смысл вытеснить: ну, не умеет отрасль в их выделение.
Тут есть прямая аналогия с заменой средневекового ремесленного производства на машинное: вряд ли бы в веке XVIII-XIX получилось бы сделать машину, которая полностью заменяет мастера. Но, к счастью, чуть раньше производство научилось выделять более простые операции и поручать их людям менее квалифицированным (это называлось мануфактура).
Так вот, нынешняя разработка до стадии мануфактуры ещё не доросла, там производство остается ремесленным, а потому надо заменять мастера-ремесленника целиком. Ну, или делать ему удобные инструменты - но это уже другая история, не про вытеснение.
на практике выделить сколь-нибудь существенную долю кода в постые задачи, посильные специально обученному человеку-джуну, не получается. Вам это разве не очевидно?
Я вообще искренне считаю, что любая апелляция к очевидности - ключевой признак демагогии.
В моей практике простые задачи для джунов, не знакомых с алгоритмами, встречаются чрезвычайно редко.
Но в статье ведь доказывается, что моя выборка не репрезентативная и, на самом деле, подавляющему большинству разработчиков знание алгоритмов не требуется. Я же лишь рассматриваю следствия из этого утверждения. И одно из этих следствий - возможность заменить AI разработчика, которому "алгоритмы не важны".
А детали того, каким образом сейчас джунам, не знакомым с алгоритмами, удается выделять посильные для них задачи - это уже вопрос не ко мне, а к автору статьи.
Я вообще искренне считаю, что любая апелляция к очевидности - ключевой признак демагогии.
Вы, конечно, враве наводить тень на плетень - но это будет именно оно. Оно ведь действительно очевидно, при малейшем, самом поверхностном, знакомстве с рынком труда.
Но если вам нужно доказательство, то посмотрите на рынок найма джунов/вкатышей и пр. - он прямо как в песне времен моей молодости: "Толпы идиотов осаждают рай, но не всех пускают" ((с) Облачный край, "Шире круг"). Так что, пожалуйста, хотите доказательство очевидного - вот оно вам. Ну, а из этой очевидности уже вытекаяет, что экономическго смысла заменять таких разработчиков нет - потому что заменять, в общем-то, там некого.
А детали того, каким образом сейчас джунам, не знакомым с алгоритмами, удается выделять посильные для них задачи - это уже вопрос не ко мне, а к автору статьи.
Да хоть к кому угодно. Это на нынешнем уровне развития производительных сил просто невозможно в сколь-нибудь массовом масштабе, и это видно по состоянию рынка труда. Если бы было возможно - то вряд ли наниматеели отказались от такой хорошей возможности сэкономить бабло. Так понятно?
В нашем случае задача аналитика написать FSD по согласованному BRD, потом протестировать поставку на соответствие с FSD, отдать ее на бизнес-тест, далее - на нагрузочное тестирование и далее на внедрение (план внедрения, план отката...) Т.е. полное продвижение поставки от разработчика до прома.
У нас компонентное тестирование (первый этап - тестирование поставки на соответствие FSD) лежит на аналитике. Да, есть тестировщики, но они автотестами занимаются. А ручное тестирование на аналитике.
Я вот в последнее время с аналитиком работаю который еще и код понимает и под отладчиком умеет. Т.е. человек может под отладчиком пройти сомнительный тесткейс и сказать - "вот тут ошиблись, надо это условие вот так поменять". Прямо конкретно по коду.
Но это, конечно, исключение.
С чего бы аналитикам вообще смотреть на ваш код? У них другие задачи. Есть вход - есть выход. Они могут подтвердить что выход имеет смысл и посчитан верно. А что там у вас хоть факториал им вообще все равно. Выход верный - значит с их точки зрения все работает правильно.
Ага, а ещё вы тут вспомните историю интересную, которую вы мне тут недавно приводили, где недостаток производительности вылез в совершенно невинно выглядевшем коде из-за фичи (ибо баг документированный есть фича) в системной библиотеке. IMHO она тут в тему.
Зачем аналитику смотреть на код?
Они могут подтвердить что выход имеет смысл и посчитан верно. А что там у вас хоть факториал им вообще все равно. Выход верный - значит с их точки зрения все работает правильно.
Именно так. И, так как выше было заявлено, что для решения подобных задач "алгоритмы не нужны", то больше ничего не требуется. Или приходим все же к тому, что алгоритмы нужны. Выбирайте.
Математические доказательства корректности программ были сладкой мечтой в 80-е годы. Практическую пользу так и не продемонстрировали.
Практическая польза есть, и несоменная: Вы можете объяснить свой алгоритм другому программисту и вы можете быть в нем уверены. Для чуть более сложных алгоритмов понимание его и формальное доказательство - фактически идентичны.
Для чуть более сложных алгоритмов понимание его и формальное доказательство - фактически идентичны.
Точно? Мерджсорт я думаю вы понимаете. Он достаточно прост чтобы его объяснить неглупому школьнику.
Теперь посмотрите его формальное доказательство. Оно вообще тоже несложное. По меркам формальных доказательств несложное.
А потом посмотрите на формальное доказательство Квиксорта. Я думаю вы этот алгоритм тоже понимаете. Доказательство там по настоящему взрослое. Попробуйте понять его.
Вот поэтому формальные доказательства и не взлетели.
Мы наверно о разном уровне говорим. Совсем в формализм упарываться - конечно не надо. Но ввести инварианты, и показать, почему операция слияния выдает сортированный список и так же простые вычисления, показываюшие что там log n этажей и суммарно все это удовольствие будет O(n log n) - это вполне себе математическое и формальное доказательство.
С квиксортом тоже - ввести инвариант (в зависимости от метода разбиения разный) и все.
Формальное доказательство алгоритма означает абсолютно конкретную штуку. Математическое доказательство вашего алгоритма как любой теоремы.
То что вы написали это даже близко не доказательство. Доказывать как бы надо все. Вот это "очевидно" не работает. И базовые штуки доказаны. Остальное мы обычно просто на их основе строим.
Сложные штуки построенные на основе доказанных базовых доказать обычно тоже можно. Но сложно. И не то чтобы нужно. Даже софт спутников не доказывают. Что про наши перекладыватели джейсонов говорить. Не стоит оно того.
Доказательство через инвариант - вполне себе формальное. Там нет никаких "очевидно". Как нет и записи вроде "M - это множество..." и всяких математических формул. Зато есть, допустим "после каждой итерации цикла по i первые j числа в массиве меньше равны Pivot, числа c j по i - больше Pivot, а остальные числа остались на своих местах".
Точно меньше? Точно больше? Докажете что это так? Для любого входного значения надо доказывать конечно же. Без множества сложно как-то. Сортировка это операция над множеством в конце концов.
Остались на самом деле остались если не их не трогали. Это подойдет.
Формальные доказательства они сложные не потому что кому-то делать нечего. Они просто такие есть. Доказывать вообще сложно.
Точно меньше? Точно больше? Докажете что это так?
Легко. В цикле есть if. Если A[i] > pivot, то вот в цикле просто увеличивается i. Числа до j не поменялись, числа j..i-1 тоже не поменялись с прошлой итерации и там инвариант выполняется. Число Ф[i] удовлетворяет инварианту. Если A[i] <= pivot, то там делается swap j+1 и i. Увеличивается j. Числа до j-1 остались с прошлой итерации, новое число a[j] - по проверенному условию удовлетворяет инварианту. На мето i попало число, которое на прошлой итерации было после j, значит тоже инварианту удовлетворяет.
Вообще, конечно, можно это все в виде леммы и тероемы оформить и по индукции доказывать, но в такой формализм не обязательно закапываться.
но в такой формализм не обязательно закапываться
В этом-то и дело, что чтобы убедить компилятор формально верифицированного языка нужно закапываться
Могу сразу сказать где у вас возникнут трудности:
"Если
A[i]" Доступ кA[i], нужно показать, чтоiкорректный индекс"не поменялись с прошлой итерации" -- итераций нет, нужно переделывать на рекурсию
"делается
swap" -- данные иммутабельные, нужно писать свой swap и доказывать, что все остальные элементы остались на своих местах"
j + 1" -- доказать, чтоj + 1корректный индекс"Числа до
j - 1остались с прошлой итерации" -- прошлой итерации нет, при рекурсии нужно требовать доказательство корректности входных данных
Если интересно -- я могу дать названия книг и несколько сайтов с формальными доказательствами. Можете попробовать оформить ваше доказательство
В этом-то и дело, что чтобы убедить компилятор формально верифицированного языка нужно закапываться
Мы о разных вещах говорим. Я не считаю, что формально ферифицировать программы специальными языками - стоит. Это действительно очень муторно. Я лишь говорил о том, что программист должен хотя бы сам себе логически обосновать почему вот этот код работает.
А потом посмотрите на формальное доказательство Квиксорта. Я думаю вы этот алгоритм тоже понимаете. Доказательство там по настоящему взрослое.
Формальное доказательство алгоритма означает абсолютно конкретную штуку. Математическое доказательство вашего алгоритма как любой теоремы.
Вы, наверное, имеете в виду конкретно доказательство, подходящее для верификации. Обычное-то математическое доказательство должно быть довольно простым - с использованием индукции по длине массива (которую при верфикации, конечно, не применить).
Тут пару лет назад доказывали, что gcd корректен. https://0xd34df00d.me/posts/2020/09/agda-wf-rec.html
Формальные доказательства это сложно. Это сложнее чем математические доказательства, потому что приходится писать на "математическом ассемблере"
Из личного опыта: я неделю потратил пытаясь доказать корректность частичной реализации printf (поддерживает только %u и %s). На обычном языке на написание и проверки времени бы ушло не более часа
Акцент был сделан не на это. Взлетели или нет. Писалось за другое: когда-то это было штатным требованием для трудоустройства. А теперь про это даже не знают "про что это", но .. тоже "погромист".. падение "уровня входа" катастрофически влияет на КАЧЕСТВО результата - того ПО, которым пользуются миллионы. Откройте ЛЮБОЙ веб-сайт. Люблой. Посмотрите инспектором запросы к серверу, сообщения в консоли, сопоставьте ЭТО с тем, что видно на экране .. и расскажите "где тут эти мегабайты?"
А теперь представьте, что Вы уехали в деревню и в ней нет ничего, кроме модемной связи пусть даже продвинутой 56кбод.. за 19200 молчу, молчу..
Для чуть более длинных алгоритмов математические методы доказательств просто погрязли в сложности, забуксовали и умерли.
Практическую пользу так и не продемонстрировали.
Ну вот я сейчас работаю над программой, проводящей трансформации директив #include в C++ файлах. В конторе этих файлов 8 миллионов, группа наша из 4 человек, соответственно мы можем справится с потоком рекламаций из примерно 100 ошибок. Вы можете примерно посчитать, с какой точностью должен работать алгоритм, сколько там должно быть девяток.
Соответственно, практическая польза — я утону в потоке сообщений об ошибках или нет.
____________________________
То есть, это всё сильно зависит от области. От того, можете ли вы бросить 10 тыс безымянных Вась на ручную обработку или нет.
Программист не должен смотреть в код применямых библиотек
Это даже в "перекладывании джейсонов" не всегда работает. Иногда быстрее пробежаться с отладчиком по коду зависимости, например, чем перерывать тонну документации в поисках того единственного параметра, который внезапно ломает что-то вроде бы не связанное.
У каждой sql БД общий +- синтаксис, но есть сильно свои особенности. Так что если ребятам нужны специалисты по конкретной БД - это вполне оправдано, т.к. не надо ждать пока кандидат втянется, изучит нюансы и т.д., им нужно, чтобы был готовый спец на данную позицию. Иногда это может быть и не сильно нужным, но тут мы можем только гадать.
Иначе через год эксплуатации выяснится, что не был учтён какой либо нюанс и что-то можно сделать оптимальнее, но для этого потребуется простой сервиса и затраты сисадмина, разработчиков. И всё потому что дали задачу тому, кто ещё не готов на все 100%.
Как к примеру в mysql нужно понимать разницу между myisam и innodb или особенности партиционирования.
Верно, у каждого инструмента есть свои особенности, тем они и различаются. Разделы по тюнингу и оптимизации достаточно обширны на любой СУБД. Но! Ни в вакансии ни в ответе кадровика .. нет НИ СЛОВА за Реляционную Алгебру! Как знание нюансов раскладки и применения, скажем партицирования или особенности индексации тем или иным способом или наличие/отсутствие триггеров спасет такую команду от проектирования в стиле 1НФ, без знания "что это за зверь"?
Нюансы той или иной БД важны конечно же, но кмк "после" реляционной алгербы а не вместо..
Есть два кандидата. Один знает реляционную алгебру, дрогой реляционную алгебру плюс конкретную, необходимую для работы СУБД. Кого выберет наниматель? Или вы априори считаете, что вы среди соискателей единственный РА знали?
А нафига там вообще эта ""реляционная алгебра"? Первую-то реляционную, типа, БД с SQL (SEQUEL) делал ведь не теортик Кодд, который эту алгебру придумал, но с которой нормальным людям работать было почти невозможно, а практики Бойс с Чемберленом, которые придумали язык запросов, с которым уже нормальным разработчикам было работать реально.
PS И что-то меня терзают смутные сомнения, что в эотй реляционой алгебре вообще есть индексы - низкое средство, не имещее отношения к возвышенной математике реляционной модели (но это не точно).
А без индексов в реальном SQL жизни нет, сами понимаете.
Да я в душе не гребу, нужна ли она реально или нет, я в БД как свин в апельсинах. Чувак вот утверждает, что до усрачки нужна.
Но суть-то не в этом, а в самой (а)логической цепочке. Он свято уверен, что работодатели, увидев знатока реляционной алгебры, должны, роняя тапки брать его на работу. А если не берут - то они дураки и ничего не понимают. А если "в ответе кадровика нет ни слова про линейную алгебру" - то вообще идиоты.
Речь была не за наличие или отсутствие иных кандидатов вообще, а за текст ответа ХР и текст вакансии - ни там ни там не было ни слова про "проектирование БД" и соответствующие скилы, кмк, требуемые для этого!
А то, что проектирование новой БД требует не столько знания нюансов той или иной реляционной СУБД, сколько знание реляционной алгебры в целом
Это если что-то простое делать. А если лезть чуть поглубже (даже не в потроха), то уже все значительно сложнее. Я в свое время читал оракловый performance tuning guide, это были 2 хороших тома. И для каждой СУБД будет так же.
Эти перфоманс гайды, точно рекомендуют денормализацию таблиц БД до 1НФ всегда? Что-то мне кажется, что это "не так" и существенно. Вопрос проектирования структуры БД - это в первую очередь, вопрос выделения "сущностей" и их взаимосвязей. В частности, "таблицы связи" .. у того же Кодда и многих последователей есть много примеров за "бинарность" связи и .. нигде нет прямого запрета на "N-арные связи", больше того, арность связей рассматривается на бинарных КАК ПРИМЕР.. Много проектов СУБД с таблицами связи больше двух сущностей? И .. что там в перфоманс гайдах про многомерные индексы и линки к сущностям более двух?
Эти перфоманс гайды, точно рекомендуют денормализацию таблиц БД до 1НФ всегда?
А вы прочитайте, и узнаете. Если опыта нет, о чем разговор?
В каком разделе предлагаете найти про 1НФ?
System MySQL Performance Tuning
Balance the Four Main Hardware Resources. Storage. ...
Use InnoDB, Not MyISAM. ...
Use the Latest Version of MySQL. ...
Consider Using an Automatic Performance Improvement Tool. ...
Optimize Queries. ...
Use Indexes Where Appropriate. ...
Functions in Predicates. ...
Avoid % Wildcard in a Predicate.
Chapter 14. Performance Tips
Table of Contents
14.1. Using
EXPLAIN14.1.1.EXPLAINBasics 14.1.2.EXPLAIN ANALYZE14.1.3. Caveats 14.2. Statistics Used by the Planner 14.2.1. Single-Column Statistics 14.2.2. Extended Statistics 14.3. Controlling the Planner with ExplicitJOINClauses 14.4. Populating a Database 14.4.1. Disable Autocommit 14.4.2. UseCOPY14.4.3. Remove Indexes 14.4.4. Remove Foreign Key Constraints 14.4.5. Increasemaintenance_work_mem14.4.6. Increasemax_wal_size14.4.7. Disable WAL Archival and Streaming Replication 14.4.8. RunANALYZEAfterwards 14.4.9. Some Notes about pg_dump 14.5. Non-Durable Settings
Простой пример: ВУЗы, группы, студенты, предметы и оценки.
Как будем проектировать БД? Группа - это атрибут студента или отдельная сущность или отдельная таблица связи студентов? А только ли студентов, если предметы изучаются группами, но могут быть нюансы - "персональные курсы"? Какова арность связи?
Как ни странно, но правильная БД будет та, которая удобно(!) позволяет отвечать на конкретные запросы стоящей задачи. И какая лежит в основе СУБД - вопрос вторичен.
И только далее идут "нюансы", например как будем партицировать ту или иную сущность? Будем партицировать по периоду обучения или по группам? .. смотря чего хотим оптимизировать.
Ранняя оптимизация - вредна.
При чем тут ваша молодость? 40 лет назад, точно так же, как и сейчас, были и программисты, и математики-программисты. Последних всегда было немного в силу высоких квалификационных требований. А потребность в коде возросла на порядки. Для бизнеса же лучше хоть какой-то код, чем вообще никакого.
По поводу БД - надо понимать разницу между "я умею плавать" и "я знаю плавать". Тимлид, который вас собеседовал, разницу эту усвоил, причем скорее всего на своем горьком опыте.
По поводу БД - надо понимать разницу между "я умею плавать" и "я знаю плавать".
Тут есть нюанс: плавание - это навыык мышечный, там мало знать а надо наработать координацию движений. А работа с БД - нет. Там без тренировки навыка обойтись можно, знаний хватит - ну, разве что, работать получится поначалу немного медленнее.
Насколько "поначалу" и насколько "немного"? Вы можете конкретизировать? Там может весь проект на год, а тут человеку ещё въезжать в тему ХЗ сколько. А главное - при выборе "знания" или "знания+навык" - какого кандидата вы бы выбрали? Я вот на своем опыте убедился, что брать кандидата на голых знаниях - плохая идея.
Кстати, мозг, как и мышцы, требует навыка. Мозг он какбы нейросеть, а не детерминированный вычислитель, на том и живем. И одна из основных фишек мозга - стереотипизация, которая тренируется. Те порой довольно сложные последовательности действий и рассуждений, которые у тренированного мозга происходят в бессознательной области за недетектируемо малое время, на голых знаниях придется прокручивать в сознательной области пошагово.
Ну, лично я в свое время в реальный Interbase въехал очень быстро, благодаря этим самым голым знанииям. И даже стал за пару месяцев основным экспертом по нему - умеющим в подзапросы и т.п., превзойдя в этом окружающих коллег. Облегчало задачу, правда, то, что в Interbase кроме базового SQL-92 почти ничего больше не было. Ну, и со знанием теории у меня все было тики-так.
Ну и со свобоным временем было хорошо - проект, на который меня брали, сначала впал в летаргию, а потом сдох. Ну, и по этой причине я себе нашел занятие - сделать скрипт, который при планировавшейся миграции из Paradox в Interbase чистил бы данные (а это было надо - там в данных было, например, целых 24 наименования станции метро "Преображенская площадь").
Даже если ваша история - правда, вы предлагаете работодателю верить, что произвольный соискатель сможет так же?
Я работодателю ничего не предлагаю. Это - чисто его риск.
Тем более, что в той истории нанимателя (конкретно, начальника программистов, которого все звали Андрюша - сам босс в такие мелочи не лез, хотя и в программирование умел, чуть-чуть) тогда больше интересовало, умею ли я в Delphi, а SQL - это так, бонусом.
Эта история тут - для иллюстрации, что можно в тему на достаточном уровне, имея только голоые знания, въехать быстро.
У Вас не достаточные знания в Postgres...
У Вас в резюме только MySql
Я думаю, вам отказали по какой-то другой причине, а это просто формальная отговорка.
За 40 лет стажа можно было научиться понимать такие вещи.
Снижение уровня входа в ит не всегда плохо. Это значит, что продукт ит становится легче в понимании. А ситуация, когда продукт могут понять только математики, да ещё и с специальными навыками может тормозить прогресс.
Тот же персональный пк. Раньше для его запуска нужно было много знать. А сейчас в любой лавке на рынке используют пк. Прогресс.
Я бы на месте потребителя оплачивал бы расширение памяти или покупку нового сервера из кармана того разработчика, который реализовал решение, работающее 0.15с вместо возможных 0.1с
Это должно работать и в обратную сторону. Если договорились, что сервис должен держать 100к rps на Xeon 2288, а разработчик делает код, который держит на Pentium, то разница - в карман разработчику. Тогда к вам выстроится очередь олимпиадников, готовых сорвать куш на жётско оптимизированном ассемблерном коде с развёрнутыми циклами и сбежать в закат, а кому это потом поддерживать - не их дело.
Ну, или вы говорите - хочу 100к rps на Xeon 2288, все смотрят, качают головой и проходят мимо, и вам приходится снижать планку требований.
В конце концов, можно докупить больше серверов или поставить немного больше памяти — и это будет гораздо более экономически оправданны решением, нежели тратить годы на разработку «оптимальнейшего» решения
Я что-то этой фразы в статье не нахожу. Автор, вы ее убрали при редактировании?
Но не могу пройти мимо и вставить свои 5 копеек.
В фаангах, такие масштабы, что "докупить больше серверов" - это огроменные деньги. А сервера эти итак уже некуда ставить - новые датацентры строить не успевают. А память нельзя докупить, потому что ее у поставщиков физически больше нет.
Поэтому помимо юнит и подобных тестов, многие части покрыты и performance тестами, и если что-то где-то ухудшается, это стараются чинить.
Потом, это знание алгоритмов - это не "тратить годы на разработку оптимальнейшего решения". Это просто давать вот такие вот интервью. Итак от кандидатов отбоя нет, а так хоть какой-то объективный критерий появляется.
В фаангах, такие масштабы, что "докупить больше серверов" - это огроменные деньги. А сервера эти итак уже некуда ставить - новые датацентры строить не успевают. А память нельзя докупить, потому что ее у поставщиков физически больше нет.
И не только в фаангах. Смотрю по нам - банк, центральные сервера. Никаких облаков. Все "во внутреннем периметре". Сервер, на котором мы работаем -
IBM Power E980
• 120 процессорных ядра Power9
• RAM (Оперативная память) - 12Тб
• LAN (Сетевые контроллеры) - 10Гигабит
• Storage - 400Тб на SSD
• Operation System: IBMi7.4
Стоит он... Да фиг его знает сколько стоит. Несколько сотен килобаксов точно стоит. А в нынешних реалиях вообще проблемно просто так купить...
А клиентская база растет постоянно Когда на удаленку уходили в марте 20-го, была задачка одна прошуршать по всей базе - тогда было 36млн клиентов. Сейчас, насколько знаю, порядка 50млн...
Задач на оптимизацию очень много - старые модули, которые 5-7 лет назад с запасом укладывались в отведенное временное окно, сейчас уже не укладываются. Приходится переписывать, что-то придумывать...
Есть даже термин у нас "дефект производительности промсреды". Это когда о сопровождение что-то типа такого прилетает:
"Коллеги, сервис *** за последние 5 недель увеличил потребление процессорных ресурсов в 3 раза!!!
Он уже является 2-м по величине сервисом после *****.
В качестве альтернативы мы рассматриваем перенос запуска сервиса на резервный сервер, но там есть лаг по отставанию до 10 мин.
Заказчикам сервиса это может не понравиться :("
И с этим надо срочно что-то делать.
И подобного прилично прилетает от сопровождения - они постоянно процессы мониторят на сервере - кто долго выполняется, кто ресурсы жрет как не в себя и т.п.
Так а какой смысл иметь 1 гипермощный сервер, когда можно разложить в кластер на несколько серверов?
Навскидку - когда транзакция проходит в основное хранилище создаём в условную кафку событие и далее уже все неприоритетные сервисы, которые не работают непосредственно с баблом (траты, зачисление) её вычитывают к себе.
Плюс какой-нибудь крон для проверки, что все транзакции попали в кафку.
Накладные расходы на обмен данными между узлами кластера - просто ну сильно больше, чем когда все данные сразу в одной здоровенной памяти лежат.
Мы же говорим про банковскую сферу. Там всё, что не текущий год-два вообще на архивный сервер, что не требует высокой производительности и частых обращений можно вынести, нет?
И какие там объемы данных гоняются, что условного гигабита не хватит? Не фоточки же. (Хотя они тоже могут быть, но это явно не забота центрального хранилища транзакций).
И какие там объемы данных гоняются, что условного гигабита не хватит?
Одно дело, когда база, живущая прямо тут же в железе, выдает тебе сразу по 'SELECT ' по номеру счета и другое - когда это все проходит через десяток сериализаций-десереализаций на (микро)сервисах и потом по сетевым интерфейсам.
Миллисекунды накапливаются.
А так - смотрим в табличку 'Основные показатели развития национальной платежной системы'. За 2022 год только по картам - 69298 млн операций. Это, если я с арифметикой не ошибся 2197 операций в секунду в среднем, равномерно размазанном по времени. И каждая операция далеко не один запрос в базу и не одно сообщение.
Ну да, это по всей платежной системе и в каждом конкретном банке только сильно меньшая часть. Но там же не только операции по картам а вообще много чего еще происходит.
В общем, если надо быстро - то приходится таки вот железки иметь.
Смысл в том, что данных очень много. И они очень разнородные. Банк - это не только счета-проводки, но и клиентские данные (не поверите, но только адресов у клиента штук 5-6 разных типов может быть, а еще несколько ДУЛ - документов удостоверяющих личность). А еще риски (репутационные, страновые, региональные...), есть "запреты". У клиента могут быть "субъекты" (всякие доверенные лица и т.п.) у которых тоже данные.
Есть комплаенс со своими заморочками - списки росфинмониторинга которые регулярно приходят и их надо раскладывать по БД, а потом прогонять всех клиентов на совпадение (по ряду параметров - ФИО+ДР для ФЛ или наименование для ЮЛ, ДУЛ для ФЛ, ИНН, адреса...) с субъектами списков и формирования стоп-листов. Выливается это условно в сравнение 50млн клиентов с 300-500тысяч субъектов списков (а субъект списка - это "Она же Анна Федоренко, она же Элла Коцнельбоген, она же Людмила Огуренкова, она же..., она же Изольда Меньшова, она же Валентина Понеяд" - несколько имен/наименований, несколько ДР, несколько ИНН, несколько ДУЛ и т.п.). Формально - каждого с каждым.
Есть еще обязательная отчетность.
Есть уведомления клиентам по всяким разным поводам типа "Проверка действительности ДУЛ по сроку для владельцев корпоративного пластика" (на самом деле там десяток разных проверок) с рассылкой уведомлений о том что срок действия ДУЛ истек или истекает через ... дней.
А еще всякие тарифы, лимиты, кредиты-депозиты, проценты...
И еще огромная куча всего-всего разного. И его реально много. И все это должно работать быстро. Потому что одновременно крутится десятки тысяч бизнес-процессов.
А еще это должно быть меганадежно.
А еще там не может быть никаких облаков. Все внутри закрытого периметра.
Про закрытие банковского дня (EOD - end-of-day) в течении которого тоже огромное количество процессов идет уже молчу...
Навскидку - когда транзакция проходит в основное хранилище создаём в условную кафку событие и далее уже все неприоритетные сервисы, которые не работают непосредственно с баблом (траты, зачисление) её вычитывают к себе.
Все это было у мелких банков. Но работало очень медленно и там свои заморочки типа - есть счет, на счете 1000р. К нему привязано две карты. На каждой отражается остаток по карте 1000р. Платишь одной картой 1000р - на ней остаток становится 0. А на второй все еще 1000р (основное хранилище - т.н. "кешир", транзакция там, пока кто-то ее заберет оттуда...) Платишь второй 1000р и через несколько часов оп-па - влетел в технический офердрафт. На счете -1000р.
Для крупных банков, работающих в режиме реального времени это недопустимо.
Так что не все там так просто. И да, Сервер не один. Их там 2-3 штуки + горячий резерв на который можно в любой момент переключиться за считаные минуты если что не так пошло. Но, повторюсь, объемы информации, количество процессов (десятки тысяч параллельно) и операций (сотни миллионов в сутки) вынуждают думать за эффективность.
И это только "центральные системы". Где на 90% mission critical. Все второстепенное вынесено на внешние системы - их тоже несколько десятков разных. Там уже business critical - попроще все.
Так а какой смысл иметь 1 гипермощный сервер, когда можно разложить в кластер на несколько серверов?
Статья именно про это. Если Вы хотите спроектировать систему так, чтобы она эффективно работала на кластере, а не на одном сервере, то Вам будет необходимо знание алгоритмов, технологий, а также наличие тех самых soft skills, кругозора в айти мире (чтобы не выбрать тот же Питон для крупного модуля, когда есть языки со строгой типизацией) и так далее.
В противном случае получится долгострой, ибо постоянно будут встречаться неудачные решения, которые не позволят добавлять новые и новые функции.
С одним сервером всё намного проще. Например, можно брать блокировки (а децентрализованная система скажет спасибо такой идее), можно не напрягаться с eventual consistency, а использовать строгую согласованность и так далее.
Я бы на месте потребителя оплачивал бы расширение памяти или покупку нового сервера из кармана того разработчика, который реализовал решение, работающее 0.15с вместо возможных 0.1с.
Точнее, на месте потребителя вы бы оплачивали вместо покупки сервера дополнительное время работы разработчика, требуемое на оптимизиацию кода с 0,15 до 0,1с. Ну, или время разработчика, который умеет сразу писать такой код - а оно тоже дороже стоит, ибо не только лишь все в это умеют, ресурс этот более дефицитный, а потому на рынке стоит дороже. То есть дополнительные затраты - на разработку вместо на дополнительный сервер - у вас все равно бы были, только другие. А ещё ведь есть затраты на дальнейшую модернизацию, которые зависят от того, насколько удобен для понимания код. А удобство для понимания и эффективность выполнения (по времени, памяти и т.п.) кода - это те самые противоположности, которые хоть едины, но между собой борются.
Как эффективнее совместить все эти противоположности - это вопрос, для каждого предприятия, и вопрос конкретный. И если в этом вашем банке такие экономически оправданы затраты именно на эффективность выполнения, то где-нибудь в вебе - ну, совсем не всегда. Каждое прежприятие должно искать свой баланс. А баланс в нынешней системе управления экономикой устанавивается рынком и конкуренцией на нем. Потому что рационально рассчитать и директивно установить баланс не получается. Если чо, в СССР (помните такой?) пробовали делать именно так - но получалось обычно, как известно, плохо.
Собственно говоря, разработчик не обязан уметь быстро реализовать те алгоритмы, которые уже реализованы во множестве библиотек. Но он обязан знать как они работают и чем отличаются.
Напрашивается вопрос: а почему бы не завести каталог алгоритмов и реализаций? Чтобы любой джун мог посмотреть и выбрать? "Хоть безумная идея, но не ругайте сгоряча"(с) - может, на этом получится и бизнес сделать?
Хотел вам возразить, что очень важны затраты времени на разработку. Потом прочитал ваше последнее предложение. Сначала, на долю секунды подумал, не возражать, но потом понял, что надо!
Как это у вас получилось, что "при тех же затратах"? Вы же говорите, что сначала код был "плохой". У этого есть причина. Пример задачи - что-то делаем с базой данных, дергая каждый раз из нее SELECTом разные записи, сравниваем, дергаем другие. Можно оптимизировать написав длинный сложный запрос с JOINами.
Но плохой, неоптимизированный код часто бывает проще придумать, он более естественнен для нашего человеческого ума. Вот программист его и придумал и закоммитил. Если вы хотите, чтобы он дольше думал - на то чтобы думать, читать документацию, дебажить хитрый код - надо время. А это - лишние затраты на разработку.
Или, можно нанять более толкового спеца, который не пил пиво на лекциях.Да, Чак Норрис эту же задачу сделал бы правильно и даже быстрее, но он и стоит дороже.
Вы же говорите, что сначала код был "плохой". У этого есть причина. Пример задачи - что-то делаем с базой данных, дергая каждый раз из нее SELECTом разные записи, сравниваем, дергаем другие. Можно оптимизировать написав длинный сложный запрос с JOINами.
На самом деле есть много возможностей сделать одно и то же. В нашем конкретном случае, где язык поддерживает как встроенный SQL, так и прямой доступ к БД.
Можно дергать выборку по одной записи, можно дергать блоками по 1000 (например) записей - это быстрее.
Можно часть логики из SQL выдернуть на постобработку (например, лианеризовать запрос, убрав оттуда все агрегатные функции, избавившись от group by, order by по неиндексируемым полям и делать все это в процессе потоковой обработки - практика показывает что так можно в 3-4 раза ускориться). Один из простейших примеров приводил тут
У меня был случай, когда решение "в лоб" давало время выполнения 3 секунды. При требованиях уложиться в 300мсек. А "если включить мозг и подумать", то получилось реализовать решение, работающее 150-200мсек. Но это если подумать...
"Вася с курсов" просто скажет - это невозможно (реально были такие случаи - "невозможно потому что в фреймворке этого нет"). Для более-менее грамотного человека, привыкшего работать головой, а не тупо лепить из кирпичиков типовые решения, это просто "займет чуть больше времени".
Так приходим к неожиданному выводу, что более-менее грамотный - ценнее! Но беда в том, что он и дороже. Потому что этот неожиданный вывод понимают и в Сбере и в Яндексе и в Гугле и в СМУ-6 и Ростов-опт-шин-торге и все хотят более опытного заманить к себе высокой зарплатой и бесплатными ананасами. Тех же самых затрат на разработку не получается.
Два цикла там, где все у один укладывается это еще не самое страшное.
Я видел запросы к стороннему сервису, обёрнутые в два цикла, и всё это время фронт ожидает ответа. Если данных для обработки много, то нередко фронт отваливался с connection timeout. Написал это чувак, который в то время был сеньором, сейчас он тимлид. Пробежался по коду того бека, практически все его решения - в лоб. Но зато клепал таски со скоростью света. Поэтому, вероятно, он быстро поднялся по карьерной лестнице.
И подозреваю, что с точки бизнеса он был прав: возможно у бизнеса была задача "все для уменьшения TTM". Потому что бизнес по классификации Белоусова попадал в категорию "крысить" (с вебом AFAIK это бывает нередко), и там главное было сделать быстрее, пока другие в эту нишу не залезли и все ништяки не растащили.
На самом деле, в последней "задаче на оптимизацию", помимо всего прочего, линеалиризировал все скули (а они там нетривиальные - 5-7 таблиц, 2-3 подзапроса и т.п.). Т.е. выкинул оттуда все group by и order by. Результат читается блоками по 1000 записей и складывается в список. На этом этапе происходит вся нужная агрегация и сортировка (список - key-value, быстрый поиск по key, элементы сразу размещаются "по месту", сортировка "автоматом").
А потом уже быстрый проход по списку от first к next с конечной обработкой элементов.
Да, два цикла. Да, избыточный скуль. Но там получается намного проще план запроса и он кратно быстрее работает. В сумме получилось в четыре раза ускориться.
Но подобные вещи уже, естественно, в камментах к коду описываются - почему именно так.
ваш работодатель обеспечивает вам идеальные условия труда? у вас достаточно времени на анализ требований, дизайн архитектуры, верификацию и т.д.? Вы получаете идеальные бизнес требования и необходимое время на реализацию?
подозреваю, что ответ на большинство вопросов - нет. поэтому ваше предложение наказывать разработчика за неэффективное решение как минимум наивно.
ваш работодатель обеспечивает вам идеальные условия труда?
Не знаю что есть "идеальные". Комфортные - да. Обеспечивает.
у вас достаточно времени на анализ требований, дизайн архитектуры, верификацию и т.д.?
Да. Никто никогда не гонит по срокам. Бывает "нормативка" (когда дедлайн строго и жестко задан), но это достаточно редкий случай.
Вы получаете идеальные бизнес требования и необходимое время на реализацию?
С бизнес-требованиями (BRD) работают архитекторы (согласование архитектурного решения) и аналитики (написание по ним FSD). Я работаю с FSD уже. Оценку сроков на реализацию даю я сам (и всегда делаю это с запасом).
Если возникают какие-то вопросы по реализации - их всегда можно обсудить с аналитиком.
Для нас во главе угла всегда стоит надежность и эффективность. Эффективность и надежность. Такая специфика. Потому что цена ошибки (в том числе потенциальная потеря производительности при пиковой нагрузке) для нас неиллюзорна и очень высока.
Примеры я приводил уже. Был реальный случай когда нормально (казалось бы) работающий в обычных условиях модуль в условиях пиковой нагрузки начал дико тормозить что повлияло на смежные процессы. В результате у миллионов клиентов по всей стране в течении полутора-двух часов (пока сопровождение не организовало WA ситуации) были большие проблемы с оплатой картами банка в магазинах (оплата не проходила - "нет ответа от банка"). Ощущаете масштабы факапа? За такое можно от регулятора очень неслабые штрафы получить. Не говоря уже о репутационных издержках.
Или известный мне случай из той же серии - запись детей в школу через ГУ. 1-е февраля, полночь, родители массово ломятся на портал записать ребенка в ту школу, куда хочется. Пиковая нагрузка. Портал ложится. Запись не проходит. А потом выясняется что в той школе куда хотели, мест уже нет. Жалобы, скандалы... Лет 5-7 назад, по-моему, это было на протяжении 2-3 лет. Сейчас не в курсе что и как, вроде нормализовали как-то...
Одна из причин аварии на Чернобыльской АЭС знаете какая (на всякий случай - это моя институтская специальность - реакторы и учился как раз в те годы когда это случилось)? Дежурная смена просто не знала что прямо сейчас происходит в реакторе и что нужно делать. Там огромное количество датчиков, на основе показаний которых получают карту распределения плотности нейтронных потоков по АЗ, и по ней система выдает рекомендации по управлению реактором (там в определенных условиях нельзя просто взять и сбросить все стрежни - станет только хуже, положение каждого стержня рассчитывается индивидуально). В те времена просто не было таких вычислительных мощностей, которые могли бы обеспечить обработку такого объема информации в реальном времени. В штатном режиме все работало, но в аварийной ситуации мощности системы не хватило. Так что в общем случае - тоже проблема производительности.
Областей разработки, где нельзя (очень дорого) забивать на производительность в угоду ТТМ немало. Да, конкретно Вы можете с этим не столкнуться никогда, но это не значит что такого нет.
Но вот, какие знания для него точно избыточны и не нужны в работе — это, к примеру, та же гидродинамика. Ему попросту негде применить эти знания.
Интересно, а как тогда разводку проектировать? Как раз прикол в том, что есть конечно все по отдельности, но собрать это все в кучу тоже нужно много знаний :)
Однако, ряд вещей, которые просто обязаны хорошо знать «программисты‑технологи», для них избыточны. В первую очередь это пресловутые алгоритмы.
В прикладном решении есть те же алгоритмы, так как ... о чудо, это просто способ описать процессы/задачи/потоки/события реального мира. И они есть везде, даже иногда в очень простых input-формах
Мне кажется, вы, к сожалению, так и не поняли, что такое алгоритм :)
Вставлю свои пять копеек. Да, спортивное программирование — параллельный к промышленной разработке мир. Примерно как современный парусный спорт абсолютно параллелен современному водному транспорту. Да, если бы при приёме на работу во флот требовали проходить на время гоночные трассы на паруснике — это был бы полный бред, поэтому никто такого и не делает.
Вопрос в другом: можно вы (не лично автор, а промышленные программисты как коллективная сущность), пожалуйста, не будете возводить свои промышленные подходы в абсолют? Представьте себе, вы приходите в яхт-клуб и говорите: паруса не нужны, все 100 лет уже на дизеле ездят. Представляете, как на вас посмотрят?
Немного напрягает, что вот такие вот продуктовики меряют всё исключительно по себе.
Так поэтому я и пишу, что есть ниши — где это нужно и важно. Это ниши создания технологий / фреймворков / СУБД / высоконагруженных библиотек / языков программирования.
Я пишу о том, что зачастую эти "алгоритмические" требования предъявляют к ситуациям и контекстам, когда они вообще не важны.
По мне так умение выбрать и использовать наиболее подходящий именно здесь алгоритм важно везде. А для этого надо понимать как они работают, чем отличаются и какой где лучше.
В "нишах" - там отдельная песня. Там часто свои алгоритмы изорбретают.
Конкретно в Яндекс алгоритмы как раз критически важно. Часто высокие нагрузки, и код на общеупотребимых фреймворках там всяких не особо и нужен. Много всякого своего написано. Многое вообще моделируют на питоне и переписывают потом под прод на С. Так что собес очень зависит от позиции и задач. Круды писать так там не надо, вот и проверяют на алгоритмы. Несколько лет назад я был внутри и читал ручным тестировщикам(!) курсы как раз-таки по CS. Так что там это не хотелки а необходимость. Реально нужен этот скилл, чтобы не набокорезить.
Кто же на круды набирает, тот и замороченные олимпиадные задачки давать не будет. Ну максимум спросит быструю сортировку или хеш-таблицу. Ну так это на самом деле любой инженер софтверный просто обязан знать, час времени на одно и час на другое надо (на изучение я имею ввиду). Почему бы и не проверить, потрачены они были или нет.
Честно говоря, я вот сейчас затрудняюсь вспомнить разные алгоритмы сортировки. Но как-то за 20+ лет карьеры - ни разу не приходилось их писать. Знание куда-то улетучилось. На практике (немного смешной пример) оказалось гораздо важнее не писать свой алгортим сортировки, а знать, что у SELECT есть атрибут ORDER BY. В общем, все уже украдено для нас. И если мне пригодится это знание раз в 20 лет - ничего страшного, если придется потратить час-два на то, чтобы прочитать снова и освежить.
Понял, что я использовал хештейблы и списки (1-2 связные) тогда, когда программировал на С. А в более высоких языках это знание уже не требуется.
Нужно ли про это знать? Наверное да, но как у Пелевина: "на уровне коллективного бессознательного". На практике, чтоб такие темы от зубов отскакивали - не слишком важно.
Раньше я слышал, что в Древнем Китае когда набирали чиновников - оценивали их умения в стихосложении и прочей бесполезной гуманитарщине. Мне это показалось смешным и абсурдным фактом. А сейчас я понимаю, что да, так и надо. Конкретное техническое знание - либо недорого стоит и оно есть, либо его можно легко получить. Гораздо важнее понять, как человек мыслит, насколько широк кругозор, насколько он уязвим к когнитивным искажениям, насколько развито критическое мышление. Если по этим показателям все ОК (и чел из IT) - скорее всего и в IT он достаточно знает, и если даже где-то есть пробел - то этот пробел компенсируется знаниями в другой теме, которые тоже могут быть полезны.
Вообще, у меня есть сомнения, что Джобс или Гейтс прошли бы собеседования так же блестяще, как их деловые успехи. Да и Торвальдс - хоть и неплохой программист, но любим мы его не за это. Все кто "выше чем программисты" (то есть, гораздо более ценные кадры) - скорее всего или не очень хорошие программисты, или вообще не очень важно, хорошие ли они программисты или нет.
Цитата чуть-чуть подредактирована без искажения смысла.
Понял, что я использовал хештейблы тогда, когда программировал на С. А в более высоких языках это знание уже не требуется.
Серьезно? Все пишущие код используют мапы примерно ежедневно. Это и есть тот самый хештейбл. Как можно писать нормальный код не зная наизусть его свойства и не понимая что ты используешь?
Смотрите как:
mydict["key"] = value
Это несложно. Даже человек, который не слышал про хэштейбл легко справится! Это как включать лампочку дома, которая запитана через сеть трансформаторов от АЭС. Не нужно знать ни про постоянный ток, ни про переменный, ни про трансформаторы, ни про сопротивления и тем более не обязательно знать про структуру атома. Просто щелкаешь выключателем и свет загорается.
Я представляю, как работает хештейбл там внутри. Но еще я представляю, как работает 4-тактный ДВС. Оба глубоких знания мне примерно одинаково важны. Лучше знать, чем не знать, конечно. Но я б не сказал, что мне это знание сильно помогает.
Это несложно. Даже человек, который не слышал про хэштейбл легко справится!
Но есть нюанс. Человек, использующий хэш-таблицу, должен знать ее побоччные эффекты: большие избыточные требования к памяти (из-за необходимости избежания большого числа коллизий - когда несколько ключей ведут в одну ячейку таблицы, что ведет к деградации скорости поиска), и сложность определения необходимого размера памяти для постоянно растущего набора данных (хэш-таблицу меньшего размера нельзя просто взять и скопировать в большую: адреса ячеек для имеющихся элементов поменяются, и их надо переразместить, жтио называется рехэштрование). Эта информация мне кажется необходимой в достаточно большом числе практических применений, чтобы ее можно было проигнорировать.
А вот какие есть и как работают методы избежания коллизий или алгоритм рехэширования или определения порога для него знать в первом приближении не обязательно.
И я, кстати, сейчас пытаюсь выяснить для себя вопрос - может ли техник-программист, - алгоритмам специалльно не обученны, но имеющий под руками хороший, годный каталог алгоритмов (со всеми их свойствами) и их библиотечных реализаций - заменить инженера-разработчика, который алгоритмы должен знать. Подобно тому, как сейчас обычный человек с Гуглом вполне может заменить на прктике известного эрудита Онотоле.
Сразу скажу, что это не лично, и не ответ на коммент, а просто мысли вслух.
Потеря время на доказательство бесполезности CS (я не про CS:GO а про Computer Science, хотя и первое не лишнее ))) обычно сильно больше собственно времени на изучение CS. Это феноменально простая инфа. База. Это вовсе не умение "нести яйца", а основа всех последующих абстракций. Пролистали Грокаем алгоритмы или посмотрели курс Кулешова на степике по алгоритмам. Для человека в теме это максимум два вечера и вот дискуссии по сабжу уже не так и нужны.
А так аргументы "не хочу, не надо, не буду, все есть в wiki" чем-то неуловимо напоминают "а зачем мне while... когда на все всегда хватает for...".
Я очень много лет изучал всякое разное, от железа, машинного кода и ассемблера, и заканчивая монструозными жабопитонными технологиями типа jee, или спрингами да джангами. Не использую 99% того, что изучал когда-то. Но сказать, что все это мне это не нужно у меня язык никогда не повернется.
Шеф-повар от кухарки все же должен чем-то отличаться, и там и там пироги, но разница обычно очевидна. Шеф-повар не будет тратить время на википедию по пустякам.
Да, конечно. В совке были пту техникум вышка и наука - сейчас не о качестве, а о градациях. Это важная идея. Но ведь сейчас действительно смешались в кучу люди-кони, градаций нет, есть стаж. Были бы - не возникало бы это проблемы. Вот и нужны везде шефы, а на проектах задачи кухарки. Се ля ви.
Но ведь если позиция называется software engineer, то как-то надо проверять подготовку (в смысле готовился или не готовился)? Кроме сферических коней (алгосов) и последующих бесед про реальный опыт (технологии) вряд ли кто-то что-то придумает. Ну а раз назвался engineer, то и спрос соответвующий. Это же не местный перекос. Это мировая практика. Все HR одновременно ошибаться не могут.
Наличие релевантного автоматического сортировщика по скилам с признаваемым в индустрии сертификатом - это был бы супербизнес, все мечтают его построить или заполучить. Но по сути это как диплом ВУЗа (не наших увы погибших, а к примеру MIT, или какого-то американского колледжа среднего уровня). А и там и там как раз оно. CS. В любом адекватном вузе планеты.
Есть ли смысл спрашивать ракетные технологии, если человек вышку первого курса не знает и не видел даже? От простого к сложному, от планера к самолету. И так везде. Почему же в IT надо сразу самолет спрашивать? Может же просто нет смысла продолжать разговор.
ЗЫ. Ну и про найм. Топ-поваров, которые придумывают новые блюда молекулярной кухни никто не ищет. Они сами владеют или управляют рестораном.
ЗЫ2. Причем тут синдром Даннинга-Крюгера вообще не понял. Мы же ведь не о джунах сейчас беседуем? Или "ничего личного" - это ложь :D ?
Наличие релевантного автоматического сортировщика по скилам с признаваемым в индустрии сертификатом - это был бы супербизнес, все мечтают его построить или заполучить
Сфера слишком быстро растет. Пока качественно вылижешь классификацию и сертификацих всех Fortran, Cobol и Perl программистов по их знаниям IBM System/360, уже какой-то интернет вылезет, какой-то HTTP, какие-то CORS и какие-то блокчейны (хакеры, куки, кряки).
Да и работодателю это не слишком нужно, потому что программист, нанятый сегодня для VR проекта, через три года будет работать над криптовалютным, а еще через три года - все буду только LLM заниматься.
Я очень много лет изучал всякое разное ... Не использую 99% того, что изучал когда-то.
С утверждением, что "лучше знать, чем не знать" - сложно спорить. Конечно, лучше знать. Но правильный вопрос, "Что мне лучше пройти сегодня, разобраться, как работают хештейблы или какую-то другую технологию?" (А может вообще не IT, а расширить кругозор, например, послушать лекцию по микроэкономике - это тоже важно)
Как же выбрать? И тут для меня напрашивается идея из области кеширования. Не обязательно "прогревать кеш" (наш мозг) какими-то данными, которые теоретически в нем могут быть полезными (а могут и не очень). А так же как и с кешем - вот как появится первый запрос, с решением которого мы не можем достаточно хорошо справиться - так, значит, нам и придется эту тему разбирать, в которой у нас есть потребность и нехватка знаний. Учиться программисту нужно постоянно, тут, мне кажется, разногласий нет. Как бы "выбор тем по промаху кеша" часто (не всегда, но часто) выручает.
Ну и мы же говорим на самом деле не про хеш-таблицы (этот пример, за который мы уцепились), а за всю необъятную тему IT и смежных областей (в наше время, хороший IT специалист в России должен даже и политологию немного знать и экономику и даже военное дело, чтобы понимать, когда принять важное IT решение ехать на Верхний Ларс :-) )
Ну конечно сидеть и все подряд учить это странно.
Но вот к примеру: вот я такой весь из себя айтишник подписался в телеге на вакансии и че-то мне подошло, и вот я уже иду на собес в Яндекс. Черным по-белому написано, "мы начинаем с алгосов". Зачем же мне экономика и военное дело?
У меня варианты другие: а) мне надо пойти на собес и поразить всех опытом да крутотой или б) все же стоит почитать чего от меня хотят и повторить/изучить это?
По многим комментариям/статьям/дискуссиям заметно, что нередко люди после нескольких лет работы "ловят звезду" и идут а) поражать воображение. А когда их б) "сливают" на простейших задачках становится обидно и мы видим море статей на тему "алгосы не нужны".
Мой поинт в том, что алгосы (без вышки и доказательств, а чисто практически) - это настолько примитившейшая первокурсная легкотня, что такое не знать - это просто "позор какой-то (с)".
Конкретно для в Java алгосы - это Java Core - самая базовая база. Базовее некуда. Коллекции, деревья, хеши и вот это вот все. Как это можно вообще не знать? Правильно. Никак. Незнание таких примитивных вещей - гарантия некомпетентности. Ибо они примитивные.
б) "сливают" на простейших задачках становится обидно и мы видим море статей на тему "алгосы не нужны".
Обидно, когда сливают. Но ведь в самом деле - не так уж и нужны. Вот мы (аналогия) ищем шеф-повара в ресторан, и что нам от него нужно? Нужна фантазия и утонченный вкус, чтобы он смешал селедку и малиновое варенье и весь город стоял бы к нам в очередь, чтобы попробовать этот невероятный вкус!
Но разве мы можем проверить фантазию на собеседовании? Это сложно. Можем ли проверить вкус? Это еще сложнее. Зато му можем проверить за сколько времени он может нашинковать лук и как быстро бегает со сковородкой в руке. Работодателю реально важна магия, которую сложно даже сформулировать и невозможно измерить, а на собеседовании у него есть весы и рулетка.
Это проверяется не потому, что это решающий фактор, а потому что это как-то можно проверить, а другое, реально важное - линейкой не замерить.
Это проверяется не потому, что это решающий фактор, а потому что это как-то можно проверить, а другое, реально важное - линейкой не замерить.
И тем не менее это, хоть и не решаюший фактор, вполне релвантно. Повар показывает, что он на кухне вообще может сковородку от кастрюли отличить и занает, где у них ручки. И иногда ему, таки, придется именно быстро нашинковать лук. Хоть большую часть времени он будет, скажем, неспешно нарезать капусту.
курс Кулешова на степике по алгоритмам
Можно ссылочку? А то что-то не ищется...
Я тут предложил делать каталоги алгоритмов и их реализаций, в рамках бизнеса сторонних сервисных фирм. Но сам я за это не возьмусь - в бизнес не умею.
Все пишущие код используют мапы примерно ежедневно. Это и есть тот самый хештейбл.
"Здесь всё не так однозначно"(с): мне вон @SpiderEkb в одном из комментариев написал, что мап может быть понят по-другому:
В данном случае мап - любой список пар ключ-значение с быстрым поиском по ключу.
Но вообще надо смотреть конкретно контекст: что за средство разработки используется. Возможны в данном контексте вы правы (не уточнял).
оказалось гораздо важнее не писать свой алгортим сортировки, а знать, что у SELECT есть атрибут ORDER BY
Угу-угу. Был случай. Отчет. Там для построения нужен был order by по 5-ти полям из разных таблиц. Работало минуты полторы даже на тестах (на проме кратно больше).
Выкинул order by из запроса, сначала засунул результат выборки в сортирований по ключу список (ключ - суперпозиция тех самых полей), потом его обработал (просто проходом по списку от головы к хвосту). Ускорился в 5-6 раз.
"Болевая реакция". очень хороший принцип. Если от неэффективного решения кому-то больно - оно будет оптимизироваться. Если же никому не больно, или болевой сигнал не проходит (клиенты страдают, но руководство не в курсе) - то не будет.
Все "умные" методы, которые призваны улучшить качество кода - все фейлятся так или иначе, а вот болевая реакция - гораздо надежнее.
Она только в защите информации плохо работает. Если в вашей системе есть уязвимость - вас не замучают шквалом звонков, она не будет болеть. Программисты (даже подозревающие, что там может быть проблема) - будут решать другие мелкие маловажные задачи, потому что те задачи болят, а эта нет.
Однако, примерно 98% программистов — не создают технологии или движки. О
Ну давайте уж будем честными - такая разница конечно есть, тут вы правы. Но про 98% это вы же с потока взяли, правда?
Потому что на практике вот это неумение изобретать алгоритмы сводится например к тому, что "инженер" в цикле на 1000 повторений столько же раз ищет элемент в массиве перебором, вместо того, чтобы один раз построить вместо массива хеш мап, и искать в нем за O(1). Ну т.е. к нему такие требования не предъявили - и он применяет единственный алгоритм, который знает. Не важно, плох он или хорош. Если хорош - повезло. Ну разве это дело?
А если у вас уже массив из 1000 элементов и надо пройтись пару раз... И вдруг решили все переложить в мапу... Оптимизировать On на O1...
Если человек не видет элементарного это одно, а когда он не может решить 2 задачи с литкода за час уровня медиум...
То хз кто чудила... Может собеседующий?
Если человек может решшить 2 задачи с литкода за час уровня медиум, то он точно понимает, в каком случае имеет смысл перекладывать массив в мапу, а в каком случае - нет.
А если у вас уже массив из 1000 элементов и надо пройтись пару раз
По суть это часть вопроса: понимать применимость того или иного инструмента на практике, исходя из обстоятельств. Для этого требуется примерное понимание того, как оно работает.
Да.
Достаточно понимания как работает.
А не шпреханье алгоритмов по ночам.
А не шпреханье алгоритмов по ночам.
Дык, контор, которые требуют хитрых алгоритмов, раз два и обчёлся. Большинству нужен какой-нибудь примитив, уровня объединения двух коллекций с группировкой. Или пробежаться по дереву в глубину и что-то найти. Ну и т.д.. Распарсить какую-нибудь строку по заданному формату. Какой-нибудь детский сад. Никто (ну почти) ведь не требует от вас эхо-корасиков.
Это ниши создания технологий / фреймворков / СУБД / высоконагруженных библиотек / языков программирования.
А так же фаанги, где далеко не только формочки шлепают. Там тупо много данных, которые надо быстро обрабатывать. А разработчкики подвижны, поэтому нельзя нанимать отдельно алгоритмистов и кодеров. Плюс в том же яндексе и технологии с фреймворками создают, и высоконагруженныее библиотеки, и даже языки программирования.
Кстати, поэтому в Фаангах еще и не спрашивают никакие популярные фреймворки - это бесполезно, потому что там везде свои самописные фреймворки, часто появившиеся на годы раньше публичных аналогов.
Было дело, видел и такое. Продает сосед яхту, приходит покупатель, осматривает первым делом каюту, нравится, осматривается яхту внимательнее и произносит:
-" А вот это что за палка торчит?" - "м.м.м Мачта" - "Её спилить можно?" -"м.м.м ну да"
-"А вот это что внизу?" -"Киль, хороший - акулий плавник 600кг" -"а его убрать можно?" -"Ну .. если мачту спиливать, то да"
-"А где тут мотор?"
-"Слышь, мужик: топай отсюдова. Яхта не продается."
:)
Представьте себе, вы приходите в яхт-клуб и говорите: паруса не нужны, все 100 лет уже на дизеле ездят. Представляете, как на вас посмотрят?
Глобально, если человек в конкретном месте будет прав, то должно быть пофиг как на него посмотрят. Представьте, что у нас не яхт-клуб, а конюшня 100 лет назад, и туда заходит Генри Форд. Говорит - лошади не нужны, все будут ездить на ДВС. Представьте, как на него посмотрели?)
"Правда" она такая... Не постоянная. Вчера было нормой - сегодня может быть не актуальной. Раньше для того, чтобы писать код ты должен был быть хорош в математику, и считать каждый бит, выдумывать хаки процессора итд. А сейчас чтобы принести пользу, у тебя репозиторий npm в несколько гигабайт, и ты даже не знаешь что там. Если бы такое сказать нашим дедам - как бы они на нас посмотрели? А сейчас? Its fine!
Очень спорно. Приведу пример из практики.
Я занимаюсь расчетами на прочность, в том числе сосудов высокого давления. Рассчитал, все нормально. В числе прочего, указал достаточный класс крепежа. И вот у клиента вылезает проблема - крепеж (они его делают сами) лопается. Испытывают на разрывной машине - характеристики выше расчетных. Сильно выше.
Оказалось, что они при изготовлении перекалили шпильки, которыми крышка притянута к корпусу. А крышка под давлением немного выгибается - в пределах упругой деформации, но выгибается. А перекаленные шпильки прочнее, но хрупче, и даже небольшой изгиб приводит к разрушению.
Они сделали новые шпильки, закалили их слабее, и проблема решилась. Хотя прочность (измеренная при строго осевом растяжении) снизилась.
То есть, даже если ты делаешь из стандартных вроде бы компонентов (или делаешь их сам) - без глубокого понимания механики различных процессов при попытке сделать лучше можно влететь.
Да. Инженер — это же творческая профессия, не конвейер. Наивно рассчитывать, что все задачи, которые ему поставят, будут укладываться в узкий коридор. Наверняка появится какая-то повышенной сложности, чуть выходящая за рамки обычных обязанностей.
Кстати, обычно такие задачи решают, пользуясь запасом знаний, а потом долго вспоминают о них с любовью.
И вот у клиента вылезает проблема - крепеж (они его делают сами) лопается.
И как это относится к ВАШЕЙ задаче? Это их задача. И, как я понял, они же и нашли проблему, и решили.
стандартных вроде бы
Раз менялся техпроцесс, значит уже нестандарные.
Я совсем не прочнист, но слово "достаточный" меня заинтриговало. Достаточный или требуемый класс крепежа?
В подавляющем большинстве случаев - достаточный. То есть замена крепежа низкого класса на высокий не создаёт никаких проблем, кроме роста цены.
Оно и в данном случае проблем бы не вызвало, если бы крепеж был не самодельный, а покупной. Но производство не учло, что высокая твердость (твердость и прочность - разные вещи, хотя и коррелируют) в данном случае - плохо, и задрало её так высоко, насколько смогло. В результате прочность получилась выше чем нужно для данного класса - процентов на 15, но шпилька стала хрупкой (обратная сторона твердости) и при небольшом изгибе лопнула. А без изгиба у них этот крепеж прошел. А когда снизили твердость - лопаться перестало, хотя прочность упала на те самые 15%, вернувшись к нормативной.
Да про хрупкость пластилина я понимаю, мне хочется понять, кто именно виноват в производственной заминке. Вот вы сказали, что нужно взять крепёж как минимум 8.8 (или какие параметры задаются?), а я взял 12.9 и у меня сломалась коробочка. И тут я начинаю чесать голову и терять деньги на простое.
В итоге: виноват ли прочнист, неточно (неполно) задавший параметры крепежа, или сборщик, неверно истолковавший указания?
В данном случае ребята не взяли готовый, а сами изготовили крепеж. И изготовили его максимально прочным - так, что он по твердости вылез за допускаемые для этого крепежа. То есть ошибка на стороне производства.
Проблема именно в том, что они хотели как лучше, посчитав, что прочность ценой твердости - это хорошо. А оказалось в данном случае плохо.
Я, возможно, плохо читаю ветку, но так и не понял, было ли им (производству) где-то написано, что 'допускаемые' в данном случае - еще и сверху ограничивается, т.е. что прочнее делать нельзя?
Или было ли написано, что 'хрупкость крепежа не должна превышать <в чем там оно меряется>'
Или считается, что они сами должны были догадаться, что поднять прочность и увеличить хрупкость на 2% - это еще можно, а на 15% - это уже вылезаем за пределы допустимого по хрупкости?
Как высшее образование учит вас работать с информацией, так алгоритмические задачи учат вас работать с задачами. Не даром на собеседованиях так много уделяют внимания тому, как вы работаете с условиями задачи и как прокладываете путь решения.
К тому же, то, что вы все же смогли подготовиться к подобному собеседованию с помощью решения подобных задач уже неплохо говорит о том, что вы обучаемы и что вы заинтересованы в этой работе.
Имхо, знание алгоритмов как таковых важно в этих собеседованиях по остаточному принципу. Тем более, ну нет там каких-то алгоритмов требующих серьезных научных изысканий, большинство задач на весьма базовые знания, а вот важно уметь применять эти знания в решении данной вам задачи (ровно как вы будете применять какие-то другие свои знания в решении продуктовых задач потом).
Кмк, тут просто популярное заблуждение насчёт знаний, умений и работы. Из обще-оптимизационных соображений многим кажется, что знать и уметь нужно только то, что требуется для выполнения непосредственных обязанностей. Но нет, инженер — это не робот, периодически ему приходится решать задачи «повышенной сложности», которые выходят за пределы рутины.
Вторая проблема — «мы не заем, что же именно мы не знаем». То есть, если человек не знаком с алгоритмами, то рано или поздно у него появится необычно сложная задача, и он вставит что-то сильно неподходящее, причём даже не будет догадываться о том, что накосячил.
Поэтому, увы, знания и умения должны покрывать больше, чем требуется для непосредственной работы. Как, знаете, доклад готовите — всегда должна быть область вокруг, в которой вы компетентны, но которую даже не планируете рассказывать. Для вопросов — чтобы не сесть в лужу на первом же, отходящем чуть в сторону.
Почему надо быть знакомым именно с алгоритмами, а не, допустим, с законодательством? Или с основами пользовательского интерфейса? Или с серьезной математикой за пределами информатики? Повышенная сложность может оказаться где угодно.
Всё надо, вы правы. Нужно, чтобы вокруг задач, которые вы решаете, была область, в которой вы что-то понимаете.
Почему надо быть знакомым именно с алгоритмами
Потому что алгоритм - это "набор инструкций, описывающих порядок действий исполнителя для решения определённой задачи". Программист в своей работе составляет именно этот набор инструкций на своем языке программирования, чтобы компьютер решал определенную задачу.
Программирование по сути - написание алгоритмов абсолютно все время. Да, часто это совсем тривиальные алгоритмы. Но все программисты сталкиваются с алгоритмами. Не все сталкиваются с законодательством или дизайном интерфейса. На связанные с этим позиции в тех же фаангах проводят дополнительные интервью.
Смотря какие алгоритмы. Знание какого-нибудь Ахо-Корасика - действительно не важно. Это редкая и нишевая вещь. Если знать, что вообще алгоритмы бывают, его можно и нагуглить, если он понадобится. Их на интервью и не спрашивают. По крайней мере в гуглах и прочих фаангах. Каким карго-культом страдают условные рога и копыта - я не в курсе.
А вот какие-нибудь задачки уровня easy-medium с литкода - важны. Если программист не может за пол часа да с подсказками выдавить из себя 10-15 строк кода, чтобы, например, развернуть число, то он не сможет развернуть массив, когда ему понадобится хоть что-то делать с данными.
Формочки клепать он, возможно, еще и сможет, но в том же гугле регулярно попадаются, таки, данные, с которыми что-то делать да и надо. Даже во фронтенде.
Потом, задачи на интервью прежде всего адаптированны под интервью. Реальные задачи со всем контекстом пол часа непосвещенному кандидату только объяснять будешь. Поэтому даже если прямого аналога этой задачи никогда не встретится, можно ее допустить, чтобы проверить как кандидат пишет не broilerplate код.
Как при проверке водопроводчика вы можете попросить его собрать трубы, не подключенные ни к чему, просто на полу в большой просторной, хорошо освещенной комнате, что никогда в его практике скорее всего не встретится.
Я считаю, что нужно хотя бы понаслышке знать основные классические алгоритмы и структуры данных. Понаслышке это значит: что такой алгоритм вообще есть, для каких задач он применяется, в чем его основная идея и принцип работы, какие есть ограничения. Мелкие детали реализации и код наизусть знать не надо, для этого есть справочники.
Но и вот в это — "вот когда понадобится, тогда и нагуглю, а до того оно мне не нужно" — я тоже не верю. Трудно нагуглить что-то осмысленное, когда даже приблизительно не знаешь куда копать. А если даже повезло и нагуглил, то как понять, что это то самое, что мне подойдёт лучше всего?
Я не так давно копал новую для себя область. Ну думаю, на Ютубе туториалов много — разберусь. Смотрю один, второй, третий... В целом всё как будто понятно, но когда пытаешься погрузиться в нюансы и уйти в сторону от учебника, то вопросов всплывает очень много. Начинаешь искать ответы — поиск выдает какую-то фигню. Помыкавшись, я задал вопросы знающему человеку с академическим образованием в нужной области. Так мне за несколько минут разложили на пальцах всё то, что я не мог собрать в кучу несколько дней. Во-первых, я понял принцип, а во-вторых, я узнал несколько недостающих терминов — и о чудо, поиск по ним стал выдавать осмысленные результаты.
Знание алгоритмов которые вы перечислили - важны.
Но умение имплементировать его в режиме лайв-кодинга ничего не говорит о специалисте.
Я например так не умею и лайвкодинг всегда избегаю, так как рассматриваю это скорее как невежество. Литкод/хакерранк - красные флаги. Это значит, что компания скорее всего забила на процесс подбора кандидатов и решила выстроить no-brain фильтр.
Все люди мыслят и думают по разному. Я не всегда могу за один присест решить какую-либо задачу, обычно они решаются в бэкграунде при отвлечении на кофе или типа того. В режиме лайв-кодинга просто невозможно это сделать.
Знание алгоритмов которые вы перечислили - важны.
Но умение имплементировать его в режиме лайв-кодинга ничего не говорит о специалисте.
Я например так не умею и лайвкодинг всегда избегаю, литкод/хакерранк - красные флаги. Для меня это значит, что компания скорее всего забила на процесс подбора кандидатов и решила выстроить no-brain фильтр.
Все люди мыслят и думают по разному. Я не всегда могу за один присест решить какую-либо задачу, обычно они решаются в бэкграунде при отвлечении на кофе или типа того. В режиме лайв-кодинга просто невозможно это сделать.
Когда я нанимаю людей мне в первую очередь важно знать какой опыт у человека, какие системы он проектировал, как выбирал технологии и почему. Мне абсолютно не интересно как он будет вращать бинарное дерево.
А разве "развернуть число" и "развернуть массив в памяти" это не совсем разные задачи?
А вот какие-нибудь задачки уровня easy-medium с литкода - важны. Если
программист не может за пол часа да с подсказками выдавить из себя 10-15
строк кода, чтобы, например, развернуть число, то он не сможет развернуть массив, когда ему понадобится хоть что-то делать с данными.
Ну положим (и сталкивался много где) задача на литкоде описана не совсем корректно. Это не "развернуть число", а развенуть десятичное представление целого числа.
В общем виде (по любому основанию) задача сводится к выделению младшей цифры в исходном числе остатком от деления на основание с умножением результата на основание и суммированием с младшей цифрой.
Так для "бинарного" представления можно обойтись банальными сдвигами, для шестнадцатиричного - сдвигать надо уже по 4 бита.
Как видим, задача как в постановке имеет несколько разных решений.. какое верное? ;)
И обратите внимание, что приведенные примеры не охватывают всё ТЗ..
Когда вы берёте готовое решение, то неплохо бы понимать, во-первых, исходя из каких допущений оно работает, а во-вторых, насколько его при необходимости можно улучшить руками. Это предполагает определённую глубину познаний.
Хотя вам, скорее всего, и не придётся писать быструю сортировку руками, но полезно представлять, насколько она теоретически отличается по быстродействию от пузырьковой и в какие практические цифры это выливается на каждом конкретном этапе развития техники, чтобы иметь возможность поправить криворуко сделанную систему.
А что касается спортивного программирования, то согласен, что этот навык не имеет особого отношения к реальной работе.
Но однако же надо согласиться, что не любая программистская позиция требует инженерного образования.
Если какой‑нибудь условный интернет‑магазин, написанный под конкретного заказчика, будет в полтора раза медленнее (или потреблять в полтора раза больше памяти) от теоретически/технологически‑достижимого предела — этого никто не заметит.
Обычно в современной практике программирования разница с достижимым при разумных усилиях пределом составляет сотни тысяч раз. Весь херак-херак-и-в-продакшен код очень неэффективен. Нужно ли ускорять интернет-магазин в сто тысяч раз – другой вопрос.
Когда вы берёте готовое решение, то неплохо бы понимать, во-первых, исходя из каких допущений оно работает, а во-вторых, насколько его при необходимости можно улучшить руками. Это предполагает определённую глубину познаний.
И насколько данное решение будет эффективным в вашем конкретном случае.
Тех же сортировок много разных. И каждая в одном случае будет лучше других, а другом хуже. Ваш случай какой?
Тех же контейнеров тоже много. И все разные. Какой для вас именно тут наиболее эффективен?
Как пример - кеширование чего-то в памяти. Одно дело справочник - один раз прочитал, потом 100500 раз пользуешься без изменений. Тут обычный сортированный массив сгодится - на старте заполнил, отсортировал, а потом быстрый двоичный поиск по нему.
Другое дело, когда что-то агрегируешь - надо по ключу искать что-то, если нашел - что-то делаем с данными, не нашел - добавляем. Тут уже массив не пройдет - много времени на сортировке после каждого добавления потеряешь. Тут лучше какой-нибудь список сортированный взять - там поиск медленней чем двоичный по сортированному массиву, но зато нет отдельной сортировки - новый элемент сразу "по месту" вставляется. В сумме будет быстрее.
Но для этого надо знать и понимать какой контейнер как работает. И в каких условиях что лучше будет. А не просто схватить первое что под руку попало.
Когда ты не владеешь инструментом и не знаешь, что он может дать и вообще никогда в жизни не видел, ты даже не можешь осмыслить, как он полезен и удобен, ведь никогда не пробовал и не сравнивал.
Точно так же с навыком думать. Если ты не умеешь думать, ты не можешь даже предположить, что этот навык тебе нужен, ведь никогда не применял. Но получив навык однажды, ты начинаешь видеть его приложение повсюду.
С моей точки зрения бОльшей глупостью является как раз-таки расспросы о фреймворках. Словарные знания, которые легко гуглятся и гуглят в "реальной жизни". Словарное знание можно нагуглить,а способность строить логические конструкции - это навык, а не словарное знание, и не нагуглишь.
Тот факт, что кандидату легче прочитать десятки книг по различным фреймворкам и языкам , чем понять всего лишь пару глав из кормена, прямо говорит о его умственных способностях, что является серьезным триггером для работодателя. Ведь это небольшой объем, просто думать надо, а не зубрить.
ЗЫ ненависть к олимпиадникам так сильно растёт, что уже много лет не упоминаю об этом в резюме и где бы то ни было. Уж поверьте никто не хочет видеть олимпиадников, даже интервьюеры. Они задают примитивные вопросы по алгоритмам для формальности. Но и это является непростительно высоким порогом для подавляющего большинства джунов.
Минусуйте🤣
Инженер достал из стола свою таблицу объёмов красных резиновых мячей...
Физику, математику и инженеру дали задание — найти объём красного резинового мячика. Физик погрузил мяч в стакан с водой и измерил объём вытесненной жидкости. Математик измерил диаметр мяча и рассчитал тройной интеграл. Инженер достал из стола свою «Таблицу объёмов красных резиновых мячей» и нашёл нужное значение.
Я думаю нелюбовь к алгоритмам как раз проистекает из необходимости их выучивать, а не из интереса. Когда интересно работать и появляются задачи, где приходится оптимизировать - изучаешь эти алгоритмы с удовольствием и с другими также обсуждаешь. Но когда в реальности еще не известно, встретишься ли, а требуют знать - бесит и вызывает много сопротивления.
Если не иметь какую-то минимальную базу, достаточную, чтобы решать вот такие задачи, то у кодера даже мысли не возникает, что где-то проходится оптимизировать и надо какие-то алгоритмы изучать. Вы, когда два числа складываете, просто пишете a+b и даже не задумываетесь над тем, а надо ли тут что-то соптимизировать. Так и "инженеры, создающие решения" - впендюрят n-квадрат на ровном месте и все.
Если кого-то не устраивает производительность (пользователей, продуктоунера, себя, и т.д.) то рано или поздно придется сесть разбираться, а почему это медленно работает и как сделать быстрее. И так или иначе к алгоритмам придешь. Или даже тот же тимлид или коллега в код ревью подскажет, что тут может быть не очень. Может и не случиться конечно, но по мне вероятность сильно меньше, чем то, что столкнешься.
Ну вот пришли: Счет на сервера почти превышает доход. Или пользователи пишут гневные отзывы и уходят к конкурентам. Отпрофилировали - два бутылочных горлышка нашли, но все-еще торомзит примерно все - 100500 разных функций, все вроде нужные. Какой алгоритм вам нужен?
Или даже тот же тимлид или коллега в код ревью подскажет, что тут может быть не очень
Т.е. алгоритмическими интервью, по-вашему, надо гонять, но только некоторых разработчиков и тимлида? Которые будут ревьювить вообще весь код?
Я ни слова не сказал, надо или не надо гонять алгоритмическими интервью. Я сказал, откуда нелюбовь к ним, по моему мнению.
Нет, вы сказали "Но когда в реальности еще не известно, встретишься ли, а требуют знать - бесит и вызывает много сопротивления." Это значит, что вы утверждаете, что спрашивают то, что может и не понадобится. И раз это бесит, то наверно вероятность этого "не понадобится" - значительная. А это можно интерпретировать так, что вы против таких интервью. Ну мало кто считает, что спрашивать что-то редко нужное - это хорошо.
Это ваши фантазии, что я так считаю. Вот вам пример: когда приходится заучивать таблицу умножения - тоже злит, ведь хочется играть пойти.
Не все, что бесит, значит против. И опять же приводил пример, когда это не бесит. Просто считаю, некоторые компании порой неадекватно упираются в алгоритмы. Но как и умножение, они нужны и процесс изучения может быть интересным.
Тут проблема в том, что многие люди почему-то воспринимают оптимизацию как бинарный рубильник - она либо есть, либо нет. Либо простое прямолинейное решение, либо какая-то олимпиадно-яйцеголовая заумь. Но на самом деле там большой спектр полутонов.
И зачастую базовый алгоритмический кругозор позволяет просто не делать заведомо тупых и тормозных решений. Не лезем ни в какие сложные дебри, просто делаем нормально. В многих случаях этого правда достаточно.
Другой популярный миф в головах — если мы столкнемся с тормозами, мы посмотрим профайлер, быстренько найдем бутылочное горлышко и пофиксим его. Так тоже бывает, конечно. Но чаще в реальности, если упомянутого выше кругозора нет, со временем тормозить начинает примерно всё. Нет одного главного бутылочного горлышка — есть много мелких.
Профайлер переоценен на самом деле. Он поможет выжать производительность когда у вас уже оптимальные алгоритмы. Но если алгоритмы странные, то вы будете выжимать еще 10% из квадрата. И толку?
Если надо выжать еще больше, то профайлер снова бесполезен. Надо понимать как работает железо. Все эти предсказатели, кеш линии и все такое.
И в итоге профайлер нужен где-то после оптимизации алгоритмов и до оптимизации под железо. Применение у профайлера есть, но мало кто его применяет верно.
Ну, я употребляю слово профайлер в широком смысле, не обязательно который под железо.
Flamegraph в браузере — это ведь тоже профайлер. Идея в том, что мы посмотрим на эти графики, увидим функцию с самым длинным прямоугольником и дальше уже будем с ней разбираться, то ли там O(n^3), то ли другие причины.
Под профайлером можно понимать некий инструмент исследования производительности. У нас есть PEX - Performance EXplorer. Который покажет по стеку что где сколько выполняется, тратит ресурсов, покажет времена подготовки и выполнения встроенных SQL запросов, интенсивность обращения к БД, лишние переоткрытия файлов и еще много чего. Там сразу все "бутылочные горлышки" как на ладони.
Даже в описанном вами случае пропускается главная причина, от которой вы даже с десятью профайлерами будете заниматься микрооптимизацией - плохая архитектура. На которую ни алгоритмы, не железо не уложить.
Для себя подобрал пример: однопоточное против многопоточного алгоритма/приложения. Если понаписать однопоточку, потом без поломки работы алгоритма может не получиться его распараллелить, нежели не разрабатывать сразу с прицелом на многопоточность.
чтобы решать вот такие задачи
Ее на доске за полчаса решит дай бог один из 50 кандидатов с хорошим резюме на мидла-сеньора-архитектора-лида. Она на самом деле не так чтобы совсем простая. Хотя формулировка проще некуда.
Во-первых, на доске уже давно не спрашивают, а дают ноутбуки, или вообще, с пандемией уже 2 года все удаленно проходит.
Во-вторых для этого серъезно надо обязательно быть сеньером-лидом? Чтобы получить циферки делением на 10, потом перемножить в обратном порядке? Тут есть только один крайний случай - 0. И надо чуть-чуть подумать, как проверять на переполнение без 64-битных чисел:
Код
int reverse(int x) {
if (x == 0) return 0;
vector<int> digits;
while (x != 0) {
digits.push_back(x % 10);
x /= 10;
}
int ans = 0;
for (int i = 0; i < digits.size(); ++i) {
if (digits[i] >= 0 && ans > (numeric_limits<int>::max() - digits[i]) / 10) return 0;
if (digits[i] <= 0 && ans < (numeric_limits<int>::min() - digits[i]) / 10) return 0;
ans = 10 * ans + digits[i];
}
return ans;
}Даже не надо думать об отрицательных числах особо, модуль сам выдаст нужные числа.
Edit: хотя даже 0 - не крайний случай.
Я доску даю. Так даже удобнее как мне кажется. Кандидату не надо утыкаться в ноут, а мне не надо подглядывать из-за плеча. Или каждому в свой ноут смотреть не надо. Это даже еще хуже. Все таки поговорить пришли, а не в ноуты смотреть. И от удаленных кандидатов я отказываюсь. Но это лично мое. Кому не подходит - ну и ладно.
Код я конечно написал до того как комментарий писать. Со второго раза верно вышло. Переполнение вниз забыл. На основе этого и оцениваю сколько кандидатов такое напишет за полчасика в стрессе. Если кандидатам заранее сказать что литкод будет, то шанс написания повышается с 1 из 50 до 1 из 10.
Кандидату не надо утыкаться в ноут, а мне не надо подглядывать из-за плеча
Ну, у нас там не любимая IDE кандидата, а онлайн редактор, который я на своем ноутбуке всегда вижу. Главная проблема доски - что там код редактировать неудобно, да и сейчас многие вообще буквы писать разучились.
Переполнение вниз забыл.
Ну для этого интервьюверы дают подсказки. За пол часа-то можно это исправить. И использование подсказок - это не черная метка.
Если кандидатам заранее сказать что литкод будет
Ну в тех же фаангах вообще даже ссылки на книги дают, что почитать можно для подготовки к алгоритмическим интервью.
Edit: И вообще, даже если вы забыли переполнение вниз, вы возможно получите максимальный бал за код, но плохо в графе "тестирует код". Если у вас такой косяк не во всех 3-5 интервью, то вас могут и нанять.
Меня то наймут. Точнее уже давно наняли. Я сам такие интервью провожу в довольно больших количествах и вижу кто приходит с какими резюме и что они на практике могут написать. Сложность определяю написав сам, а нормирую по уровню того что могут или не могут сделать кандидаты по опыту собеседований.
Моя ошибка это вообще не проблема. Исправляется реально одним примером данных на которых не будет работать. Кандидат написавший так же прошел без проблем.
Главная проблема доски - что там код редактировать неудобно, да и сейчас многие вообще буквы писать разучились.
Губка нормально стирает. Доска большая. Даже написать рядом новые 10-20 строк и потом стереть предыдущие не проблема.
Буковки ну как-то написать можно. Не красоту почерка оцениваем. Зато на доске можно квадратики систем дизайна порисовать. Вдруг кандидат достаточно хорош для этого?
Ну, у нас там не любимая IDE кандидата, а онлайн редактор, который я на своем ноутбуке всегда вижу.
И все смотрят в свои ноуты, а не друг на друга.
Буковки ну как-то написать можно. Не красоту почерка оцениваем. Зато на доске можно квадратики систем дизайна порисовать.
Главное неудобство - невозможность вставлять новые строки и необходимость стирать всю строку при малейшем в ней измененнии. Кандидаты много времени тратят на стрирание и еще больше нервничают. А систем дизайн - это отдельное интервью. И там, да, доска удобнее будет.
И все смотрят в свои ноуты, а не друг на друга.
А в вашем случае тогда - все смотрят на доску, а не друг на друга?
Главное неудобство - невозможность вставлять новые строки и необходимость стирать всю строку при малейшем в ней измененнии. Кандидаты много времени тратят на стрирание и еще больше нервничают.
Я это меняю на более простые задачки. Вроде смерджить Н отсортированных массивов. Точно такую же найти не могу. Между этой и этой. Тут и декомпозиция и продолжение о чем поговорить. И код простейший. И специальных знаний не нужно.
Когда на доске заставляют писать огроменные штуки на много десятков строк это плохо. Я против, но ничего сделать не могу. Регулярно вижу как валятся на таком. Валятся именно из-за неудобства доски для написания связного кода больше 10-20 строк.
А в вашем случае тогда - все смотрят на доску, а не друг на друга?
Да, и так лучше как мне кажется. В целом не только мне. Я спрашивал вокруг.
Я доску даю. Так даже удобнее как мне кажется.
Проходил собеседования и перед доской, и онлайн по зуму в любимой IDE. Мои ощущения: доску сжечь напалмом. Это разновидность пытки.
подглядывать из-за плеча
Этсамое... К нубуку можно подключить большой монитор :)
Олимпиадник?
Почему, собственно, предполагаю — контейнер, два цикла. Это не промышленное программирование — здесь достаточно единственного цикла, и уж точно нет никакой необходимости в контейнере.
Достаточно, да. Я это и сам заметил, но убирать контейнер не стал. Код так логичнее, на мой взгляд. Вот мы цифры получили, вот число собираем по простой формуле. Можно и объединить - но тогда все в кучу будет. В конкретном примере разница не такая большая, но если у вас что-то более сложное, то сохранить промежуточный результат и развести разные действия по циклам - гораздо читабельнее.
Как раз промышленное программирование - это наиболее читабельный и понятный код, при прочих равных. В микрооптимизации упарываться не стоит. Грамотно выбранный алгоритм и структуры данных обеспечат вам 95% всего ускорения.
Если бы этот код был в горячей точке, то стоило бы избавится то вектора, чтобы не было аллокаций памяти. На практике я бы его на какой-то InlinedVector заменил скорее, чем бы сливал оба цикла.
Олимпийский подход — максимально быстро выдать результат, ни на секунду не задумываясь об эффективности решения — очевиден чуть более, чем полностью. Но промышленное программирование довольно далеко от спортивного хотя бы в том, что любой код, который производит лишние и заведомо не нужные действия — это по меньшей мере лишний код. По чуть большей мере — вредительство.
Код ниже имеет ничуть не менее читабельный и понятный вид. Но вот что мне действительно странно, так это когда удаление из кода действий, которых там в принципе не должно быть (и никакой оптимизатор этого тоже не вычистит), называют упарыванием в микрооптимизации.
#include <stdint.h>
int
reverse(int x) {
int digit, res = 0;
while (x != 0) {
digit = x % 10;
if (digit >= 0 && res > (INT32_MAX - digit) / 10) return 0;
if (digit < 0 && res < (INT32_MIN - digit) / 10) return 0;
res = res * 10 + digit;
x /= 10;
}
return res;
}Если бы этот код был в горячей точке, то стоило бы избавится то вектора, чтобы не было аллокаций памяти. На практике я бы его на какой-то InlinedVector заменил скорее, чем бы сливал оба цикла.
В промышленном коде и этот “оптимизированный” вариант не прошёл бы code review, так как осуществляет бессмысленное разделение входных данных на бессмысленно хранимые составляющие.
И много вы тут лишнего выкинули? С точки зрения кода вы одну строчку только сократили. Да 9 сравнений, которые предсказатель ветвлений почти все угадает. Зато, если цифры надо будет не разворачивать, а сдвигать по кругу, то ваш код не исправить. Придется разбить на 2 цикла, как у меня.
А главное, тут нет явного разделения на этапы выделения цифр и собирания числа, что делает код гораздо понятнее. Это вкусовщина, конечно, и тут можно спорить до бесконечности. Но, например, можно выделить эти части в разные функции и вызывать их по очереди. Можно код переиспользовать. Опять же, в данном примере практически нет разницы между вариантами - код итак тривиален. Но будь задача чуть-чуть позаковырестее, мой подход был бы очевидно лучше.
лишние и заведомо не нужные действия
То, что один код эквивалентен другому - само по себе не значит, что какие-то действия там заведомо не нужные. Эти действия, как тут, могут нести смысл увеличения понятности кода.
С опытом начинаешь сразу писать поддерживаемый и расширяемый код. Возможно, и вы до этого дойдете, а не станете писать как можно более компактный код во чтобы-то ни стало.
Коллега, что-то мне подсказывает, что я в разработке ПО несколько дольше, чем вы живёте на этом свете. Вы даже не можете вникнуть в сказанное мной уже трижды:
ваш код выполняет работу, которая не нужна для решения поставленной задачи.
ваш код впустую использует память для хранения того, чего хранить не нужно для решения поставленной задачи.
Я не предложил код “как можно короче” (его можно уложить в два C-оператора, если хочется краткости в ущерб понятности и эффективности). Я предложил код, который оставаясь таким же понятным, как и ваш, не делает того, чего от него не нужно в поставленных условиях.
Поставьте ещё один -1.
Я предложил код, который оставаясь таким же понятным, как и ваш
Вот с этим я не согласен.
Вот еще пример: часто имеет смысл выделить сложные логические условия в отдельную переменную с именем. Это лишние действия и лишняя переменная, но я надеюсь, вы согласитесь, что это улучшает код. Вопрос о том, что перевешивает в конкретном случае - лишние действия или понятность кода - мы в споре не решим. Это вкусовщина.
Я ваше мнение услышал, с ним не согласен. Вы услышали мою мотивацию, но у вас другая оценка ситуации. На этом спор предлагаю закончить.
Знаете, раз уж я потратил свое некоторое время и силы на разбор этой задачи и спор по ее поводу с автором предыдущего комментария, то я вам от себя добавлю.
Во-первых, порядок разделения числа на цифры из этого решения - далеко не единственный (хотя, кажется, оптимальный), и даже - не самый очевидный: более очевидным IMHO является деление сначала исходного числа, а затем остатка от предыдущих делений на убывающие степени 10 со взятием частных в качестве цифр. Во-вторых, порядок сборки числа из цифр ровно так же не является единственным. В-третьих постановки задач в реальном мире изменчивы, часто - в непредсказуемую сторону (пример вам от оппонента был).
А потому ваше упортство в использовании совпадения (вообще говоря, мало чем обусловленного) порядка разборки и порядка пересборки числа - оно сродни настойчивому желанию вынести все куски повторяющегося кода в отдельную процедуру, вне зависмости, насколько общие сущности этим кодом обрабатываются.
Так вот, не знаю, учат ли уже сейчас этому студентов (ну, кроме общих слов про "SRP"), но люди, пытавшиеся так делать на практике, обычно довольно быстро получают инсайт о том, что такой код из разных мест для разных сущнойстей стремится ещё и меняться в разные стороны. А потому к ним обычно приходит просветление на тему, что так делать - не то, чтобы совсем нельзя, но надо осуществлять так же осторожно, как и любое нарушение ТБ.
Ваш случай и вариант, который вы упрямо отстаиваете - он в чем то аналогичен, хотя и попроще. Поэтому, во имя просветления, держите ещё -1 к предыдущему комментарию от меня.
Во-первых, порядок разделения числа на цифры из этого решения - далеко не единственный (хотя, кажется, оптимальный), и даже - не самый очевидный
По-моему оно самое очевидное, потому что это почти всем известный еще со школы способ перевода между системами счисления. Если делить на 2, то вы получите цифры в двоичном представлении. Чтобы получить десятичные цифры - делаем все тоже самое, только делим на 10.
А я бы из этого кода сделал темплейт "по константе основания" в надежде что реверс двоичного представления будет заменен на банальные сдвиги компилятором, а проверки удалены как избыточные.
Если не иметь какую-то минимальную базу, достаточную, чтобы решать вот такие задачи,
Вот ни хрена эта задача не на минимальную базу. Если бы ограничение по диапазону было -10^9..10^9 (а лучше 0..10^9), то тогда - на минимальную: разбить на цифры ( можно тупо - на 10^8 частное - первая цифра, остаток 0 поделить так же на 10^7 и т.д., но можно и немного упростить пойти с последней циры как остатка от деления на 10, затем остаток опять поделить на 10 - частное будет предпоследней цифрой и т.д.) а потом собрать из этих чисел число путем умножения в обратном порядке на степени 10 (опять-таки, можно тупо - унмножать на соответствующие степени 10, можно оптимизировать, взяв новую старшую цифру как результат и умножая последовательно на 10 и добавляя соответствующую цифру). Это все IMHO элементарно и что-то мне сомнительно, что есть технари, которые до этого не додумаются даже на собесе.
А вот аккуратно проверить граничные условия на соответствие диапазону Int32, не имея в запасе дополнительных разрядов - это уже не совсем тривиально, на собесе можно запросто что-то уронить. Поэтому на собесе конкретно такая задача - это проверка натасканности, а не сообразительности.
впендюрят n-квадрат на ровном месте и все
... и во многих случаях этот квадрат никому не помешает. Особенно, если знать, что число n будет заведомо небольшим. Я сам так делал, например когда надо было в таблице филиалов, меняющейся раз в несколько месяцев, т.е. - фактически при запуске программы-сервиса на Windows, и в которой даже по самым смелым ожиданиям вряд ли было бы больше сотни записей: читал конфигурацию этих самых филиалов, простыми вставками запихивал ее отсортированную в массив один раз при запуске, а потом сколько надо раз, столько надо искал бинарным поиском (который тоже был не столь частым, чтобы для него хэш-таблицу делать). К сожалению, в те давныие времена подходящей либы не было: это была древняя Delphi, и пишучи этот код, я тогда в течение целого дня люто завидовал плюсовикам с их STL (увы, по разным причинам на плюсах это было делать нельзя).
Но таки да, согласен: техник программист для успешной работы должен иметь под руками каталог алгоритмов.
А вот аккуратно проверить граничные условия на соответствие диапазону Int32, не имея в запасе дополнительных разрядов - это уже не совсем тривиально
Да ладно! Вот я ниже привел решение. Но, допустим, я олимпиадник-алгоритмист, который знает, как работает деление по модулю с отрицательными числами, помню со школы схему Горнера (название пришлось, правда, гуглить) и способен заметить, что функция 10x+d монотонно возрастает. Но даже без этого всего любой технарь способен проверить на переполнение, например, сравнив полученные цифры числа с массивом {2,1,4,7,4,8,3,6,4,7} до вычисления числа в int. Ну или сравнить со строкой. А отрицательные числа можно решить, развернув цифры абсолютного значения и вернуть минус ответ (правда, возникает один крайний случай с числом -2^31, которое по модулю не влезает в int. Но даже только забыв этот случай вы интервью не завалите).
Действительно плохой выбор задачи. Много нюансов, которые морочат голову, и почти ничего не скажут вам про кандидата.
Я писал прежде всего о подвохе в задаче: она называется "Перевернуть число", а в реальности оказывается, что, внезапно, надо ещё и проверять, что не будет переполнения. Эта внезапность в условиях собеса может сыграть злую шутку, на что я и указал - собсвтенно, комментарий был именно про это. И играет: кто-то, к примеру, забыл коррект но проверить для отрицательных чисел.
А как сделать эту проверку - это я уже начал думать позже, после нажатия кнопки Отправить. Только вот никакой монотонно возрастающей функции у меня в голове не появилось: сначала - проверка по цифрам (не понравилось), потом - аналог проверки в вашем коде, но только на 10-й цифре - в других местах переполнение возникнуть не может. На всё это ушло ещё где-то минут пять, так что я потом уверенно ответил, что на собесе я бы за полчаса явно решил (учитывая, что алгоритм переворачивания вообще тривиален, там думать-то особо негде, не говоря уж про зубрить).
PS И я рад, что в Гугле мелкие ошибки на тесте прощают. Но, увы, так не везде.
Это не подвох в задаче. Оно дано прямо в условии. Да, эту задачу можно усложнить, не говоря этого, тогда это будет подводным камнем. Но тогда и проверку переполнения можно разрешить в int64 делать, а вот это ограничение на 32 бита оставить на дополнительный вопрос.
сначала - проверка по цифрам (не понравилось)
Вполне рабочий вариант.
Это не подвох в задаче. Оно дано прямо в условии.
Правильно, подвох - в условии. Именно это я и имел в виду, я условие от задачи не отделяю. Да и спрятать его больше негде было.
Вполне рабочий вариант.
Мне не понравилось, что нарушается мнемоническое правило "не использовать магичские числа" (оно даже не из опыта, AFAIK теперь этому даже студентов учат): там возникают магические числа (цифры), которые я, к тому же, наизусть не помню. Потому стал думать дальше, благо ничто меня не подгоняло.
Правильно, подвох - в условии.
Нет, если вам прямо сказано об этом условии, то это никакой не подвох, который можно не заметить, как какой-то крайний случай. Подвох - это если надо как-то по иному интерпретировать условие или догадаться самому о чем-то.
что нарушается мнемоническое правило "не использовать магичские числа"
В моем решении тоже используется "магическое число": INT_MAX. Если константный массив/строку правильно обозвать, то код будет вполне отличный. Так-то там еще и "магическое число" 10 используется во всех решениях.
к тому же, наизусть не помню.
На интервью достаточно сказать, что "вот тут у нас массив с цифрами 2^31". Не надо эти цифры даже воспроизводить. Это же можно загуглить или подсчитать в калькуляторе за 2 секунды. Точно так же на интервью прощается незнание наизусть параметров стандартных функций, да и даже их имена. Я сам, когда интервью проходил (успешно), забыл, что там за lower_bound и upper_bound есть в stl - что конкретно они возвращают - больше-равное число или большее. Просто сказал интервьюверу, что какой-то такой метод есть. Вот допустим он возвращает самое левое строго большее число. Описал это в комментарии и все остались довольны. И сам на интервью к этому никогда не придираюсь.
Нет, если вам прямо сказано об этом условии
Согласитесь, что в названии подвох точно есть.
В моем решении тоже используется "магическое число": INT_MAX
Это не число - это идентификатор. На идентификаторы мнемоническое правило не распространяется.
На интервью достаточно сказать, что "вот тут у нас массив с цифрами 2^31". Не надо эти цифры даже воспроизводить.
Ещё раз респект Гуглу за отсутствие тупой упертости и буквоедства. Но не у всех эпигонов оно так, а большинство соискателей из РФ дело иметь будут, скорее, с эпигонами.
То что вы называете « инженеры, создающие решения», это не инженеры. Это квалификация уровня техникума. Среднее специальное образование – типа, специалист, который знаком с технологиями и может их правильно и грамотно применять. Есть фрезисты, слесари, токари и соответственно программисты. У программистов тоже есть «разряды» как у токарей. Только называются по другому – всякие джуны, миддлы и т.п. А ведь «программист 6-го разряда» не звучит хуже «токаря 6-го разряда».
В сфере ИТ, по сути 98% кадров являются именно такие специалисты. Другое дело почему считается что это инженерный уровень? Как по мне – инерция мышления. Отсюда и весь вой насчет вузовского образования – «мне эти знания никогда не понадобятся!». Конечно не понадобятся – ты хочешь работать на уровне среднего специалиста, почему тогда пошел учиться в университет?
В этом есть и другая проблема – есть тенденция из-за этого просто занижать и менять требования к высшему образованию, уменьшать теорию, увеличивать практику и знакомство с конкретными технологиями. Таким образом делая техникумы из вузов.
А это следствие "без вышки никак" и "будешь плохо учиться - в ПТУ пойдешь". А ведь люди со средне-специальным образованием - это как раз те, кто работает по готовым инструкциям от людей с высшим, но работает так, как люди с высшим не умеют.
Вот я, например, инженер. Я могу спроектировать деталь и рассчитать на прочность, но я не обработаю ее на станке и не (качественно) не сварю - для этого есть токарь, фрезеровщик и сварщик.
Но так печально сложилось, что работа руками у многих людей считается чем-то плохим или унизительным, а сидеть в офисе и перекладывать договора - хорошо. Нет, для договоров тоже нужно многое знать и уметь, но хороший слесарь знает и умеет не меньше.
В общем, да. ПТУ - это не плохое образование. ПТУ - это другое образование. И оно тоже нужно.
Тут есть два нюанса:
"А как?" как отфильтровать "гожего" кандидата от "негожего"? Особенно силами HR, который, в титульной деятельности... скажем так "в пределах четкой должностной инструкции". Потому, в условиях, когда кандидатов реально много, просто задирают планочку по-выше, как умеют, в надежде, что так пройдут только самые самые. Тащем-то помогает плохо. Видел пару раз, как в яндекс(в яндекс Карл!) проскакивали ТАААКИЕ персонажи на испытательный срок...
Наша деятельность - это ковыряние в торте Наполеон. Только слои там - из абстракций. Лично я для себя оч давно усвоил "если работаешь со слоем абстракции N, то должен понимать N-1". Если работаешь с интерпретатором, знай как. Если с базой данных, знай, как она обрабатывает данные в памяти, ну и т.д. и т.п. Алгоримты - это один из "придонных" слоев. "НуивотЪ" (с)
Знакомый работавший в кп/яндексе говорил, что часто проблему тормозов решали добавлением памяти/ssd/cpu, так как выходило намного дешевле. Чем неделями искать то самое проблемное место в коде
Которого может и не быть :)
Если проблему тормозов можно решить добавлением железа, то часто проще всего так и сделать. Однако железом вы, во-первых, даже в сотню раз обычно вряд ли ускорите (за исключением совсем патологических случаев), а во-вторых, что вы будете делать, когда кончится доступное железо?
Автор немного намудрил в классификации, на мой взгляд.
Инженер-исследователь и инженер по эксплуатации, вот как это называется.
Первый должен знать алгоритмы, доказывать теоремы, играть в науку и вызубрить все формулы с бумажки.
Второму достаточно знать, что где взять, куда и как прикрутить, какой шуруп заколотить молотком и владеть справочником как бог, а теоремы оставить в покое.
И когда вы нанимаете специалиста, определитесь, кто вам нужен, первый или второй.
Да, непременно выскочит советчик, который уверяет, что потребно все сразу одновременно и теорию доказать и на дуде сыграть и в карандаш без калькулятора уметь, плюс челом бел и бровьми союзен, а так не бывает.
В общем соглашусь с автором всесторонне, в 99 случаях нужен работник, но экзаменуют так, будто нанимают академика, который все равно окажется не фонтан и растечется мыслью по древу там, где проще, поюзав справочник по красным резиновым шарикам, херакс херакс и в продакшн.
Я помню, как меня пригласили собеседоваться в ••••.ру на позицию специалиста по UI в группу •••. Это был очень известный в своё время продукт (можно сказать, Грааль моего детства, тем более, у меня в детстве не было Интернета), который на момент собеседования слегка подзачах (UI определённо вносил свою лепту). Я подумал: “Make ••• Great Again!” — весьма достойная миссия, было бы здорово над этим поработать. Тем более, на предыдущем месте начиная с одной только имплементации чужих UI-макетов, я закончил проектированием нового функционала, работой с юзерами и т.п.
На собеседовании меня первым делом спросили, какие примитивы синхронизации в Windows я знаю. Сначала я хотел переспросить, точно ли эта та позиция, про которую мы говорили. Потому что я бы хотел услышать вопросы, как писать десктопные приложения на основе разметки и не тащить стометрового бегемота по кличке Хромиум. Почему такой приятный для глаза скевоморфизм устарел (это можно обосновать не только модой, но и объективными причинами — могу набросать постик, если кому-то очень интересно). Как происходит падение через шрифтовую решётку, почему тофу это невкусно и чем goto отличается от noto. Как встроить своё окно куда-нибудь в виндовое (или наоборот). На худой конец, про baNaNa (Ecma в UI используется широко, и это не просто так). С другой стороны, подумал я, в последнем проекте я действительно использовал примитивы синхронизации, и нередко. Наверно, они хотят поговорить не о том, с чем работает интерфейсник (это банально), а о том, с чем он встречается редко, но метко (можно сильно запороть юз-кейсы, если не уметь в многопоточность). И я ответил: критические секции, мьютексы, семафоры.
«Хорошо, но мало!», услышал я в ответ. «А теперь расскажите, как устроен мьютекс». Тут уже пришлось переспросить про вакансию (оказалось, не перепутали). Я, как мог вежливо, сказал, что не то, что не знаю, а знать не хочу — если бы меня интересовало устройство мьютекса, я бы писал ядра-чистый-изумруд. Как специализирующийся в UI разработчик, я знаю, как ими пользоваться и считаю это абсолютно достаточным. Знаю, когда использовать более лёгкие внутрипроцессные примитивы, а когда — глобальные, как избежать гонок, даже знаю удобный способ шарить прагмами хендлы мьютексов между процессами. Ну и как прилежный читатель Феня Юаня с грехом пополам умею вызывать разные WinAPI-функции для всего этого дела ;)
Собеседующий как будто всего этого не услышал. «А вы возьмите лист бумаги и попробуйте спроектировать мьютекс! Как бы вы это сделали? Какой алгоритм должен лежать в основе?». Я понимаю, что это уже не смешно, и говорю: «Мне кажется, я вам не очень подхожу» (про себя думаю, естественно, наоборот). На этом мы и попрощались.
Через год ••••.ру закрыла ••• за полной невостребованностью у юзеров.
Я ни на что не намекаю.
Инженеры-технологи не компетентнее тех, кто пользуется их решениями. Зачастую, они не могут оперативно собирать финальные продукты, пользуясь стеком решений. Эти инженеры узкоспециализированы. Как и те, кто собирает решения в продукт. Я ещë не встречал универсалов с одинаковой эффективностью в 100% сценариев.
Алгоритмы важны для сборщиков. Только, не всегда от них требуется работа со сложными алгоритмами. Можно сколь угодно разглагольствовать на тему "но он же допустит ошибку, если не знает как уменьшить сложность алго за счëт дифференцирования функции", и, всë-равно, человек, который знает, как выполнить математическую оптимизацию алго-функции, либо не будет достаточно компетентным, чтобы организовать связку микросервисов с шиной данных, либо его зарплатные ожидания сильно выше того, что готовы предложить в областях, где собирают готовые решения. Дело не в необходимости опыта решения алгоритмов, а в углублëнности этого опыта.
Я эти мысли озвучиваю всю свою жизнь и минусов понахватал за это время несчётное количество, хотя вроде всё же очевидно.
Для тех, кто любит рассказывать про гипотетического Васю, который из-за незнания O(n) накосячит и проект стоимостью 100000000000000 триллиардов квинтильонов долларов пойдёт в мусорку - не будьте детьми и перестаньте уже нести такую чушь - во-первых если ваш Вася занимает такую должность, что только от него зависит проект - то кто-то такого некомпетентного же поставил на эту должность?! Во-вторых, если Вася такой крутой и рулит таким проектом, он точно-точно будет банально сидеть кодить? В-третьих, ни за что не поверю, что у такого проекта нет "отдела качества" и тестировщиков.
Зачем вводить в беседу заведомо глупые придуманные примеры? Запомните, даже за самым-самым стоит человек или группа лиц, которые всегда скажут, если что-то не так, в одну голову ничего титанического сделать невозможно, та же наука работает от публикаций и рецензий, само научное сообщество фильтрует знания и новодел.
Так что в 99.(9)% задач сортировать будет метод из стандартной библиотеки, так же как проще внедрить UE5 чем создавать свой движок, особенно с нуля и чтобы угнаться за конкурентами. Физика, освещение, звук - вполне вероятно уже люди поумнее всё написали, в конце концов сейчас 2023 год, а не 1972.
Зачем вводить в беседу заведомо глупые придуманные примеры?
...когда можно использовать примеры из реальной жизни ни на йоту не умнее?
При этом проект собрал "всего" 8 миллиардов долларов!
Снимите розовые очки - "отдел качества" и тестировщики - не всемогущи!
...когда можно использовать примеры из реальной жизни ни на йоту не умнее?
розовые очки - это думать что все и всюду будут мега-специалистами. А этот пример хорошее тому подтверждение что никакие "алгоритмы на собеседованиях" не работают, ведь это случилось в той самой парадигме, а не в моей, то есть я как раз прав.
"отдел качества" и тестировщики - не всемогущи!
конечно нет, когда у вас некомпетентны кадры в целом, включая топов.
или вы думаете что при самодуре-начальнике великий программист будет писать идеальный код и программа будет идеальна от и до? у ваших розовых очков еще и +5 линзы.
или вы думаете что при самодуре-начальнике великий программист будет писать идеальный код и программа будет идеальна от и до?
Программист, не имеющий понятия об алгоритмах будет писать ужасный код при любом начальнике.
А этот пример хорошее тому подтверждение что никакие "алгоритмы на собеседованиях" не работают, ведь это случилось в той самой парадигме, а не в моей, то есть я как раз прав.
Нет, это показывает что проблемы иногда проскальзывают даже с "алгоритмами на собеседованиях" - и если б их знание не проверяли, то всё было бы значительно печальнее.
Алгоритмы - это часть арсенала программиста; на собеседованиях никто не просит придумать их с нуля, проверяется их знание и то, какие критерии программист использует для выбора подходящего из них для поставленной на собеседовании задачи.
Программист, не имеющий понятия об алгоритмах будет писать ужасный код при любом начальнике
Это не мешает им зарабатывать миллиарды. То есть вам нужно определиться что для вас важнее - алгоритмы и код или доход?
Алгоритмы - это часть арсенала программиста
Думаю алгоритмы пригождаются почти никогда, нужен только скилл на их правильное применение.
Да с чего вы взяли, что не мешает?!
Думаете, необходимость ждать в лобби по 25 минут не стоила Rock* нескольких миллиардов упущенной прибыли?
Несчесть проектов, которые загублены багами и отвратительной производительностью...
Думаю алгоритмы пригождаются почти никогда, нужен только скилл на их правильное применение.
Скилл на их правильное применение требует хотя бы знание того, какие алгоритмы существуют..
Думаете, необходимость ждать в лобби по 25 минут не стоила Rock* нескольких миллиардов упущенной прибыли?
Точно не стоила, ведь у них просто нет конкурентов.
Думаете, необходимость ждать в лобби по 25 минут не стоила Rock* нескольких миллиардов упущенной прибыли?
Я не играю в такое, но судя по тому что почитал сейчас - проект-то без альтернативы, так что ждали и платили.
Скилл на их правильное применение требует хотя бы знание того, какие алгоритмы существуют..
Я знаю очень много алгоритмов, но практически не умею их применять. Например я про графы читаю раз в пол года и не понимаю что с ними делать. Сортирую std::sort() или кастомлю что-то O(log2(n)) если совсем делать нечего. Основное - перемножение матриц, двоичная арифметика, векторы, графы, сортировки, поиск подстроки и т.д. - это знают вообще все, умеют ли пользоваться? Ну да, std::sort(). Или думаете кто-то программирует кастомного Хаффмана или LZ днями и ночами? Ну и все-все-все алгоритмы всё равно никто не знает, так что нет никакого "какие алгоритмы существуют". Я тут у знакомого из США как-то спросил "пользуется ли он гамма-кодами Элиаса?" Предсказуемый ответ: "Чем?"
У любого развлекательного проекта есть куча альтернатив - бросить и потратить время на какое-нибудь более интересное занятие, например, посмотреть фильм про высыхающую краску.
А если этот проект ещё и существует на донат - то есть альтернатива "не донатить".
А насчёт "много алгоритмов" - сомневаюсь, что на собеседованиях просят всякую экзотику. Скорее спрашивают базовые вещи - чтобы не скатываться в линейный перебор или не требовать вдвое больше памяти, чем требуется для решения задачи там, где это ограничение важно.
У любого развлекательного проекта есть куча альтернатив
Ну если мы говорим про амёб. Вы - амёба? Уверен что нет, и я не амёба, поэтому если я хочу поиграть в выживайку The Long Dark, то вы меня не отвлечёте от этого даже другой выживайкой Subnautica. Точно так же играющий в танки у одной компании не кинется играть в танки у другой. Или смотрящий сериал про вампиров не кинется смотреть другой тоже про вампиров. Опять же,если мы не говорим про амёб. И если человек ждал Starfield и получил длинные загрузки, то он будет играть в Starfield с длинными загрузками, а не переёдет на No Man Sky.
А чтобы кинуть игровой проект и начать смотреть видео про высыхание краски - ну это вообще вы про каких-то овощей рассказываете.
сомневаюсь, что на собеседованиях просят всякую экзотику
Вы только что сами написали "требует хотя бы знание того, какие алгоритмы существуют" и тут же отказываетесь от своих слов. Неконструктивный диалог.
Вы путаете игровой процесс в GTA Online и процесс созерцания загрузочного экрана GTA Online. Сравнивать надо именно второй, и удовольствие от этого абсолютно такое же, как от наблюдения за высыхающей краской.
Игроки - не британские цензоры, им никто не платит за такое созерцание поэтому они найдут себе другое занятие, и есть ненулевая вероятность, что это другое занятие для этих игроков в конце концов окажется интереснее и они забросят игру - из-за чего Rock* и потеряло миллиарды.
Вы только что сами написали "требует хотя бы знание того, какие алгоритмы существуют" и тут же отказываетесь от своих слов.
Никто не спрашивает все алгоритмы - скорее такая узкая специализация окажется кандидату во вред. А вот спросить знание алгоритмов, применяющихся в данной предметной области как раз стоит.
Единственное, о чем говорит этот пример:
человек скорее всего не дочитал документацию или взял первое попавшееся. (Или по вашему тут алгоритмист должен был с нуля что-то писать?) Уповать на "не знает O(n) от O(n²)" - нету смысла, маловероятно.
В компании нет контроля качества, как и свободного времени заниматься улучшением кодовой базы (а ля менеджмент не поставил таск - ничего не делаю).
О проблеме долгих загрузок GTA5 знал каждый игрок. В моем случае я лишь увидел 100% одного ядра во время загрузки и подумал "ну таким образом грузится значит..." Это надо годами не замечать слона.
Как это сегодня бывает, не было бы античита - пофиксил бы кто-то из сообщества раньше. Будь открытый движок - ещё раньше. Прислушивались бы к отзывам пользователей + багтрекер - аналогично. Но что ожидать от компании, которая техподдержкой писала отписки пользователем, у которых не пришла оплаченная микротранзакция.
Может люди поумнее все и написали, но при "умелом" подходе можно "один сломать другой потерять"(с). История хранит, а окружающее нас ПО каждый день напоминает пользователям, что некомпетентных сотрудников назначают некомпетентные начальники, и отдел тестирования это не панацея, а продукт надо выпустить вчера. Пользователю не легче от числа "Вась" в коллективе. А вот вокруг удачных архитектурных (включая алгоритмические) идей возникают удачные долгоживущие проекты, отправляющие тех самых конкурентов в историю. Заложить в основу проекта такие идеи способен даже один толковый человек понимающий алгоритмы, задача остальных - не утопить идею при реализации. Без понимания алгоритмов, можно и не реализовать, то заложенное конкурентно преимущество на "вау" уровне, способное привлечь пользователей.
Запомните, даже за самым-самым стоит человек или группа лиц, которые всегда скажут, если что-то не так, в одну голову ничего титанического сделать невозможно, та же наука работает от публикаций и рецензий, само научное сообщество фильтрует знания и новодел.
Только отфильтровать можно в разные стороны. Можно путём изменения эффективности кода, можно путём изменений ожиданий публики, можно путём изменения требований, можно путём изменения бюджета и т.д.
Про то, как работает научное сообщество, тоже можно очень даже поспорить. Публикаций и рецензий очень много, а движения научного знания вперёд мало.
Для тех, кто любит рассказывать про гипотетического Васю, который из-за незнания O(n) накосячит и проект стоимостью 100000000000000 триллиардов квинтильонов долларов пойдёт в мусорку
Вы правы, это крайне маловероятно. Типичный вариант - это Вася вставит O(n^2) вместо O(n), написав, к примеру strlen в условии цикла. Код слегка замедлит выполнение, что будет незаметно. Но в случае пика нагрузки (в 10), потоковая обработка, которая в теории должна сработать, катастрофически замедлится, пропустить timeout, после чего вам пойдёт звонок. И если Вася проработает год-другой, таких мест будет много, а, соответственно, спать вам будет нервно и неприятно. А значит, придётся тратить очень много времени на рецензирование PRов Васи. Это тоже неприятно.
Код слегка замедлит выполнение, что будет незаметно.
Да тут не надо даже пика нагрузки. Просто примерно вся программа будет раз в 5 медленнее, чем могла бы. Потому что там за каждым уголом O(n^2) вместо O(n).
Это замедление как раз легко парируется методом «просто добавь машин». Сейчас это особенно легко с виртуальными машинами. Да, латентность таким образом не лечится, но это, обычно, не проблема.
Проблема получается в динамике, может быть даже адиобатической, когда у вас система написана под 10к запросов в секунду и написана более-менее линейно-масштабируемой. А через год у вас всё возрастает до 30к, а какой-то участок тормозит не в 3 раза, а в 10.
Я никогда не работал в софтверной компании, но вы все тут через одного пишете, что какой-то Вася у вас чего-то там пишет единолично - объясните, как такое может быть? Я скрипты на PowerShell когда внедрял для автоматизации работы сисадминов, я их утверждал, писал подробную инструкцию и мне потом сисадмины-коллеги вопросы задави а потом предлагали что-то поменять. А у вас Вася годами что-то пишет и никто не в курсе, дял меня это нонсенс, поэтому в качестве аргумента я такое не принимаю. Это сугубо вопрос некачественного руководства в компании, а не программирования.
что какой-то Вася у вас чего-то там пишет единолично - объясните, как такое может быть?
«Господин Журден и не подозревал, что вот уже более сорока лет говорит прозой...» Вы тоже пишите единолично (у вас же нет друга-телепата?). И о ещё необнаруженных косяках ваших программ тоже никто не в курсе.
так я пишу дома "в стол", а мы как бы говорим о бизнесе.
Я скрипты на PowerShell когда внедрял для автоматизации работы
сисадминов, я их утверждал, писал подробную инструкцию и мне потом
сисадмины-коллеги вопросы задави а потом предлагали что-то поменять.
Это не в стол — это «продуктовая разработка». Вы, ув. @Zara6502 таки пишете прозой, как и все мы.
Да, «бизнес» звучит гордо, но реально любой узкой темой занимается небольшая группа из 3-5 инвалидов. Больше нельзя, как, знаете, нельзя бить ногами вдвадцатером одного человека — большие затраты на синхронизацию.
Есть определённые практики, которые никто не мешает адаптировать для дома (CI/CD, VCS, рецензирование — даже в одиночку, проглядывая на след. день, помогает).
вы написали много, но не понял я ровным счетом ничего.
если у вас есть опыт работы только среди 3 инвалидов, то это не репрезентативная выборка, это не значит что везде так и что так и должно быть. Тогда уж предлагайте HR писать статьи про разделение подходов при найме инвалидов и всех остальных. Потому что придумывая кейс вы не разрушаете принцип, вы просто этот кейс пытаетесь натянуть на глобус, что очевидно не будет работать. Так что вы не правы.
Отдел качества также может состоять из людей, которые знают только про функциональное тестирование, а про нагрузку им на курсах не рассказывали. Да и понимание, что под Интерфейсом лежит, часто заканчивается на HTML/CSS.
У тестирования такая же проблема, а скорее всего это уже не QA, а QC, если не testers. Потому что «проще купить новую память», «нанять еще 5 тестировщиков», чем подумать, на что и реагирует индустрия.
Я не собеседовался в Яндекс и достаточно поверхностно знаю алгоритмы. Но мне всегда казалось, что эти холивары имели бы смысл только в случае, когда нормальные работодатели смотрят резюме, проводят скрининги и т.п., а вот яндекс и фаанг выкатывают оферы и вешают лычки чисто по рейтингу на литкоде. Как один из критериев отбора алгоритмическая секция ничем не отличается от пресловутой строчки "коммерческий опыт" в резюме, эйчар-скринингов и т.п. В идеальном мире конечно любого желающего с вайти-курсами за плечами стоило бы взять на 3 мес испытательного и смотреть, вдруг он окажется лучше того олимпиадного программиста с солидным айти-дипломом, который умеет деревья балансировать. Подозреваю, что как только в том же Яндексе соотношение вакансия/резюме опустится ниже какой-то отметки, там моментально забудут про все эти секции и ничего при этом не потеряют. Но пока не перевалило, надо же как-то кандидатов отсеивать и алгоритмы способ далеко не самый плохой.
Почему эти «алгоритмические задачки» вообще так популярны на собеседованиях и почему руководство верит, что так они смогут отобрать хороших программистов — вопрос открытый.
Могу предположить - лень интервьювера.
Алгоритмы это как приправа в блюдо. Без приправы - не очень. Но и жрать одну только приправу - идиотизм. Если все 9000 этапов собеса крутятся вокруг алгоритмов, то это какое-то кровавое шапито, а не оценка кандидата.
Вот в целом согласен, но не в случае с Яндекс! Потому как им нужны и "простые кодеры", и очень продвинутые ребята, и компания дает возможности роста чуть не до небес. Вторые только и могут вырасти из первых, все эти мечты "из грязи в стразы" сразу же - ну такое
Нет-нет. В Яндексе, если вы прошли первый фильтр(я прошел с третьего раза), то вас ждет нормальное дружелюбное собеседование с компетентными профессионалами.
Вот только там меня сразу спросили "статическое связывание". И залип.
Мне понадобилось минут 10 чтобы спросить у яндекса и хлопнуть себя по лбу "так этот способ вызова, оказывается НАЗВАНИЕ ИМЕЕТ!!!" :))))))))))))))))))))
Естессно мы вежливо распрощались :)))))
Прав ли был коллега? Прав!
Потому, что как любой крупной корпорации, яндексу нужны "детальки" которые сядут в посадочные места без допусков и начнут функционировать без раскачки.
Это если бы им понадобился реверс-инженер для поиска багов в забытых приложениях, я был бы к месте :) Наверное...
Больше удивляет, что через такой, вполне годный фильтр иногда проскакивают совершеннейшие "чуда-юда"
В Яндекс я собесился на зарплату Х, которая была на самом деле смешно малой даже по тому времени. Собесился с учётом того что у меня за плечами годы стажировок, успешных проектов, работ. Позиция - разработка ПО.
Так вот, у меня почти сразу начали спрашивать за хитрые обходы деревьев, я что-то попытался ответить, но всё больше ловил в себе мысль "что вообще происходит?". Дали написать какой-то код, который я написал не самым оптимальным образом. И потом мне сказали что я им не подхожу.
Поменяв в резюме ЗП с Х на 2Х я нашёл нормальную компанию Сбер, в которой мне задавали нормальные предметные вопросы. Была также и парочка предметных вопросов с подковыркой, но я ввиду своего многолетнего опыта смог ответить верно. Никакой ерунды ни про графы, ни про деревья, ни про алгоритмы.
Естественно всё прошёл, кайфую, дорос до техлида, ЗП давно перевалила за 3Х. Соболезную тем кто уходит работать в Яндекс на подножный корм. Мало того что унижают, так ещё и не платят толком. А ещё руководство высказывает всякую херню в публичное поле, что стыдно становится.
Лучшее лекарство от всех болезней в коде - это нагрузочное тестирование. А реализацию любого алгоритма можно у чат джпт спросить. Отстали от жизни интервьюеры, которые требуют знания, которые в элементарном доступе и пригождаются только тогда, когда начинается пресловутая оптимизация после нагрузки. Я за свою жизнь ещё не разу не видел, чтобы написанные опен сорс решения не болели болячками. Хоть многие и считают что все эти вещи делаются супер умными людьми, но прикол в том что именно людьми.
Вывод какой - берёшь готовую деталь - оттестируй её нагрузкой по своим кейсам, точно также как свой продукт. Просвятишься однозначно.
И как знания алгоритмов помогут тебе в оптимизации СУБД например, которая тормозит на твоих кейсах. Да никак. Ишью повесишь разрабам и будешь ждать фикса.
Не существует человека который с первого раза написал супер оптимальный чудо код. Да и с 10 го раза редко получается. И то что код оптимален может сказать именно интеграционный нагрузочный тест, который долбит по апишке или gRPC. А то иногда ведь пишут бенчмарки просто на функции ну и типо гляньте - она быстрая.
Хорошо если тестировщик смог отловить ситуацию(например, нагрузочным тестом) когда программист по незнанию применил неэффективный подход, плохо, когда ни тот и другой по незнанию не сообразили где нагрузить и оптимизировать. Мне, как пользователю, ежедневно приходится сталкиваться с неадекватно длительными ожиданиями при работе с программами, созданными в таких парах. Прозвучит категорично, но соискатель с глубоким знанием алгоритмов перспективнее, чем без таковых, пусть даже на должность дворника (уверен даже там можно оптимизировать подходы). ))
Есть разработка, а есть производство. Учить алгоритмы - означает возможность хотя бы прочитать научный пейпер со сложнейшей математики и реализовать его. А не зубрить алгоритмы сортировок - вы обязаны по-умолчанию их знать и уметь применять и создавать свои собственные.
Разработка - это итерационный поиск нового оптимального решения, где нужно реализовать сразу множество решений и выбрать лучшее.
Произвоство - это реализация оптимального решения и поддержка его. У производства есть четкие сроки.
Это две разные области со своими задачами и технологиями.
Утверждать что разработка не нужна, придумывать ничего не нужно, и так сойдет, и что все можно собрать из готовых решений - такое может сказать только кодер вообще без опыта
Разработка нового решения почти всегда выгоднее использования готовый решений, из-за специфики программирования.
создавать свои собственные
И как, много новых сортировок создали?
Каждый год по одной, в среднем.
Сортировка на gpu, различные сортирвки для отрисовки прозрачки, и не зависячищие от порядка, всякие аналоги-ZBuffer, быстрейшая сортировка для целочисленных массивов, сортировка для балансировки kd-деревьев, сортировка pointcloud для автоматического лодирования, стохастическая сортировка.
В основном это эвристические алгоритмы, так как они самые быстрые, но они не универсальны. И их просто так не реализовать, нужно дорабатывать под конкретные задачи и являются объединением сразу нескольких алгоритмов.
Лучший алгоритм сортировка - это отсутствие необходимости сортировать.
Замечательно. Но как из этого следует, что каждый разраб обязан по умолчанию придумывать свои сортировки? Будет задача по работе - сядем и придумаем. Не будет - ну уж извините, не все игровые движки пишут. И тем более почему все должны по щучьему велению рожать это все на собесе за отведенные 45 минут? Чем этот снобизм отличается от "не служил - не мужик"?
Опишу простой кейс, где знание алгоритмов must have: LiveJournal. Написан на Perl, его движок работает с точки зрения производительности чуть лучше, чем отвратительно. Единственный вариант сделать его чуть быстрее и адекватнее - найти самые медленные части и переписать алгоритмически эффективно. Желательно ещё и с применением XS (компилируемого в бинарь кода на Си, подключаемого как обычная перловая библиотека).
И это, к сожалению, очень типичный кейс, особенно, как мне кажется, в российском мире разработки, где основным заказчиком через пятые руки, но всё равно является государство (и это точно не про эффективность). В чём кейс? В том, что компании хотят что-то изменить, ничего принципиально не меняя. Улучшить давно сдохший в муках движок, но не переписывать его на другом языке с нуля, оптимизировать какие-то куски библиотек для взаимодействия с ЦБ, но не менять сами библиотеки, потому что ошибка может стоить слишком дорого, а "бизнес" устраивает статус-кво (работает - не трожь), заменить кусок последовательного кода без намёка на треды и асинк, алгоритмически оптимизировав в нём 10% (хотя можно было получить +300% прироста производительности, всё-таки переписав движок).
Бизнес очень консервативен сам по себе, даже в сфере IT. Бизнес, взаимодействующий с богатым, но чреватым безумными штрафами и даже уголовными делами государством, - часто и вовсе костенеет, становится пугливым и неповоротливым до (бес)предела. И всё, что он может себе позволить - это гальванизация трупов кода из юрского периода ботоксными подтяжками правильных алгоритмов. То есть бизнес конечно начинает в какой-то момент осознавать проблему и хочет что-то изменить, но... только ничего не меняя. И чем крупнее бизнес - тем безнадёжнее и абсурднее ситуация в этом плане. И Yandex здесь - совершенно не исключение, хотя там есть, куда применять навыки написания алгоритмов, особенно в таких штуках как проекты, завязанные на картографию и AI.
Не перестаю удивляться, почему люди начинают приводить аналогию из тех областей, в которых они сами дилетанты. При этом серьезно полагают, что их рассуждения дилетанта доказывают их правоту в совершенной иной области деятельности, где они считают себя профессионалами.
Если Вы не инженер водопроводчик, то откуда Вы знаете технологию разработки водопроводных систем? Вы в данном случае рассуждаете как дилетант, а дилетанту - все просто.
Если Вы программист -профессионал, то и рассказывайте на своем примере.
"Почему эти «алгоритмические задачки» вообще так популярны на собеседованиях и почему руководство верит, что так они смогут отобрать хороших программистов — вопрос открытый. "
Отвечаю на ваш вопрос. Потому что разработка алгоритма - это универсальное решение задачи, которое может быть реализовано на любом языке программирования.
Из своего опыта могу сказать , что порою выбираю язык программирования исходя из решаемой задачи.
Написать программу по хорошему алгоритму как два пальца и подобно переводу хорошего рассказа с языка писателя на язык читателя.
Странно, что, пролистав все комменты, все разговоры об одном и том же, - CPU, RAM, риск случайного комбинаторного взрыва, и противоположная позиция, что всем этим можно пренебречь.
А проблема ведь алгоритмически слабых инженеров она в другом, как правило. Не в том, что счёт из облака придёт больший, а в том, что они неспособны решать задачи на высоком уровне абстракции. И это приводит к раздуванию объёма работ на порядки (с сопутствующим раздуванием time2market, объёма правок при доработках, тестирования). И решение, созданное сильными алгоритмистами, становится принципиально конкурентоспособным для бизнеса, а не, условно, полтора ядра экономит.
Проведу пример из жизни. Проект - терминал управления коэффициентами для букмекера. На вид что-то вроде эксель таблицы с фиксированным лейаутом в зависимости от вида спорта. Оператор может там часть ячеек запол руками, часть заполнится сама при помощи внешних (не входящих в скоуп) алгоритмов. Команда что-то около 10 чел. Архитектор в алгоритмах очень слаб, но опыт программирования имеет солидный. Что он делает: показывает мастер-класс команде, как надо сделать раздел для футбола, создав контроллеры, фронт, логику запрограммировав, с алгоритмами проинтегрировав. Это время он вместе с командой кодит. Потом говорит, мол, я вам указал путь, остальные 25 видов спорта делайте по образу и подобию. Команда начинает делать. По виду спорта за 2 месяца. Потом, набив руку в копипасте, ускоряется до 1 вида спорта за месяц. Потом самый алгоритмически продвинутый член команды пишет кодогенератор, и команда выходит на финишную прямую со скоростью 2 недели на спорт. Года за 2 они заканчивают и даже празднуют сие событие.
А теперь давайте оценим, что произошло. В итоге у нас огромный и раздутый копипастой репозиторий, который почти невозможно поддерживать, необходимость ждать ещё 2 недели, если новый вид спорта появится, хорошо прокачанный скилл копипасты. Если операторам надо лейауты менять, это задача на разработку, которая становится в очередь.
И это при том, что, будь архитектор алгоритмически подкованным, он бы понял сразу, какой взять уровень абстракции. Понял бы, что, условно, писать контроллер и dto для баскетбола бред. Что лейауты можно не кодить программистами, а загружать из того же экселя динамически. Фактически, проект можно было изначально сделать очень компактным и гибким. Отдать 90% конфигурирования бизнес-аналитикам (или линейным руководителям операторов системы), а программистам оставить лишь сложную алгоритмическую часть по преобразованию эксель таблицы с лейаутами, привязками ячеек к алгоритмам, условиями взаимодействия ячеек между собой, в работающий терминал в момент запуска. Тогда бы и заняло это не 2 года. И, что важно, решение бы вышло очень гибким. Операционные отделы продолжили бы настраивать его под себя, никого не беспокоя, пока программисты перешли бы на новые интересные задачи.
По вашему описанию проект больше пострадал от отсутствия грамотной проработки предметной области и проектных ошибок, нежели от незнания алгоритмов исполнителями. Автор скорее указывает на то, что программист зачастую выступает в роле транслятора пожеланий менеджера или заказчика в исполняемый код. В такой схеме места для реальной инженерной работы действительно практически не остаётся, и польза от "ворлдскиллов" и правда превышает профит с фундаментальных знаний. Но это только в ближней перспективе. А потом все ошибки проектирования, "временные" решения, дыры в алгоритмах из тысяч условий под каждый найденный тестированием "частный случай" начнут обваливать проект прямо на головы вот таких вот умников, для которых "алгоритмы не важны".
Да, Вы определенно правы, что проект пострадал из-за отвратительного проектирования. Но, почему так вышло? Архитектор ведь не был классическим говнокодером. Он практически наизусть мог цитировать "Чистый код" Мартина и "DDD" Эванса, постоянно на конфы ходил, паттерны знал. Моё мнение, что его проблема (и проблема подчиненных, которые не нашли что возразить) была в неспособности мыслить на правильном уровне абстракции.
И, тут уже моё наблюдение, что этот скилл отлично коррелирует с пониманием алгоритмов. Люди, которые показывали хорошее понимание алгоритмов на собеседовании, хорошо справлялись и с абстракцией в работе, и наоборот. Возможно, потому, что опыт с алгоритмами и пониманием, как оно работает внутри, заставляет задавать правильные вопросы, а не тупо транслировать документ с требованиями в доменную модель. Это причина, почему лично я всегда предпочту нанять человека, который, например, сможет запрограммировать вывод множества всех подмножеств и оценить сложность этой операции перед тем, кто зависает уже на объяснении задачи на примерах (чтобы незнание терминологии не стало преградой). Вот, как-то так сложилось, что такие люди способны выбрать правильный уровень абстракции и предложить изменение ТЗ, способное улучшить ценность значительно, а не просто где-то пол ялра сэкономить
Ну, козырять цитатами из умных книжек по разработке горазд сейчас любой с парой тысяч на кармане и умением совершать покупки на Озоне. Я за свою практику таких "рецептов успешной разработки" наслушался. Причём не редко от людей, которые слыхом не слыхивали про бинарные деревья и хэштаблицы и начинают блеять, когда заводишь разговор о том, какую конкретно типовую проблему конкретно этот чудо-рецент призван был решить и какое она имеет отношение к конкретно нашим палестинам.
"Уровень абстракции" - приятный уху программиста термин. Но тут всё проще. Образованного специалиста в любой области и отличает способность взглянуть на решаемую проблему комплексно. Зачастую заглядывая при этом за рамки предложенных регламентов и ТЗ - причём даже непроизвольно. Даже не в силу особого ума, у него просто асоциативный ряд априори больше.
Но стоит признать, что автор отчасти прав. Я (и вы, думаю, тоже) по-старинке понимаю под программистом именно специалиста по составлению и реализации алгоритмов для решения прикладных вычислительных задач в определённой области. В то время как по должности программист часто - тот, кто заставляет компьютер выдавать удовлетворяющий заказчика результат. Неважно какими средствами. Продолжая (бестолковый) пример с водопроводчиком, задача программиста - хоть скотчем и жвачкой склеить трубы, лишь бы их при заказчике не пробило и он принял работу. Лопнут под нагрузкой из-за того, что не было "технологического инженера", пояснившего бы за закон Пуазейля - так нужно же было оформить соглашение о поддержке. Если цель заработать денег, а не сделать дело - это удачный подход с большими шансами на успех.
и проблема подчиненных, которые не нашли что возразить
А как была выстроена культура команды, разрешалось, поощрялось возражать и озвучивать идеи?
И это при том, что, будь архитектор алгоритмически подкованным,
Но ведь ваш пример как раз про другое, что именно ключевым было проектирование, а не алгоритмы. Архитектор вбрал заведомо не подходящую парадигму для проекта и алгоритмика в обычном понимании ему бы не очень то помогла.
а программистам оставить лишь сложную алгоритмическую часть по преобразованию эксель таблицы с лейаутами, привязками ячеек к алгоритмам, условиями взаимодействия ячеек между собой, в работающий терминал в момент запуска.
Вот как раз алгоритмически тут нет ничего сложного, сложно нормально спроектировать систему типов чтоб люди потом не умерли пытаясь расширить её не типовым лайутом.
Ваш пример несколько об ином - программист занялся работой архитектора.
В вашем примере ошибка не столько алгоритмическая, сколько архитектурная: неэффективный дизайн решения.
Ведь, как вы сами описали, исключить повторяющийся код, отдать подстройку под спорт бизнесу - это больше дизайн решения.
Проблема хоть программирования, хоть какой угодно другой области применения человеческих усилий, одна - высшие посты занимают те, кто понятия не имеет об олимпиадных задачках. Всё остальное - следствие.
Хотя у проблемы начальников тоже есть корень. Но критиковать читателей здесь не принято.
Помимо меня, также 20 лет занимающимся программированием, с вами, думаю, будет согласен Ли Кай-Фу, когда-то программист, а теперь ИТ-миллиардер, который в своей книге "Сверхдержавы искусственного интеллекта" писал также что есть два типа разработчиков - создатели моделей и иже с ними, и тех, кто их использует. И как вы писали, первые гораздо более технически подкованы, но для конечного пользователя и распространения ИИ нужны в большей степени вторые.
вообще этим должны заниматься скорее математики, а не инженеры
А Вы знали, если неправильно расположить насос для водоснабжения или неправильно выбрать его мощность может возникнуть кавитация на лопастях, которая очень быстро их разрушит?
Ошибочно считать что знание алгоритмов бесполезно в коммерческой разработке. Компании которые проводят такие собеседования не разрабатывают сайты визитки на 100 пользователей. Была недавно статья на хабре от озона про 1 млн рпс. Сколько будет стоить ошибка которая приведет к росту потребления памяти в 1.5 раза в их сервисе? Порядок, думаю, сотни тысяч $ в месяц. Без учета того, что у них может не быть таких запасов, а значит сервис упадет и это будет стоить еще дороже. Яндекс и подобные, кроме нагруженных сервисов еще и БД свои пишут, балансировщики, поисковые движки. Те коммерческая разработка это не только рест контроллеры и раскрашивание кнопочек.
То что вы описали называется энтерпрайз хайлоад продукты. Помимо них существует бесчисленное множество компаний в тысячи раз меньше и им это всё не нужно.
Не все хотят работать в ФААНгах и энтерпрайзе.
Кто то хочет пилить стартап в команде из 1-5 человек, а не автоматизировать предприятия или писать банковские сервисы. Разные люди, разные задачи и разные навыки нужны.
Равно как я очень скептически отношусь ко всякому «спортивному программированию», где на скорость люди решают какие‑то полуматематические задачи — поскольку это совсем не те навыки, которые нужны программистам в реальной жизни и в реальной работе. Это какая‑то «параллельная вселенная».
Не редкость, что спортивные навыки малополезны в реальной жизни. (Например, действия, применяемые в автоспорте, обычному водителю строго противопоказаны и даже запрещены). Тем не менее, это в целом хороший показатель мастерства человека в этой сфере, в т. ч. потому что ему будет проще подстроиться к реальным сложностям.
Сознательно не трачу время на подготовку к алгоритмическим интервью, leetcode и работе в таких компаниях. Обычно где желающих очередь, там и отношение к сотрудникам как к легко заменяемому ресурсу.
Хотя мне иногда все же приходится освежать знания и использовать асимптотическую сложность алгоритмов при решении своих задач. Последний пример из своей практики для задач маршрутизации описал в Онлайн визуализация алгоритмов: жадного, Дейкстры, A* и двунаправленного поиска
Обычно где желающих очередь, там и отношение к сотрудникам как к легко заменяемому ресурсу.
Ну, в гугле отличное отношение. Хоть и портится потихоньку. Но все-равно - одно из лучших, как мне кажется. Сокращения-увольнения первый раз в истории случились в этом году. Удаленная работа, шикарный офис с плюшками и хорошая зарплата. Даже если вы плохо справляетесь со своими обязанностями, вас не уволят, а переведут на personal improvement plan, и будут долго пытаться вас вытащить.
По моим наблюдениям история на собесах как с задачей о люках. Спрашивают потому что так спрашивает и Гугл. Культ Карго. Как это соотносится с практикой на конкретной позиции задумываются не очень сильно. А стоило бы. Ведь на сколько я знаю Гугл и сам на своей статистике признал, что хорошое прохождение алгосов не даёт в итоге хорошего инженера в работе. И задачки а-ля люки убрали.
То есть в очередной раз предлагается рассматривать программиста как рабочую единицу, задействованную в выпуске на прилавок алгоритмосодержащего продукта с заданными потребительскими свойствами. Ок. Мысль не нова, приводимые аргументы, аналогии и выводы далеки от того, чтобы претендовать на оригинальность.
Вот только почему-то общеинженерные методики и практики плохо приживаются в разработке ПО. Может всё-таки эта область несколько отличается, в связи с чем все подобного толка аналогии оказываются притянутыми за уши? И по странному стечению обстоятельств организации, практикующие серьёзное отношение к компетентности своих разработчиков в такой скучной и, безусловно, малопрактичной области знаний, как построение и анализ алгоритмов, вдолгую оказываются более преспособленными к изменениям стеков технологий. А руководители отделов, получив совсем немного опыта в подборе кадров, чуть ли не хором говорят, что наличие знаний алгоритмов должно входить в список обязательных требований к соискателю. Хотя бы потому, что за ними код по прошествии некоторого времени переписывать не придётся.
Но ваша точка зрения имеет право на жизнь.
Классическое "не больно-то и хотелось".
Был у меня замечательный пример работы в компании где собрались сплошные "инженеры-реализаторы", которые делом занимаются а не эти ваши сортировки пишут. Эти ребята даже свой язык и UI фреймворк с кросс-компиляцией под все возможные платформы запилили. И как водится сделали его функциональным, потому что это модно и если компилируется - то работает, мы тут не байты перекладываем а продукт делаем.
А потом оказалось что годами существует баг при котором таблица на 1000+ строк при клике на заголовок сортируется по 15 секунд. А сортировалась она так потому что сортировка была сделана мердж-сортом на списках, сами списки в языке были сделаны поверх массивов и concat работал за линию со всеми вытекающими.
Ни один инженер-реализатор за несколько лет не удосужился залезть в стдлиб и понять что происходит, они ведь были заняты действительно важными делами. А может кто-то даже залез, посмотрел сорцы но ничего такого не заметил, алгоритмы ведь не важны, как и нервы людей у которых UI по 15 секунд клик мыши отрабатывает.
Не так давно писал в соцсетях хейт‑пост по поводу «алгоритмических секций» при приёме на работу в Яндекс.
Не взяли и стало обидно, да? Трудно представить более классическую ситуацию чем эта.
А вы ведь ещё и новое поколение "инженеров реализаторов" обучаете, судя по инфе в профиле. Но это, в общем, даже радует - спрос на специалистов с нормальным багажом знаний будет только расти.
А потом оказалось что годами существует баг
Но ведь задокументированные баги принято чинить же?
А в этом вся мораль истории.
"Инженеры-реализаторы" которым алгоритмы не важны даже не подумают залезть исходники стдлибы, ведь она лишь инструмент который не подводит.
Реализаторам писавшим эту стдлибу тоже алгоритмы были не важны, а потому персистентность была обеспечена копированием, мы тут делом занимаемся а не деревья на вайтборде крутим.
Инженеры которым не важны алгоритмы зачастую принимают такие архитектурные решения что легче нанять студента-олимпиадника чем потом страдать от тормозов во всех конечных продуктах которых коснулась рука "реализатора".
Раз баг годами существовал и не был пофикшен, значит никого это не беспокоило, и в чем проблема тогда?
Не всегда нужно фиксить баг, который видит какой то 0.001% пользователей, особенно если профит от фикса не перекроит потери на реализацию.
На правах лирического отступления.
В JS есть тип данных BigInt. Кто интересовался методами быстрого умножения, слышал про алгоритмы Карацюбы, Тоома, FFT и пр. Угадайте, какой из них использует под капотом Хромиум? Правильный ответ — все, в зависимости от размера чисел. А ещё несколько быстрых алгоримов деления, форматирования чисел и т.д. А вот в Firefox реализация BigInt только базовая. Кому интересно, можете поэкспериментировать с бенчмарками и убедиться, что в FF идеально выходит O(n^2), а Хром намного быстрее. Ну и исходники можно посмотреть, там любопытно.
Ну и исходники можно посмотреть, там любопытно.
Вот, кому интересно.
Based on Golang? Ну и история введения очень позабавила, "revert, reland, revert^2", а так, конечно, интересно.
Почему эти «алгоритмические задачки» вообще так популярны на собеседованиях и почему руководство верит, что так они смогут отобрать хороших программистов — вопрос открытый.
На этот вопрос есть очень простой ответ - это очень упрощает задачу отбора. Натаскал задачек с того-же леткода, и просто ставь галки - решил//не решил. Думать не надо, любая мартышка справится с отсевом "плохих" программистов.
Потому что 99% программистов способны написать код для 99% ситуаций, а вот отбор по алгоритмическим задачам делают для того, чтобы быть уверенными, что когда настанет тот самый 1% ситуаций, где нужно будет не тупить, а решить что-то, возможно даже алгоритмически, потенциальный кандидат с этим справится. Как-то так
Я вам сейчас напишу, почему вы не правы.
Случай 1, 2012 год, мы писали софт для DB2, и там один из авторов пихал данные транзакций в вектор, делал по нему линейный поиск и удалял из середины. Пока код не наткнулся на транзакцию из миллиона записей. Автозамена на std::set проблему решила, но она бы не появилась, если бы была грамотность.
Еще случай, 2011 год, товарищ по цеху делал поиск в мапе итератором.
Еще недавний случай, товарищ фильтровал/копировал односвчзный список вставкой в конец другого односвязного списка (O(N^2) на ровном месте).
Еще случай оттуда же, товарищ сделал выдачу паркетного файла с сервера постранично, на каждый запрос страницы файл читался с начала...
Подмена понятий.
Алгоритмическое собеседование как в Яндекс\Гугл\ГдеТоЕще не нужно. Нет никаких доказательств что оно как-то влияет на продуктивность сотрудников и вообще как-то помогает.
А само знание алгоритмов очень нужно, помогает не писать говнокод. Алгоритмов которые надо знать и понимать не очень много: массивы, списки, сортировка, бинарный поиск, кучи, деревья, хэш-таблицы, "динамическое программирование". Обычно это изучается первые полгода на курсе программирования, а при самостоятельном изучении заботать за пару ндель можно.
У вас какие-то взаимоисключающие параграфы. По вашим словам, собеседование, которое проверяет знание алгоритмов не коррелирует с продуктивностью сотрудников, но при этом знание алгоритмов помогает не писать говнокод (а умение писать не говнокод очевидно на продуктивность влияет).
Алгоритмическое собеседование в Яндекс/Гугл - это лучший из возможных вариантов для них:
Во-первых, оно действительно коррелирует с производительностью, вы про это во втором параграфе написали. Плюс в Фаангах гораздо чаще возникают задачи с данными, где действительно эти алгоритмы надо применять. Я на интервью справшиваю то, что лично в прод коммитил.
Во-вторых, такие интервью можно стандартизировать, масштабировать и ввести объективные критерии. Когда у вас такая большая кампания - это важно. Никак не получится, например, "поговорить по душам" про прошлые проекты. Откалибровать интервьюверов невозможно. Плюс, вас завалят исками за дискриминацию (был знаминитый иск, где гугл обвинили в дискриминации по возрасту за вопрос о количестве бит в байте. Представляете что будет, если спрашивать про фреймворки какие-нибудь). Правда, это к россии не так сильно применимо.
В-третьих, такие интервью достаточно сложные. Когда у вас сотни кандидатов на место, вам нужно достаточно сложное интервью с большим диапозоном оценок, иначе у вас 80 кандидатов на место получат высший бал, и что с ними дальше делать?
В-четвертых, тут очень сложно считерить. Натаскаться объяснять чужой проект на гитхабе, как свой - на порядки проще, чем зазубрить все возможные задачи. Выучить стандартные фразы о плюсах и минусах фреймворка без малейшего понимания - тоже просто. Но если человек задачу решил, то он с гораздо большей вероятностью умеет в алгоритмы и способен идею оформить в виде кода.
Какие есть альтернативы вообще? Спрашивать фреймворки? Так в условном гугле своя кухня. Смотреть старые проекты? Как их оценивать? Как нанимать джунов? Как проверить, что это не состряпанный конторой "войти-в-айти" профиль? Условный срок? Идеальный почти по всем праметрам вариант, но физически невозможный из-за количества кандидатов, высоких зарплат и найма с релокацией даже из других стран. Тестовое задание? Их проверять на порядок сложнее. И читерить с ними проще.
Да, это не лучший вариант для условных ООО "Рога и Копыта". Если вы, например, позицию пол года закрыть не можете, вам нужен кодер только формочки клепать для ваших 10 юзеров, то бездумно копировать алгоритмические собеседования не стоит - это карго-культ.
Но для Фаангов - это лучший вариант.
У вас логическая ошибка в первом же предложении. Вы считаете что "алгоритмические собеседования как в гугле", которые по факту решение leetcode задач уровня medium-hard на время в стрессовой ситуации, как-то проверяют знание алгоритмов. Это не так, единственное что проверяют такие собеседования - сколько человек тренировался решать leetcode задачи на время. Это не знания, а навык, причем весьма специфический, практически не востребованный в коммерческой разработке.
Этот навык довольно слабо коррелирует с производительностью, так как высокая производительность в разработке ПО достигается тем, что люди не делают того, чего делать не надо. Не пишут сложный общий алгоритм, когда достаточно реализации частного случая, не делают навороченную архитектуру, когда достаточно написать все в одной функции, используют готовые библиотеки вместо написания своего кода в конце концов. Это все никак не связано с решением leetcode задач на время.
Более того, нет никаких исследований, что умение быстро решать leetcode задачи на время как-то коррелирует с производительностью. Я честно искал и не нашел.
Вы все правильно пишите, про преимущества таких собеседований, что сложно считерить, надо готовиться, обеспечивает однозначную оценку кандидата. Но проблема в другом - это собеседование не проверяет нужных навыков.
Если вы фаанг или хотя бы яндекс, то к вам могут стоять очереди хоямячков, готовых забесплатно поработать ради строчки в резюме. Но если у вас компания поменьше, то найти хотя бы 10 подходящих кандидатов по другим критериям, кроме знания алгоритмов будет уже проблемой.
Что касается задач, то как в фаангах, так и в рогах-и-копытах примерно одинаковое соотношения задач нетривиальной обработки данных и банальных перекладываний json. И вероятность что натренировавшись решать 100500 задач с литкода в секунду вы не будете заниматься скучной фигней - крайне мала.
Альтернативы всегда существуют.
Обычное собеседование с разбором кейсов: "как бы вы решили [такую] задачу". Желательно кейсы практические из встречающихся на практике. Тут и знания фрейморков, и алгоритмов, и умение фокусироваться на задаче итд
Чтение кода и поиск багов. Несмотря на банальность такая работа встречается в практической разработке гораздо чаще, чем реализация каких-то алгоритмов.
Тестовое задание, близкое к тому, чем придется заниматься, желательно с ограничением времени, которое сам кандидат назначит. Это идеальная проверка, но к сожалению многие кандидаты откажутся решать.
Эти варианты не взаимоисключающие, а взаимодополняющие. Если у вас поток кандидатов большой, а отобрать надо мало, то можно применить все три, а если поток маленький, то провести только обычное собеседование.
Это не так, единственное что проверяют такие собеседования - сколько человек тренировался решать leetcode задачи на время. Это не знания, а навык, причем весьма специфический, практически не востребованный в коммерческой разработке.
Не согласен. Натренироваться решать задачи без понимания сложностей и базы (простых) алгоримтов невозможно. Зазубрить ответы на тест по знанию языка или сильные и слабые стороны фреймворка можно. Зазубрить все задачи - невозможно.
Да, тренировка помогает справлятся с задачами более быстро. Ну это издержки огромного потока кандидатов. Если бы гугл спрашивал "Обычное собеседование с разбором кейсов", то там тоже быстро бы уровень вопросов и их количество сильно выросли бы, ведь им все-равно надо 90+% кандидатов отсекать. В итоге пришлось бы тоже тренироваться это интервью проходить, а форумы бы полнились гневными отзывами, что "мне не надо на работе быстро разбирать кейсы на доске - я, блин, код пишу!"
Потом, я уже много раз говорил, в ФААНГах довольно часто встречаются задачи, почти как с литкода. Я на интервью даю ту задачу, которую сам в прод коммитил. Мне приходилось писать и динамическое программирование и бинпоиски по ответу, и хитрые структуры данных с переплетенными стеками или очередями. Потом, вся разработка состоит из такого решения задач: вам надо что-то сделать, вы формулируете в голове решение и кодите его. Чаще это задачи уровня easy с литкода, но и medium достаточно часто появляются, что бы навык, помогающий проходить интервью, был достаточно релевантен.
Я пишу статью сейчас, а то мои комментарии итак слишком длинные получаются. Там я подробнее разберу почему альтернативы не работают.
Алгоритмы, алгоритмы, алгоритмы... А автор вообще на литкод когда-нибудь заходил? Подавляющее большинство зелененьких и львиная доля желтеньких задач вообще не требует знаний алгоритмов. Зачастую можно придумать свое решение, причем далеко не оптимальное, и оно пройдет. На алгоритмических секциях спрашивают как правило такое, чтобы понять, умеет ли человек банально программировать и хоть минимально думать (я надеюсь, вы не будете спорить, что любому программисту это нужно).
P.S. Как же меня коробит, когда кто-нибудь заявляет: "Зачем знать вот это и вот это?" Давайе червям уподобимся еще, у которых единственный скилл - рыть землю.
Не стоит дженерализировать.
Алгоритмическое мышление — это же не только Дийкстра, А* или динамическое программирование.
Это насмотренность, возможность подобрать правильный подход к решению стандартной задачи.
Например, исправить последовательность символов в "битом" потоке. Структуры данных, опять же. Можно ли обойтись битовым массивом или стоит с хэшмепом реализовать. Такие задачи встречаются достаточно часто на практике, если в твоей зоне ответственности что-то чуть более серьезное, чем непубличный API "для пацанов". Но даже в публичном API нужно, например, валидировать параметры по разным критериям. И для этого не всегда есть подходящие решения.
Дальше, про библиотеки, написанные "маэстро". Некоторые не получится использовать, не понимая специфику задачи. Например, KNN в рекомендательных системах ретейлера. Результат будет, но он будет мусорным, пока не разберешься, как работать с данными.
Собеседующий, если он не бревно, конечно, глядит на то, как человек мыслит, а не только на результат. Сразу видно, где есть пробелы, а куда нужно будет вкладывать дорогой образовательный ресурс. Рассказывать можно разное, на деле сразу видно — ну и делать скидку на стресс, конечно.
Резюмируя, алгоритмы — это способ реализации задачи эффективно и "понятным алгоритмическим языком". Как для водопроводчика понимание того, почему трубу не надо укладывать под таким углом.
В конце концов, можно докупить больше серверов или поставить немного больше памяти — и это будет гораздо более экономически оправданны решением, нежели тратить годы на разработку «оптимальнейшего» решения.
Или переложить эти расходы на конечного потребителя (смотрим ААА (и не только) гейм-дев).
В реальности же нужны совершенно другие компетенции.
Перечислять их тут нет смысла. В числе прочего, это умение писать понятный поддерживаемый код.
Почему нет смысла? Можно парочку для примера предложить, да чтоб их ещё и оценить можно было хоть сколько нибудь однозначно в течение часа. А что касается понятного и поддерживаемого кода, то это настолько субъективно может быть, что проще на кофейной гуще погадать.
Да, упарываться в алгоритмы нет смысла, если это не требуется, однако можно спросить пару-тройку, чтоб не пришлось покупать дополнительные сервера и прочее.
Нужен баланс на самом деле. Плохими разработчиками являются как чистые "олимпиадники", так вообще не имеющие представление о том, что такое алгоритмическая сложность. Если ты не знаешь, как в общих чертах каждый "кубик" работает внутри, то да, ты можешь делать простые конструкции из них. Но любая проблема, когда оказывается, что твоя конструкция работает плохо или как-то не так, ставит тебя в тупик. Поэтому для профессионального роста (= способность решать более сложные задачи) разработчику приходится разбираться, а как оно работает внутри. А там и алгоритмы неизбежно вылезают.
Что же касается алгоритмических секций - не знаю как сейчас, а год-полтора назад в том же яндексе на них, фактически, просили из "кубиков" стандартных библиотек собрать решение алгоритмической задачи. Ни сортировок, ни хеш-таблиц, ни уж тем более чего-то более сложного "с нуля" там писать не просили. Фактически проверяется наличие у кандидата "алгоритмического" мышления и умения из кубиков собирать более сложные алгоритмы.
Скорее навыки написания алгоритмов ставят не столько на первый план, сколько на первые этапы/секции)) Да, возможно, все эти алгозадачи не будут использоваться на работе в явном виде. Но в фаанги, в которые огромная конкуренция данный этап отсева кандидатов все-таки имеет смысл и унифицирует процесс найма. Как минимум алгосекция отсеивает кандидатов, незамотивированных разобраться в алгоритмических задачках и в базовых вещах из computer science (все-таки некоторые паттерны мышления оттуда мы используем в разработке неосознанно). Она является лакмусовой бумажкой, уравнивает всех и позволяет более объективно сравнить кандидатов по общим принципам на первых этапах.
В фаангах используется множество технологий в разных сервисах и командах, сразу проведение интервью по каждой технологии для огромной кучи кандидатов банально не оптимально с точки зрения времени/ресурсов/денег. В идеале алгосекции должны давать возможность оценить навыки декомпозиции задачи, коммуникацию, умение превращать мысли в код, стиль кода, умение оценивать время и тд, пускай и в контексте микрозадач. Но ведь это как раз те навыки, которые будут нужны и в реальной разработке. Ну, а о технологиях уже можно будет поговорить на собесе с командами, если до этого добраться.)))
Слишком много воды в посте. Аналогии избыточны. Если коротко, то Яндекс ищет спортивных программистов потому что ему важна скорость выкатки решения для конечного пользователя. А Ядро ищет хороших инженеров, так как ему важнее архитектура и вакатка на рынок занимает гораздо больше времени, да и задачи более фундаментальные. Короче Яндекс это хипстер, а Ядро это Линукс Торвальдс
Подписываюсь под каждым словом автора. У меня был похожий разговор на групповом собеседовании (бегите, если видите неиндивидуальный подход) 1С-Рарус. Это было обучение программированию на 1С после полутора месяца отборочных испытаний. У меня уже был уровень джуна. Я сказал, что ценю правильный подбор решений, а не изобретение очередного велосипеда а-ля ускорьте сортировку как в олимпиадах по программированию. Мне весьма скоро отказали, так как "мы не сходимся в ценностях". Не хочу никого обидеть, но вот уверен, что девку с фиолетовыми волосами и грязными вещами взяли.
Я очень рад, так как сейчас работаю в международной компании, в которой важна практическая, а не теоретическая польза. А так мне пришлось бы получать 12000 рублей в месяц и увеличивать зарплату на столько же за сдачу очередных искусственных экзаменов по 1С.
В чем то вы правы, но все таки алгоритмические кружки далеко не бесполезны, решение логических задач вообще прокачивает мозг, и позволяет и в прикладных ситуациях лучше мыслить. Но да, простая зубрёжка алгоритмов - почти бесполезна
Ваш "технологический" программист и есть математик. Программирование на таком уровне является разделом математики. Все ваши понятия - алгоритм, рекурсия, линейное программирование, класс, стратегия, транспорная задача - пришли из разделов математики на стыли с лингвистикой ("как это записать правильнее?")
Когда-то давным-давно, в начале 2000х, когда по земле бродили мамонты вроде меня, было две популярные реализации STL для C++ (и куча форков, конечно). В одной из них сложность list::size() была O(1), а в другой O(n).
И каждый раз, когда программист, не понимающий про сложность алгоритмов, писал перебор элементов списка с их нумерацией, жизнь показывала, зачем знать про сложность алгоритмов. Иногда не сразу, а когда список разрастался с десяти элементов до тысячи.
Полностью согласен с автором и ещё добавил бы вот что. Навыки айти специалист обычно делятся на хард и софт. Так вот, я бы сказал, что навык написания алгоритмов - это супермалая часть хард скиллов (меньше 5%). В итоге получается ужасный дисбаланс, когда Яндекс набирает людей, которые великолепно могут выполнить меньше 5% обычной работы программиста. А на остальные 95+% просто забивают.
Это ненормальная ситуация и существует она только лишь потому что сфера айти невероятно быстро росла. Уверен, что в будущем ситуация изменится в лучшую (адекватную) сторону.
Сколько же можно жаловаться на алгоритмические собеседования? Создайте свою успешную кампанию и нанимайте кого хотите, хоть "программистов" не знающих даже школьную математику.
Это частный бизнес, владелец нанимает кого хочет. Если он это делает плохо - в здоровой экономике он разориться. Но как видим, тенденция на такие собеседования не исчезает, наоборот они стали стандартом местами.
Я скорее согласен с автором.
Мое любимое, это когда инженеры отбираются на собеседованиях с помощью алгоритмов. А потом бизнес удивляется почему они при проработке задач обсуждают O(n), не уделяют должного внимания всяким «customer journey», а через время и вовсе уходят из компании, потому что им стало скучно.
Алгоритмы не важны