Алгоритмы не важны / forpes.ru

Главная
Алгоритмы не важны

Алгоритмы не важны +69

17.11.2023 13:20

despair 305 32000 Источник

Прошу простить заранее за несколько кликбейтный заголовок )

Не так давно писал в соцсетях хейт‑пост по поводу «алгоритмических секций» при приёме на работу в Яндекс.

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

И ставят данной компетенции очень высокий приоритет при приёме на работу.

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

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

Буду использовать простой язык без заумных терминов и объяснять «на пальцах», чтобы было понятно.

Так вот, глобально всех инженеров (а также вообще всех высококвалифицированных технических специалистов) можно разделить на две больших категории:

Те, кто создают технологии или технологически‑сложные узлы / агрегаты. Например, инженеры, создающие новые двигатели внутреннего сгорания, реактивные двигатели, ракетные двигатели. В нашем примере с водоснабжением пусть это будут инженеры, создающие новые насосы для воды. Назовём их — технологические инженеры.
Те, кто с помощью уже имеющихся технологий или узлов / агрегатов создают конкретное решение или продукт для конечного потребителя или продукт на широкий круг потребителей. В нашем примере про водоснабжение — это инженеры, которые создадут (и реализуют) проект по водоснабжению / отоплению конкретного загородного дома. Назовём их — инженеры, создающие решения.

Так вот, число первых, то есть «технологических» инженеров — сильно меньше, чем вторых. Их квалификация на порядок выше, чем вторых, и необходимость в них на несколько порядков меньше, чем вторых. По понятным причинам — создавать технически‑сложные элементы «конструктора» сложнее, чем строить потом из конструктора конкретные решения. Да основных моделей водяных насосов, которые нужны в частных домах — может быть сотни, а самих домов, в которых надо обустраивать водоснабжение — сотни миллионов.

Так вот, квалификация первых, «технологических» инженеров должна быть сильно выше.

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

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

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

За него уже подумали заранее другие квалифицированные инженеры и предоставили подробные спецификации того, какие узлы и агрегаты (трубы, краны, задвижки, автоматику, насосы и т. п.) можно и нужно использовать в тех или иных ситуациях.

Ему нужно исходя из конкретной ситуации и запросов клиента понять: сколько нужно труб и каких, чтобы всё развести куда нужно: чтобы хватило давления / объёма воды, при этом чтобы иметь некий запас надёжности / прочности / толщины труб, но при этом не переплачивать за заведомо избыточные характеристики, сколько нужно кранов и каких, где какая нужна автоматика, какие требования нужно соблюсти по каким‑то нормам / ГОСТам / стандартам и т. п.

Наш «инженер‑реализатор» определённо должен обладать немалой квалификацией, чтобы учесть все эти вводные и предложить оптимальное / сбалансированное решение, которое решает задачу, при этом надёжно, при этом отвечает нормам безопасности, и чтобы при этом не переплачивать за ненужное.

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

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

Если бы он проектировал новую модель насоса (был бы «технологическим» инженером) — ему было бы это однозначно нужно.

Даже если ты инженер‑проектировщик какого‑нибудь специализированного электрического грузового автомобиля для конкретного заказчика в некоем прекрасном будущем, когда на рынке готовых компонентов уже представлена широкая номенклатура узлов — есть уже готовые всевозможные электромоторы и аккумуляторы «на любой вкус и цвет» — тебе не нужно разбираться в нюансах органической или неорганической химии — ты просто берёшь уже готовые аккумуляторные ячейки, которые тебе подходят, и просто их используешь в своём электромобиле. В каком‑то смысле, проектирование превращается в рутину — тебе просто нужно знать основы / принципы проектирования конкретных видов продуктов, грамотно подобрать компоненты, которые подойдут по характеристикам, соединить всё вместе, покрасить в нужный цвет, и вуаля — автомобиль поехал.

Теперь вернёмся к программированию...

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

Есть «технологи», создающие новые движки / технологии / технически‑сложные библиотеки / инструменты.

Например, те, кто создают новые СУБД (которые быстрее / эффективнее конкурентов), новые поисковые движки, движки для работы с нейросетями, языки программирования и т. п. Им, определённо, нужны хорошие знания алгоритмов, чтобы создавать высоко‑конкурентные «узлы» и «детали».

Если твоя СУБД или твой движок нейросетей недостаточно быстрые или потребляют слишком много памяти в сравнении с конкурентами — другие инженеры / программисты просто не будут их использовать. Конкуренция тут достаточно жёсткая и требования очень высокие и жёсткие.

Однако, примерно 98% программистов — не создают технологии или движки. Они создают продукты или конкретные решения под конкретных заказчиков. Их задача — взять адекватный набор из уже готовых технологий / движков / библиотек и сделать конкретное решение.

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

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

Если какой‑нибудь условный интернет‑магазин, написанный под конкретного заказчика, будет в полтора раза медленнее (или потреблять в полтора раза больше памяти) от теоретически/технологически‑достижимого предела — этого никто не заметит.

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

Однако, чаще всего для обеспечения этих характеристик куда важнее правильно подобрать стек технологий и «правильно» спроектировать само решение из конструктора кубиков‑технологий, нежели пресловутое умение «оптимизировать пузырьковую сортировку» и производить те или иные «операции над списками за один проход».
Подобрать «правильную» СУБД и «правильный» фреймворк и использовать его правильным образом — куда важнее и вносит существенно бОльший вклад в производительность решения, чем оптимизация алгоритмов на микро-уровне.

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

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

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

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

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

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

Во этой ситуации ставить главным / основным критерием при приёме на работу для обычных (в том смысле, что принадлежащим к тем самым 98% разработчиков, которые делают РЕШЕНИЯ, а не ТЕХНОЛОГИИ) программистов — это, считаю, большая ошибка.

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

PS: Равно как я очень скептически отношусь ко всякому «спортивному программированию», где на скорость люди решают какие‑то полуматематические задачи — поскольку это совсем не те навыки, которые нужны программистам в реальной жизни и в реальной работе. Это какая‑то «параллельная вселенная».

Это как «танец с саблями» имеет отдалённое отношение к реальному бою на саблях.
Люди, которые хотят устроится в компании с подобными требованиями, специально прокачивают свои «алгоритмические» скилы на всяких leetcode.com.

А потом, после похождения собеседований, успешно их забывают.

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

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

(К тому же, вообще этим должны заниматься скорее математики, а не инженеры...)

Комментарии (305)

aamonster
17.11.2023 13:44
#26169342
+56
Штука в том, что ваш "инженер-реализатор" может в силу непонимания каких-то базовых вещей всадить совершенно нелепую ошибку, которая будет создавать неудобства, но видна не будет. А потом придётся искать и чинить, а то и обходить костылями.

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

Но да, толковый прораб, следящий за ними, может выправить ситуацию.
1. n43jl
  17.11.2023 13:44
  #26169412
  +63
  Гипотетически, это гадание на кофейной гуще. Олимпиадник-Алгоритмист в силу знания что и какими алгоритмами можно заранее оптимизировать, может понаписать и переусложнить код так, что потом его проще будет выкинуть и полностью переписать, чем поддерживать.
  
  Алгоритмические собеседования - это просто калька с гугла, и стало относительно стандартом в Фаангах и Американском энтерпрайзе.
  1. aamonster
    17.11.2023 13:44
    #26169416
    +11
    Ну да, нет резона совсем уж упарываться по алгоритмам. Но уложившиеся в голове знания на уровне "а почему СНиП требует, чтобы труба шла под уклоном" – необходимость.
    
    haqreu
    17.11.2023 13:44
    #26171724
    +9
    И не просто под уклоном, а под каким именно уклоном. Пример: стандарт уклона в ПВХ канализации - 3%. Что класть 0% нехорошо - это довольно очевидно. А хорошо ли 9%?
  1. vkni
    17.11.2023 13:44
    #26169832
    +10
    Нет, речь о том, что инженеру Васе даётся 100 задач обычных, на перекладывание JSON'ов, а 101 случайно попалась такая, что нужно знать про O(n). Без понимания алгоритмов, он накосячит и даже не будет догадываться об этом.
    
    А задачи стандартизовать до конца нельзя — он же не рабочий на конвейере.
    
    gatoazul
    17.11.2023 13:44
    #26170378
    +16
    Если Вася накосячит и это никто не заметит (например, в виде слишком большой нагрузки), то значит оно и не нужно. А если заметит, то укажет Васе на проблему.
    
    wataru
    17.11.2023 13:44
    #26170416
    +3
    Не факт, что это будет заметно сразу. Скорее всего производительность просто будет потихоньку снижатся, пока пользователи не начнут ругаться и уходить к конкурентам. А потом пойди найди, какой же Вася и где накосячил - потому что если в компании нет алгоритмических интервью, то торомзить с большой вероятностью будет примерно все.
    
    mvv-rus
    17.11.2023 13:44
    #26170618
    +2
    Люди с опытом коммерческой мне тут недавно объясняли, в ответ на вопрос, почему нельзя обойтись без опыта коммерческой разработки, что надо опыт коммерческой разработки учит просто так, шоб було, обязательно вставлять в код отдачу метрик на мониторинг и настороить пороги (и всё это приходит только с опытом), а мониторинг там уж поднимет тревогу задолго до прихода северного пушного зверька.
    
    И я их так понял, что при наличии коммерческого опыта можно на практике алгоритмы и не знать.
    
    BugM
    17.11.2023 13:44
    #26170648
    Это был я кажется. И не надо перевирать меня.
    
    Алгоритм вы же напишите? Вот чуть ниже неплохой пример того что надо написать за полчасика на собеседовании. Я напишу, если что. И на собеседовании на позицию выше джуна спрошу и то и другое. На джуна только алгоритма даже попроще чем там хватит, не вопрос. А вот на мидла надо и написать что-то такое и поболтать про отвлеченные темы вроде мониторинга.
    
    mvv-rus
    17.11.2023 13:44
    #26170832
    Это был я кажется.
    
    И вы тоже, но ЕМНИП - не один. И я скорее утрирую, чем перевираю. Впрочем, если хотите, можете высказать свое мнение по поводу того же по смыслу, но более корректно сформулированного утверждения: "в коде, написанном опытным разработчиком, наличие участков излишней сложности, по сравнению с оптимальной, скорее всего, не приведет к фатальным последствиям, потому что опыт подскажет такому разработчику по-любому заблаговременно позаботиться о наблюдаемости своего кода и ведении его мониторинга". То есть, что цель избежать кризиса можно достичь другими средствами помимо знания всеми и каждым разработчиком деталей (таких, как асимптотик) алгоритмов.
    
    Алгоритм вы же напишите?
    
    Лично я - совершенно нестандартный случай, сильно не похожий на массовго соискателя, поэтому не хочу заострять внимание на своей персоне. Предпочитаю рассматривать сценарии вне зависимости от личностей, личность же я считаю важным учитывать, разве что, только в плане наличия у нее достаточных оснований для своих высказываний.
    Но если вам так интересно лично про меня (непонятно, правда зачем) - то за полчаса напишу (впрочем, это из моего комментария к тому посту, наверное, понятно), но проверить это экспериментально уже не получится.
    
    По поводу того алгоритма, точнее, задачи, я уже высказался в том самом своем более раннем комментарии: что это, скорее - задача на готовность к проверке и обработке граничных условий, т.е. - скорее, таки на опыт: сам алгоритм переворачивания цифр тривиален, особенно - в варианте "по тупому"(что это означает - см. тот комментарий). Если вы считаете, что такие задачи, с подводными какмнями, надо справшивать на мидла, то тут я ничего не скажу - за полным незнанием ваших требований.
    
    PS Если вы хотите узнать, писал ли лично я квадраты - таки писал (и ЕМНИП, тоже где-то в каментах про это отвечал). Хотя и с полным пониманием, что это квадрат, и почему ему там место. И лет пять тот код таки прожил по итогу, впрочем, там был далеко не хайлоад и даже не близко.
    
    BugM
    17.11.2023 13:44
    #26170842
    Случай из реальной жизни:
    
    Вот на то чтобы поймать вот такое в реальном продакшен коде я потратил больше недели. Потом исправил меньше за день вместе с выкаткой релизов, лол. Мониторинги звенели, все как полагается. Но толку, если починить не выходит? Поставить заплатку которую надо все время поддерживать получилось, пользователи ничего не заметили. Идея заплатки понятна. Была сильно ограничена пачка читаемых данных, которые потом уходили в большой хороший батч процессинг. И сверху это все было залито железом чтобы работало в неоптимальных условиях под большой нагрузкой.
    
    Мониторинги отработали как надо? Да. Они четко показали проблему производительности влияющую на пользователей. Помогли ли они ее решить? Нет, но это и не их задача. Защитили мониторинги продакшен от факапа? Да, они показали что есть проблема и дали время на поиск и внедрение обходного варианта чтобы пользователи не страдали.
    
    Лично я - совершенно нестандартный случай, сильно не похожий на массовго соискателя, поэтому не хочу заострять внимание на своей персоне
    
    Это так не работает. Мы все особые случаи. У нас у всех особый опыт. Нет коробки с дефолтными мидлами или тем более дефолтными сеньорами. Чтобы у них были дефолтные навыки и дефолтный опыт.
    
    Но если вам так интересно лично про меня (непонятно, правда зачем) - то за полчаса напишу
    
    Лайк. Это лично для меня критерий что с человеком можно говорить о разработке софта.
    
    Если вы считаете, что такие задачи, с подводными какмнями, надо справшивать на мидла, то тут я ничего не скажу - за полным незнанием ваших требований.
    
    Надо. Потому что большая часть пришедших "мидлов по резюме" это не напишет. Их надо отфильтровать. Если бы каждый мидл такое мог написать, то и спрашивать бы не стоило. Но увы.
    
    Если вы хотите узнать, писал ли лично я квадраты - таки писал (и ЕМНИП, тоже где-то в каментах про это отвечал). Хотя и с полным пониманием, что это квадрат, и почему ему там место. И лет пять тот код таки прожил по итогу, впрочем, там был далеко не хайлоад и даже не близко.
    
    Это нормально. Если понимаешь что и зачем пишешь, то можно писать все. В этом нет проблем.
    
    У меня в проде тоже есть квадраты. Они там обоснованны. И перед ними стоит ассерт на количество пришедших данных. Лучше упасть сразу, а не тормозить вечность.
    
    mvv-rus
    17.11.2023 13:44
    #26170916
    +1
    Мониторинги звенели, все как полагается. Но толку, если починить не выходит? Поставить заплатку которую надо все время поддерживать получилось, пользователи ничего не заметили. Идея заплатки понятна. Была сильно ограничена пачка читаемых данных, которые потом уходили в большой хороший батч процессинг.
    
    Мои мысли по поводу. Сначала - в рамках сценария: собственно, от нынешнего мидл-разработчика с коммерчеким опытом требуется локализовать проблему - что она в либе. И 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) и попробуйте все вышенаписанное туда упаковать. Получилось?
    
    Ну, а к остальному мне добавить нечего.
    
    mvv-rus
    17.11.2023 13:44
    #26170966
    +1
    ,
    
    Забыл про свой особый случай добавить
    
    что за последние годы освоил современный C# и фреймворк ASP.NET Core в качестве основного инструмента - и это отражено в на моём гитхабе и в статьях на Хабре - и современный JS (вообще-то я с JS работал как админ лет пятнадцать-ldflwfnm назад - был тогда такой WIndows Scripting Ноst для работы с COM Automation, через который в системе было доступно немало, но тогда JS был другим) в качестве дополнительного - это не отражено нигде, однако имеющееся знание JS позволило бы мне, к примеру, если бы описанная ваша проблема с removeAll была бы на JS, поправить ее - там это очень просто, достаточно в условном HashSet.prototype исправить свойство по имени removeAll, и вообще, насколько я понял, такие трюки в JS являются типовыми, так что что про них стоило бы знать даже джуну).
    
    Но это, конечно, ни разу не опыт коммерческой разработки.
    
    BugM
    17.11.2023 13:44
    #26172070
    +2
    Я не об этом. Исправить такую проблему c .removeAll это однострочник. Пишется за минуты. Найти где еще он нужен это тоже минуты. Простой поиск по коду покажет все места.
    
    Настоящая проблема в том чтобы понять что квадрат и тормоза возникают именно в removeAll. Метод всем своим видом показывает что он не квадратичный. Бизнес логика развесистая, кода в ней много разного. Профайлер показывает какую-то чушь. Вызовов всяких в том числе и removeAll много, на флеймграфе ничего не понято. Вот неделя плюс и ушла чтобы понять что надо просто вызов removeAll поменять.
    
    mvv-rus
    17.11.2023 13:44
    #26172672
    +1
    Про устранение я написал потому что не совсем понял, в чем там сложность: думал, что такие вызовы по всему коду раскиданы и и править их по одному в каждом месте обуродуешься.
    
    Изолировать такую ошибку - тут таки да, нужен опыт, "коммерческой разработки" или ещё какой: люди без опыта стандартным библиотекам языка доверяют слепо (сам такой был).
    
    Nalivai
    17.11.2023 13:44
    #26172010
    Нет коробки с дефолтными мидлами или тем более дефолтными сеньорами. Чтобы у них были дефолтные навыки и дефолтный опыт.
    
    Но тестируем мы их стандартными задачами и стандартными вопросами, смог решить стандартную задачу - лайк, хороший. Не смог - не лайк, плохой.
    
    aamonster
    17.11.2023 13:44
    #26170704
    +3
    Я так понимаю, если привык на каждый чих метрики ставить и их отслеживать – алгоритмы будешь знать уже через несколько месяцев, причём не просто заученные из книги, а с пониманием, зачем они нужны.
    
    wataru
    17.11.2023 13:44
    #26171468
    +1
    а мониторинг там уж поднимет тревогу задолго до прихода северного пушного зверька
    
    Ну вот у вас каждую неделю на 1% процент что-то ухудшается. Ну это в принципе, нормально, ведь новые фичи в код добавляются. А потом эти 1% складываются в пушного зверька.
    
    mvv-rus
    17.11.2023 13:44
    #26172682
    Дык, у мониторинга, в отличе от лягушки, пороги не адаптивные. Доползло до 70% CPU - он честно предупреждение напишет, до 90% - ошибку. А там уж дело разработчиков, сделать ли "обходное решение" (так в ITSM костыль называют) струтурное ли (т.е. найти и убрать багу) или перепасовать (последнее практикуется в "Реальном ITSM").
    
    Но мониторинг по-любому свое дело сделает: прокукарекает, и приход песца неожиданностью уж всяко не будет.
    
    vkni
    17.11.2023 13:44
    #26170454
    +7
    Если Вася накосячит и это никто не заметит (например, в виде слишком большой нагрузки), то значит оно и не нужно. А если заметит, то укажет Васе на проблему.
    
    Опять, представьте, что у вас нагрузка неравномерна. Если у вас алгоритм с O(n^3), он будет нормально справляться с «обычной» нагрузкой, а когда придёт всего в 10 раз больше, он встанет колом. И как всегда это будет вечером в субботу.
    
    aamonster
    17.11.2023 13:44
    #26170542
    +3
    Да, я говорил именно про подобные случаи.
    
    И тут не надо каких-то топовых разрабов. Нужно, чтобы у людей базовые знания алгоритмов были отработаны до автоматизма, чтобы они не всаживали O(n²) на ровном месте.
    
    vkni
    17.11.2023 13:44
    #26170728
    +3
    Но не надо беспокоиться про топовых разработчиков, создающих алгоритмы. У них тоже есть определённая зона, в которой они должны «шарить», но применяют редко. Например, ряды и производящие функции.
    
    aamonster
    17.11.2023 13:44
    #26170740
    +3
    О топовых вообще беспокоиться не надо, они сами справятся. У них другие проблемы – ну там, не уехать жить в дурдом и тому подобное.
    
    imanushin
    17.11.2023 13:44
    #26171814
    +6
    Если Вася накосячит и это никто не заметит <...> то значит оно и не нужно.
    
    Такое будет только в идеальном мире, с моей точки зрения.
    
    Я вот замечал такую последовательность событий:
    
    Разработчики пишут сложную систему. В ряде случаев они спрямляют углы, плюс тестировщики смотрят только на частные случаи (они же не могут перебрать все, правда?).
    
    Параллельно с этим, систему продают по B2B каналам. Другими словами - продавцы показывают всё управленцам, а не конечным пользователям.
    
    Систему успешно внедряют, и она начинает работать. Показатели поначалу красивые, конечно.
    
    На протяжении времени оказывается, что система работает медленно и неэффективно. Пользователи жалуются. Лет через пять некоторые из них даже становятся управленцами, а потому уже начинают иметь реальную власть, чтобы давить на переход на что-то иное.
    
    Параллельно с этим, служба поддержки терпеливо отвечает клиентам, что Ctrl-V не работает в их html формах, что плашка "загрузка" может действительно висеть минуту, ибо мы же не гугл какой-то, правда? Ну и некоторые отчеты сделать нельзя, и это было на странице 78 контракта.
    
    Из-за пункта 4, клиенты начинают постепенно уходить к конкурентам и систему отправляют в утиль.
    
    то укажет Васе на проблему.
    
    К этому моменту, эффективный ~~менеджер~~ Вася, скорее всего, уже работает в другой компании, так как среднее время работы на одну фирму явно меньше пяти лет. А если нет, то мало кто будет увязывать низкую производительность с уходом клиентов.
    
    mvv-rus
    17.11.2023 13:44
    #26172702
    Параллельно с этим, систему продают по B2B каналам. Другими словами - продавцы показывают всё управленцам, а не конечным пользователям.
    
    И вот тут вот у хорошего CIO (он же - директор по информационным технологиям, он же - ещё кто нибудь, тут важно не название должности, а роль) в дело вступают эксплуатационщики, задача которых - допросить пресейлов (не сейлзов - с тех толку мало) с пристратием, выяснить нелицеприятные детали и подготовить снятие лапши с ушей ЛПР, если сейлзам ее туда удалось повесить (снимать лапшу - это уже работа CIO, экспоуатационщикам это не по чину). Мне лично в бытность главадмином по инфраструктуре приходилось этим заниматься, и не один раз: да CIO у нас был хороший. Но не всем так везет с CIO, да.
    
    imanushin
    17.11.2023 13:44
    #26172728
    И вот тут вот у хорошего CIO <...> в дело вступают эксплуатационщики
    
    И как они код проверят? Они легко поймут, что react компонент на N элементов получает N уведомлений о новом объекте при старте программы, а потому сваливается в O(N^2)? Или они будут просто квадратики на презентации смотреть? Как они это выяснять будут?
    
    Как будут понимать, что компонент не оптимизирован под следующую версию Java (которая будет через год), даже зная, что безопасники потребуют её обновить?
    
    Мне лично в бытность главадмином по инфраструктуре приходилось этим заниматься
    
    Да, от части проблем получится уйти, если работать добросовестно. Вот только понять, что система будет работать неэффективно после года работы (ибо накопится условная история) - сложно. В презентациях код показывать не будет, да и админ вряд ли будет его смотреть и анализировать. А далее условная форма будет тормозить по 5-10 секунд на каждом поле, что приведет к тому, что люди будут ворчать. И, конечно же, сисадмин не заметит проблемы, ибо ему не надо вбивать эти документы постоянно. Более того, сисадмину опасно замечать проблемы в процессе эксплуатации, так как он же и подписался под этим решением.
    
    Но я соглашусь, что определенную долю проблем можно попытаться отсечь заранее. Именно потому крупные фирмы (те же банки) лет 20 лет назад стали уходить от outsource решений и стали готовить свои команды.
    
    mvv-rus
    17.11.2023 13:44
    #26172802
    И как они код проверят?
    
    По крайней мере, они зададут нужные вопросы, даже если не знают как работает код - shit, который happens при наличии опыта, даже чисто в экспоуатаци, просматривается. Вопросы, конечно, будут не про код, а типа: "для какого количества пользователей вы тестировали?" (а лучше - "внедряли").
    
    Ну, а лично мне было легче тем, что я из программирования пришел и лет за несколько успел и на чужие ошибки насмотреться, и, тем более - на свои: в те времена основное по времени занятие программиста уровнем хоть чуть выше формошлепа на Delphi было искать свои ошибки (не знаю, как там сейчас, когда сплошь фрейворки да Q&A, да умение быстро печатать, по некоторым слухам, может быть в списке требований).
    
    DarthVictor
    17.11.2023 13:44
    #26170572
    +6
    В реальности на 1 задачу на ассимптотическую сложность будет 10 задач на проверку данных пользователя, от обычных проверок на незаполненое поле до всевозможных SQL-инъекций и XSS. Но по опыту это почему-то спрашивают сильно реже.
    
    vkni
    17.11.2023 13:44
    #26170734
    +1
    Да, рутины, увы, больше. Но это везде.
    
    Tsimur_S
    17.11.2023 13:44
    #26173028
    Нет, речь о том, что инженеру Васе даётся 100 задач обычных, на перекладывание JSON'ов, а 101 случайно попалась такая, что нужно знать про O(n).
    
    Совсем даже не обязательно она будет необычной, можно поймать такое и во время перекладывания json.
    
    https://habr.com/ru/articles/544764/
  1. wataru
    17.11.2023 13:44
    #26169876
    +5
    Олимпиадник-Алгоритмист в силу знания что и какими алгоритмами можно заранее оптимизировать, может понаписать и переусложнить код так, что потом его проще будет выкинуть
    
    Эта проблема решена обязательным код-ревью. В том же гугле любой код обязательно проходит ревью коллегами. И если ревьюверу непонятно, или он считает, что можно написать проще, он об этом скажет и олимпиаднику придется все переписывать самому сразу. А если в компании все такие Олимпиадники-Алгоритмисты и "непонятный и зарнее оптимизированный код" друг друга они итак понимают, то никакой проблемы тут нет.
    
    Этим же механизмом лечится единственная, на мой взгляд объективная проблема олимпиадников - плохо читаемый олимпиадный код. Уже через 2 недели новый работник сам пишет хороший, понятный код даже без пинков от коллеги.
    
    SpiderEkb
    17.11.2023 13:44
    #26169894
    +5
    У нас после ревью еще будет нагрузочное тестирование на копии промсреды. И оно покажет то, чего на тестовых серверах просто не увидишь (там данных кот наплакал - сотня-другая тысяч записей, ну полмиллиона, а на проме 50 миллионов только по клиентам, а по счетма и клиентским данным - там уже сотни миллионов записей).
    
    И на НТ выдадут по самые помидоры - тут скуль неоптимален (и вообще ту же информацию можно по другой таблице получить, она не такая тяжелая), тут лишнее переоткрытие файлов, тут каждый раз создается временный объект (а это тоже время). Могут даже предъявить за излишнее использование динамической памяти - почему тут 100500 выделяется-освобождается куча мелких кусков постоянно...
    
    wataru
    17.11.2023 13:44
    #26169926
    Я в другой ветке про это тоже написал. В гугле тоже почти все тоже покрыто performance тестами и если что-то где-то ухудшается, это чинят. В каких-то проектах часть presubmit проверки меряет, например, размер исполняемого файла и это ревьюверам выдается.
    
    imanushin
    17.11.2023 13:44
    #26171846
    И оно покажет то, чего на тестовых серверах просто не увидишь
    
    Всё верно - разработчики тестируют на одном подмножестве сценариев, а вы - на другом. И остается надежда на то, что пользовательский сценарий через месяц будет такой же, как и Вы предсказывали.
    
    VADemon
    17.11.2023 13:44
    #26172154
    +1
    Двойное бинго:
    
    код-ревью. В том же гугле любой код обязательно проходит ревью коллегами. И если ревьюверу непонятно, или он считает, что можно написать проще, он об этом скажет и олимпиаднику
    
    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)
    
    Отсюда: https://dave.cheney.net/high-performance-json.html
    
    wataru
    17.11.2023 13:44
    #26172188
    По вашей ссылке на "garbage factory" нет доступа. Пока понял, что какой-то элемент дизайна стандартной(?) библиотеки в языке go кому-то не нравится и, хоть его и очень удобно использовать, это не самый оптимальный способ что-то там сделать.
    
    Насколько там был непонятный код, или насколько его лучше можно было написать из статьи непонятно. Может, народ там взвесил плюсы и минусы и решил, что удобство использования тут важнее.
    
    Более того, чтобы исправить проблему тут автор изменил АПИ этой библиотеки. Т.е. там не код был кривой и неоптимальный, а дизайн интерфейса наложил ограничения. А вот дизайн интерфейса в стандартной библиотеке, насколько я могу предполагать, утверждался наверно аж целой комиссией. Т.е. это не к программисту вопрос, а к комитету языка.
    
    VADemon
    17.11.2023 13:44
    #26172246
    +1
    Гугл чтоли РФ 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, но выжать все соки -- только поломав интерфейс.
    
    BugM
    17.11.2023 13:44
    #26172294
    Удобное АПИ часто важнее скорости работы.
    
    Для очень многих задач есть библиотеки поудобнее или побыстрее. Когда к себе тащишь выбираешь что нужнее. Это нормально.
    
    Что как делать в стандартной библиотеке языка вопрос для комитетов. Все сразу может и не получиться и нужен какой-то компромисс.
    
    wataru
    17.11.2023 13:44
    #26172304
    Гугл чтоли РФ IP забанил?.. А так в целом все верно.
    
    Нет, но мой впн был забанен. Без него все открывается. Там именно то, что я и предполагал. Контраргумент к "фабрике мусора" - более понятное и простое API тут важнее.
    
    Соптимизировать автор смог и с сохранением API, но выжать все соки -- только поломав интерфейс.
    
    Автор сам пишет, что оптимизация в основном засчет избавление от выделений памяти, которые он там пол статьи объясняет - и что они неизбежны при таком интерфейсе.
    
    VADemon
    17.11.2023 13:44
    #26172316
    И я об этом же:
    
    Because allocations make up a large proportion of the Decoder.Token API, pkg/json.Decoder provides an alternative API that produces significantly fewer allocations and is 8-10x faster.
    
    Читать как "в добавок к"
  1. nameless323
    17.11.2023 13:44
    #26170994
    +2
    Олимпиадник-Алгоритмист в силу знания что и какими алгоритмами можно заранее оптимизировать, может понаписать и переусложнить код так, что потом его проще будет выкинуть и полностью переписать, чем поддерживать.
    
    А откуда противопоставление олимпиадников и прикладных программистов? Получается что если человек понимает алгоритмы, то он автоматически не может разобраться в новом фреймворке и архитектуре?
    
    Алгоритмические собеседования - это просто калька с гугла, и стало относительно стандартом в Фаангах и Американском энтерпрайзе.
    
    В фаанге алгоритмика от силы 10% времени занимает, там проверяют и опыт/тех скилы и алгоритмику, а не что-то одно.
    
    MiraclePtr
    17.11.2023 13:44
    #26171322
    +4
    А откуда противопоставление олимпиадников и прикладных программистов? Получается что если человек понимает алгоритмы, то он автоматически не может разобраться в новом фреймворке и архитектуре?
    
    Просто олимпиадников годами натаскивают именно на write-only код, да ещё обычно в процедурном стиле, и они к этому сильно привыкают. И иногда их приходится долго и мучительно переучивать писать по-нормальному и закрывать пробелы в знаниях (типа тех же архитектурных паттернов). А если есть ещё звездная болезнь (типа "вы чё, псы, я в финалы олимпиад выходил, и вообще, АЛГОРИТМЫ придумывать могу"), то совсем туши свет.
    
    nameless323
    17.11.2023 13:44
    #26173290
    +5
    Просто олимпиадников годами натаскивают именно на write-only код
    
    Это какие-то тысячные процента всех программистов. В остальных случаях люди достаточно хорошо понимают и алгоритмы и умеют писать нормальный продакшн код. В Фаанге том же чистых олимпиадников фактически нет. Другое дело что на том же хабре почему-то уже считается обойти дерево или написать сортировку олимпиадным уровнем.
  1. imanushin
    17.11.2023 13:44
    #26171774
    Олимпиадник-Алгоритмист в силу знания что и какими алгоритмами можно заранее оптимизировать, может понаписать и переусложнить код так
    
    Кстати, с этим успешно может справиться и любой другой разработчик. Более того, чаще переусложнение идет от отсутствия опыта или знания: например когда человек плохо понимает, как система работает под капотом, например, но успешно справляется с частными случаями.
    
    Другой пример: ошибка в дизайне проектирования вылезла уже после того, когда всем было бы очевидно, что легче переделывать.
  1. Offensive
    17.11.2023 13:44
    #26172164
    -1
    Ну да, в среднем и в целом эти приколы на собеседованиях не нужны. Сама недавно столкнулась, кстати, с другой стороной этой медали, так сказать. Чувак спрашивал меня что и как называется, при том что принимал на сольную работу, где у меня не будет тиммейтов, для которых я должна быть удобной. Такой ужас, я дропнула сразу))
1. vkni
  17.11.2023 13:44
  #26169826
  +2
  но видна не будет
  
  Потому что мы «не знаем того, чего не знаем» — если мы чего-то не узнали, то о существовании этого мы можем даже не догадываться. Плюс есть определённые выбросы в задачах, которые ставят инженеру — это же не рабочий на конвейере.
  
  Поэтому его знания должны покрывать зону типичных рабочих задач с большим нахлёстом — чтобы на случайно попавших сложных задачах он не накосячил.
1. saboteur_kiev
  17.11.2023 13:44
  #26170476
  +2
  Так дело не в среднем образовании "инженеров реализаторов", а конкретно в этом вот инженере, который базовые вещи как раз обязан знать.
  Также как и известные проблемы в популярных алгоритмах, которые были допущены "крутыми инженерами"
  
  Так вот, число первых, то есть «технологических» инженеров — сильно меньше, чем вторых.
  
  Потому что позиций меньше
  
  Их квалификация на порядок выше, чем вторых
  
  Как порядки будем считать? Я вот с этим не согласен.
  
  Инженер-алгоритмист не пишет алгоритмы каждый день. Там вообще бывает, что за год пару раз надо придумать алгоритм, который придумывается и анализируется командой, с консультациями. И это делается не за день и не за два. В тему конкретно погружаешься, почитываешь литературу, экспериментируешь.
  
  Это просто инженерная работа. На этой позиции.
  Да, конечно на такую позицию лучше собеседовать человека у которого с математикой хорошо еще до приема на работу, но не значит, что он в десять раз умнее. Он просто потратил свое рабочее время на эту задачу, в нее погружался, готовился и делал. От катастрофических ошибок он не застрахован.
  1. aamonster
    17.11.2023 13:44
    #26170730
    +1
    Ну да. Алгоритмы в том объёме, в котором они реально нужны – это не rocket science, а просто немного знаний и навыков, только доведённых до автоматизма – когда ты не задумываясь выбираешь алгоритм за O(n log n) вместо алгоритма за O(n²) (и только очень хорошо обдумав можешь остановиться на втором, объяснив причину в комментариях к коду).
1. dyadyaSerezha
  17.11.2023 13:44
  #26170926
  Все так и умение писать субоптимальные алгоритмы важна, но не надо требовать от человека написать полностью правильный алгоритм за 15-30 минут, если такой же в реальной работе пишут и отлаживают дня 3. Имею буквально свежайший опыт. Ну да, не учел кое-чего, не очистил кое-что в одном месте, но суть-то была верная. Хотя буквально через 10 минут после собеседования увидел вче свои недочёты. Но не прошёл.
  1. wataru
    17.11.2023 13:44
    #26171496
    +2
    По крайней мере на тренингах по интервью в фаангах, что я видел, учат не требовать только одно идеальное решение. И вообще там отчет по интервью пишется большой и там куча разных параметров - далеко не "задачу решил без ошибок/не справился". Не учтя что-то где-то вы получите не максимальный бал возможно. А если даже с небольшими подсказками найдете свой недочет попозже, то наоборот получите больше баллов за тестирование кода. Плюс, этих интервью до 5 штук дают. И потом комитет все отчеты смотрит и решает, что делать, чтобы такие казусы устранять.
    
    Конечно, не все интервьюверы - идеальны, а не в фаангах, которые бездумно копируют тренд, может вообще все с ног на голову быть поставлено. Но если вас завернули за мелкие косяки, то это не проблема алгоритмических интервью как таковых, а тараканы конкретного собеседующего.
  1. aamonster
    17.11.2023 13:44
    #26171748
    +1
    Я говорил не про "успеть за 15 минут", а про рефлекторное понимание, какой алгоритм или структура данных в данном месте подойдёт. Типа вот здесь дерево, здесь двоичная куча, а здесь и просто массивом обойдёмся, при переполнении будем его удваивать – амортизированная сложность нормальная будет.
    
    Чтобы поменьше было такого, что заложил не то, а когда оно выстрелит – весь в мыле бегаешь и переписываешь полпрограммы (тут, кстати, ещё привычка хорошо изолировать куски кода важна, чтобы если уж заменять – то только маленький кусочек).
1. Offensive
  17.11.2023 13:44
  #26172160
  +1
  Понятное дело, что понимать алгоритмы это заметно лучше чем не понимать)) Но уметь в принципе делать дело намного важнее чем быть крутым алгоритмизатором. Слабый (но не совсем донный, конечно же) алгоритмизатор всё равно решение рано или поздно вымучать сможет. Грубо говоря, IQ не самое важное.
  1. aamonster
    17.11.2023 13:44
    #26172170
    +2
    Тут не IQ, и большой объём знаний не нужен – сколько там этих алгоритмов? Оглавление Кнута + краткая справка по каждому поместится в тоненькую брошюрку, а детали реализации всегда подсмотреть можно (если вдруг готовая не подошла).
    
    Тут – представление об алгоритмах, общая насмотренность и выработанные рефлексы типа "нельзя здесь O(n²), есть же дерево/куча/хэш".
1. dprotopopov
  17.11.2023 13:44
  #26173822
  Вы правы ... предпоследний проект, который я допиливал, оказался из таких ... проект писался до меня года 3, технически это были несколько инстансов, которые должны были между собой синхронизиравать разные справочники/данные ... в начале кто-то запилил туда алгоритм однонапрвленной синхронизации данных, а через год, как я понял, программисты и аналитики подумали что если все работает, то можно больше не думать и стали задействовать этот же код, ьез модификации для обмена данными в двух направлениях - в результате получилось, что данные просто гоняются по кругу между отдельными инстансами приложения независимо от действий пользователей. И это лепили года 2 - при этом никто особо ничего не замечал (ни аналитики, ни тестеры), а всякие зависы списывали на баги сети... пришлось почти полгода выправлять код, что другие лепили из дерьма и палок года два-три в несколько лиц.

SpiderEkb
17.11.2023 13:44
#26169418
+3
В конце концов, можно докупить больше серверов или поставить немного больше памяти — и это будет гораздо более экономически оправданны решением, нежели тратить годы на разработку «оптимальнейшего» решения

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

Ну или просто - заказчик получает продукт, который тормозит. Поставщик говорит "у вас сервер слабый, нужен апгрейд". Ок. Вычитаем стоимость апгрейда из стоимость разработки.

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

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

В целом - ну вот чуть-чуть мозг включить и сразу будет работать на 15-20% быстрее. При абсолютно тех же затратах времени на разработку.
1. iig
  17.11.2023 13:44
  #26169462
  +2
  заказчик получает продукт, который тормозит
  
  А зачем он принимал продукт, не соответствующий требованиям?
  
  В целом - ну вот чуть-чуть мозг включить и сразу будет работать на 15-20% быстрее
  
  Люди ленивые. Если можно сэкономить мозг - сэкономят.
  1. SpiderEkb
    17.11.2023 13:44
    #26169522
    А зачем он принимал продукт, не соответствующий требованиям?
    
    А его убеждают в том, что иначе никак, только так. Хоть это и неправда.
    
    Люди ленивые. Если можно сэкономить мозг - сэкономят.
    
    Ага, при этом на чужое прям все на ... изойдут "тормозное! ресурсы жрет!" Родной, а ты сам-то как пишешь? Вот прям все до такта выжимаешь? Или "херек-херак и в продакшн"?
    
    Вот недавно переписывал модуль... Ну, блин, ну слов нет. Просто, что называется, левой ногой писано. Полностью переписал. Стало компактнее, понятнее и работает в четыре раза быстрее. Не потому что я умный такой, а потому что написано было вообще из рук вон плохо. А написать сразу аккуратно - не пришлось бы сейчас время тратить...
    
    Я понимаю, приходится иногда повозится с оптимизацией, что-то накручивать - кеширование какое-то, еще что-то... Ну там да... И то можно сразу подумать и что-то такое предусмотреть.
    
    Ладно последние пару лет ввели обязательное нагрузочное тестирование на копии промсреды. Там хоть откровенный треш не проходит уже. Все полегче.
    
    iig
    17.11.2023 13:44
    #26169536
    +1
    Родной, а ты сам-то как пишешь? Вот прям все до такта выжимаешь? Или "херек-херак и в продакшн"?
    
    Кто там все возводит в абсолют - ситхи или сикхи? ;)
    
    san-smith
    17.11.2023 13:44
    #26171210
    +2
    Хм... а вдруг этот модуль можно было ещё на 15-20% быстрее сделать?
    Вы бы на всякий случай отложили заначку, а то вдруг другой программист сделает быстрее и придётся возвращать деньги заказчику.
1. n43jl
  17.11.2023 13:44
  #26169698
  +14
  Слишком идеализировано. В реальности же нужно учитывать:
  
  Читаемость (иногда лучше пожертвовать производительностью в угоду читаемости)
  
  Простота (иногда лучше пожертвовать производительностью в угоду простоты поддержки)
  
  Дедлайны и давления бизнеса не тратить на это времени
  
  Польза бизнесу (иногда есть альтернативы сэкономить 100 000$ бизнесу и распыляться на экономию на спичках (CPU+RAM) за 500$/мес может быть нерационально с точки зрения финансов)
  1. SpiderEkb
    17.11.2023 13:44
    #26169852
    +1
    иногда лучше пожертвовать производительностью в угоду читаемости
    
    не надо противопоставлять. Производительный код может быть читаемым.
    
    иногда лучше пожертвовать производительностью в угоду простоты поддержки
    
    и простым
    
    Дедлайны и давления бизнеса не тратить на это времени
    
    "Вам чтобы быстро, или чтобы рукава одинаковые?" (с)
    
    иногда есть альтернативы сэкономить 100 000$ бизнесу и распыляться на экономию на спичках (CPU+RAM) за 500$/мес может быть нерационально с точки зрения финансов
    
    Если ваш процесс начал в период пиковой нагрузки тормозить так, что по всей стране миллионы клиентов не могу расплатиться картой вашего банка - "нет ответа от банка" - сколько вы потеряете? Реальный, кстати, случай. Именно дефект производительности, проявившийся в период пиковой нагрузки.
    
    Тут кроме прямого финансового ущерба есть еще репутационный + возможны штрафы от регулятора (время недоступности системы нормируется минутами - пара часов это уже серьезное ЧП). А регулятор наш в количестве нулей в штрафах особо не стесняется.... Ладно хоть не подняли вопрос о приостановлении действия лицензии "за неисполнение обязательств перед клиентами" (если на банк уже зуб точат, такое может стать последней каплей запросто).
    
    MiraclePtr
    17.11.2023 13:44
    #26170490
    +2
    Производительный код может быть читаемым.
    
    и простым
    
    Ах если бы. Да, иногда может, но далеко не всегда, и часто приходится выбирать одно из двух.
    
    что по всей стране миллионы клиентов не могу расплатиться картой вашего банка - "нет ответа от банка"
    
    возможны штрафы от регулятора (время недоступности системы нормируется минутами)
    
    Это всё-таки очень узкоспециализированные и специфичные задачи. Как уже метко сказали ниже, "большинство разработчиков клепают формы, и перекладывают данные с базы на фронт и обратно готовыми библиотеками". В их работе таких критичных требований нет, и цена ошибки гораздо ниже.
    
    "Вам чтобы быстро, или чтобы рукава одинаковые?" (с)
    
    ...и именно поэтому очень многие бизнесы устами менеджеров на этот вопрос не задумываясь отвечают "чтобы быстро".
1. VladimirFarshatov
  17.11.2023 13:44
  #26169766
  +12
  Подпишусь под каждым словом. Более того! Уже слышал от подобных "сборщиков кубиков" фразу "Программист не должен смотреть в код применямых библиотек" не единожды. Увы, но тотальное и хроническое (за мои 40 лет в ИТ) снижение входного порога становится всё более агрессивным. В моей молодости должность называлось математик(!)-программист и требовало знание не только алгоритмов или оценки сложности, но и целых разделов математики для доказательства(!) корректности примененного аргоритма.
  
  Из недавнего: "У Вас не достаточные знания в Postgres, а наша компания ищет разработчика для .. проектирования новой БД на нем. У Вас в резюме только MySql" А то, что проектирование новой БД требует не столько знания нюансов той или иной реляционной СУБД, сколько знание реляционной алгебры в целом .. то видимо тимлидам команды невдомек ни с какой стороны.. ни в описании вакансии ни в ответе.. :(
  
  И это один из ведущих игроков рынка. Увы.
  1. SpiderEkb
    17.11.2023 13:44
    #26169874
    Увы и ах... У меня стаж в разработке, конечно, поменьше (всего 30+ лет), но практически все время в тех областях, где требовалась высокая эффективность и быстродействие. Ну так получилось. Возможно поэтому от кода, который с первого взгляда неэффективен, просто корежит на ревью.
    
    А для проектирования БД надо да, реляционная алгебра + теория нормализации. На курсах этому не учат, это уже серьезно, там еще и база нужна.
  1. DaneSoul
    17.11.2023 13:44
    #26170336
    +7
    В моей молодости должность называлось математик(!)-программист и
    требовало знание не только алгоритмов или оценки сложности, но и целых
    разделов математики для доказательства(!) корректности примененного
    аргоритма.
    
    Так и сейчас есть сферы где это необходимо: разработка систем искусственного интеллекта, большие данные, программы сложной обработки графики и видео и т.п. низкоуровневые и математически зависимые вещи.
    Но это узкие ниши, большинство разработчиков клепают формы, и перекладывают данные с базы на фронт и обратно готовыми библиотеками.
    
    SpiderEkb
    17.11.2023 13:44
    #26171184
    +1
    большинство разработчиков клепают формы, и перекладывают данные с базы на фронт и обратно готовыми библиотеками.
    
    При этом они все пользуются готовыми библиотеками, БД и прочим, что разработано "нишевыми программистами" и еще хотят чтобы все это работало быстро и правильно.
    
    VladimirFarshatov
    17.11.2023 13:44
    #26172344
    +1
    БД ещё полбеды.. пользуются чужими пакетами для связи с БД, натыренными с гитхабов, даже не вникая чем тот или иной пакет плох или хорош, для какой специфики и круга задач автор его наклепал .. пофиг! "программист не должен смотреть в кода пакета" .. финиш тут. Главное не код, им важно поддерживается пакет сию или уже нет (sqlx уже полгода без изменений .. блин, а если в нем нет ишью, что - пробельчики в код вставлять что-ли авторам?) и .. сколько звезд насобирал пакет на гитхабе (берем этот пакет, у него звезд больше, а то что "этот" пакет на 3/4 содержит совершенно не нужного кода для вашей задачи .. ну и чО? Не, бизнес раскошелится на новое железо! .. сколько этого раскошеливающегося бизнеса позакрывалось под таким давлением ..).
    
    Вот это - реально грустно.
    
    ptr128
    17.11.2023 13:44
    #26171358
    большинство разработчиков клепают формы, и перекладывают данные с базы на фронт и обратно готовыми библиотеками
    
    Как Вы думаете, сколько лет развития AI ещё потребуется, чтобы надобность в таких разработчиках отпала? А первых из "узких ниш" AI вряд в обозримом будущем заменит. Вывод?
    
    mvv-rus
    17.11.2023 13:44
    #26172712
    +1
    Не знаю. Потому что AI не обладает опытом и здравым смыслом, чтобы отличить те 10-20 случааев, которые стандартны, от одного нестандартного. Проявляется это в склонности AI фантазировать при отсутсвии решения. Как быстро удаствя к AI прикрутить здравый смысл (и получится ли это чисто количественным наращиванием параметров) - это мне неведомо. Возможно, что для успеха внедрения AI придется поменять процессы разработки - как для успеха внедрения машин в промышленности потребовалось поменять процесс изготовления вещей - с ремесленного производства на мануфактуру.
    
    ptr128
    17.11.2023 13:44
    #26173160
    отличить те 10-20 случааев, которые стандартны, от одного нестандартного
    
    Ну так это и не требуется. Мы же говорим сейчас именно о замене только тех программистов, которым "алгоритмы не важны". А здравый смысл есть у аналитиков, которые непосредственно из своей постановки по "перекладыванию данных с базы на фронт и обратно" получат готовый код и смогут его протестировать.
    
    mvv-rus
    17.11.2023 13:44
    #26173214
    А кто этот поток фильтровать будет и по каким признакам? Сейчас вот, к примеру, фильтровать, похоже, не получается, а потому - высокий порогог вхождения в отрасль, от чего стонут и вайтишники, которые через порог перелезть могут, и бизнес, которому перелезших через порог таки не хватает.
    
    ptr128
    17.11.2023 13:44
    #26174094
    Не понял о каком потоке речь. Если о результатах работы AI - то аналитик, тестируя результат.
    
    mvv-rus
    17.11.2023 13:44
    #26174670
    -1
    Поток - задач, которые надо решить. Постфактум - результат - тоже фильтровать можно. Но я о другом. Сейчас в реально разработке не получается разбить на части задачу так, чтобы ее куски можно было бы поручить джунам (в промышленности это была бы мануфактура) - это видно по состоянию рынка труда. Почему вы уверены, что удастся разбить на части задачу, чтобы поручить части AI
    
    PS Фраза "аналитик, тестируя" у меня в голове как-то не сочетается со знакомыми мне аналитиками. Но, возможно, мне на жизненном пути не попадались хорошие аналитики, которые умеют и в аналитику, и в код.
    
    ptr128
    17.11.2023 13:44
    #26174736
    Ещё раз. Если алгоритмы программисту не нужны, то, AI вполне таких заменит. Если нужны - возвращаемся к теме статьи.
    
    Я, кстати, наоборот, не встречал аналитиков, не способных протестировать результат по своей же постановке. Где Вы таких видели?
    
    mvv-rus
    17.11.2023 13:44
    #26174756
    +1
    А если нужны, но редко, тогда как? Вы тут IMHO ложную дихотомию продвигаете: либо алгоритмы нужны для всех (основной массы) задач, либо не нужны совсем. Жизнь сложнее.
    
    PS Про аналитиков. Это было давно. И в конторах, для которых производство ПО было побочным делом. Аналитики там реально вобще были обычно пятым колесом в телеге. Если вообще были. В реале программисты, которые работали совершенно самостоятельно, каждый над своим проектом, договаривались с заказчиками сами.
    
    ptr128
    17.11.2023 13:44
    #26174842
    Вы тут IMHO ложную дихотомию продвигаете: либо алгоритмы нужны для всех (основной массы) задач, либо не нужны совсем.
    
    Вы ничего не перепутали?
    
    https://habr.com/ru/articles/774682/comments/#comment_26171358
    
    Аналитики там реально вобще были обычно пятым колесом в телеге. Если вообще были.
    
    При чем тут случай, когда аналитики выполняют свои прямые обязанности - не занимаются постановкой задач?
    
    mvv-rus
    17.11.2023 13:44
    #26174916
    -1
    Ещё раз. Если алгоритмы программисту не нужны, то, AI вполне таких заменит.
    
    Не перепутал - см. выделение. И вообще речь я веду идет о таком положении, когда с задачей из реального мира, имеющей ценность для потребителей, целеком AI не справится, и нужно задачу бить на куски, с частью из которых справятся формошлепы/джейсонмуверы сейчас и AI - в ближайшем будущем.
    Так вот, индустрия в целом сейчас не умеет так разбивать задачу и выделять из нее куски для обработки их менее квалифицированным персоналом/AI.
    
    Есть, конечно, вариант, что AI сможет целиком решать задачу из реального мира - но что-то я сомневаюсь, что это прекрасное будущее наступит сколь-нибудь скоро.
    
    PS И, похоже, словом аналитики мы тут называем разные вещи. Ну, и бог с ним, тогда, я больше не буду об этом.
    
    ptr128
    17.11.2023 13:44
    #26175698
    Нет давайте все же вернемся к чудовищной для меня логике, которая из фразы "Как Вы думаете, сколько лет развития AI ещё потребуется, чтобы надобность в таких разработчиках отпала? А первых из "узких ниш" AI вряд ли в обозримом будущем заменит. Вывод?" привела к следствию, что
    
    либо алгоритмы нужны для всех (основной массы) задач, либо не нужны совсем.
    
    Или даже из фразы "Если алгоритмы программисту не нужны, то, AI вполне таких заменит. Если нужны - возвращаемся к теме статьи."
    
    Тут явно звучит утверждение об обратном, что алгоритмы в общем случае необходимы. А те задачи, где они не нужны, вполне по силам AI.
    
    Обвинение меня в полном идиотизме и демагогии я так просто не прощу. У меня в лексиконе вообще нет понятий "для всех" и "не нужно совсем".
    
    mvv-rus
    17.11.2023 13:44
    #26175822
    Обвинение меня в полном идиотизме и демагогии я так просто не прощу.
    
    Дык, значит, я вас неправильно понял. Или вы меня. ОК, уточнение принимается. Но вернемся к нашим баранам - вам и вашему утверждению.
    
    Я утверждал, что индустрия не умеет разделять задачи на простые и сложные, например - на те, где эти самые алгоритмы не нужны и где без них не обойтись. И это утверждение, в отличие от перспектив AI, можно проверить. Можете что-то возразить?
    
    Далее: про все остальное, что там насчет лет развития AI, про это я сказать не могу: "Сегодня не все могут смотреть в завтрашний день. Вернее, не только лишь все - немногие могут"(с). Я - не могу. Ни и вы тоже, наверное, не можете, не так ли? А к чему тогда тот ваш аргумент из будущего, если он в принципе не проверяем?
    Единственно что я могу предположить - что простые задачи AI решать сможет быстрее (но это не точно). И, кстати, какие задачи для этого будущего AI окажутся простыми, в частности, как разделения задач на простые для AI и сложные связано с необходимостью применять алгоритмы для решения задач - это я тоже не знаю. Это будет ясно, только когда будет AI.
    
    Так что, кого там заменит AI - я даже рассуждать не хочу.
    Однако в скорое наступление эпохи AI-разработчиков я не верю, учитывая нынешнее состояни отрасли разработки, когда никого из мастеров- разработчиков невозможно сколь-нибудь массово заменить подмастерьями-джунами - которых много и которые сильно дешевле: то есть AI в этом нынешнем состоянии отрасли быть способен должен заменять полноценных мастеров, иначе не взлетит.
    
    Короче, если замена разраюотчиков AI станет возможной, то, я полагаю, заменят всех разработчиков, безотносительно знания алгоритмов. Но это проверить, конечно, нельзя.
    
    ptr128
    17.11.2023 13:44
    #26176906
    Я утверждал, что индустрия не умеет разделять задачи на простые и сложные, например - на те, где эти самые алгоритмы не нужны и где без них не обойтись. И это утверждение, в отличие от перспектив AI, можно проверить. Можете что-то возразить?
    
    Любой тимлид, распределяя задачи на доски своей команды, ежедневно разделяет задачи на простые и сложные, специфичные и не очень, требующие разработки алгоритма или нет. Это его обязанность вообще-то.
    
    Единственно что я могу предположить - что простые задачи AI решать сможет быстрее (но это не точно).
    
    Точно то, что он уже их решает. Если постановка, написанная аналитиком, уже является алгоритмом (что норма для простых задача), то дальше AI справится без особых проблем.
    
    никого из мастеров- разработчиков невозможно сколь-нибудь массово заменить подмастерьями-джунами - которых много и которые сильно дешевле: то есть AI в этом нынешнем состоянии отрасли быть способен должен
    заменять полноценных мастеров
    
    У Вас самого эта фраза конгнитивный диссонанс не вызывает?
    
    Или Вы искренне считаете, что если лаборант не может заменить профессора, то робот, заменяющий лаборанта должен уметь заменять профессора?
    
    Или все же автоматизация затрагивает, в первую очередь, наиболее простые операции и вытесняет наименее квалифицированный персонал?
    
    SpiderEkb
    17.11.2023 13:44
    #26176808
    +1
    В нашем случае задача аналитика написать FSD по согласованному BRD, потом протестировать поставку на соответствие с FSD, отдать ее на бизнес-тест, далее - на нагрузочное тестирование и далее на внедрение (план внедрения, план отката...) Т.е. полное продвижение поставки от разработчика до прома.
    
    SpiderEkb
    17.11.2023 13:44
    #26176792
    У нас компонентное тестирование (первый этап - тестирование поставки на соответствие FSD) лежит на аналитике. Да, есть тестировщики, но они автотестами занимаются. А ручное тестирование на аналитике.
    
    Я вот в последнее время с аналитиком работаю который еще и код понимает и под отладчиком умеет. Т.е. человек может под отладчиком пройти сомнительный тесткейс и сказать - "вот тут ошиблись, надо это условие вот так поменять". Прямо конкретно по коду.
    
    Но это, конечно, исключение.
    
    BugM
    17.11.2023 13:44
    #26173218
    +1
    С чего бы аналитикам вообще смотреть на ваш код? У них другие задачи. Есть вход - есть выход. Они могут подтвердить что выход имеет смысл и посчитан верно. А что там у вас хоть факториал им вообще все равно. Выход верный - значит с их точки зрения все работает правильно.
    
    mvv-rus
    17.11.2023 13:44
    #26173228
    Ага, а ещё вы тут вспомните историю интересную, которую вы мне тут недавно приводили, где недостаток производительности вылез в совершенно невинно выглядевшем коде из-за фичи (ибо баг документированный есть фича) в системной библиотеке. IMHO она тут в тему.
    
    ptr128
    17.11.2023 13:44
    #26174106
    Зачем аналитику смотреть на код?
    
    Они могут подтвердить что выход имеет смысл и посчитан верно. А что там у вас хоть факториал им вообще все равно. Выход верный - значит с их точки зрения все работает правильно.
    
    Именно так. И, так как выше было заявлено, что для решения подобных задач "алгоритмы не нужны", то больше ничего не требуется. Или приходим все же к тому, что алгоритмы нужны. Выбирайте.
  1. gatoazul
    17.11.2023 13:44
    #26170384
    +5
    Математические доказательства корректности программ были сладкой мечтой в 80-е годы. Практическую пользу так и не продемонстрировали.
    
    wataru
    17.11.2023 13:44
    #26170422
    +2
    Практическая польза есть, и несоменная: Вы можете объяснить свой алгоритм другому программисту и вы можете быть в нем уверены. Для чуть более сложных алгоритмов понимание его и формальное доказательство - фактически идентичны.
    
    BugM
    17.11.2023 13:44
    #26170448
    +8
    Для чуть более сложных алгоритмов понимание его и формальное доказательство - фактически идентичны.
    
    Точно? Мерджсорт я думаю вы понимаете. Он достаточно прост чтобы его объяснить неглупому школьнику.
    
    Теперь посмотрите его формальное доказательство. Оно вообще тоже несложное. По меркам формальных доказательств несложное.
    
    А потом посмотрите на формальное доказательство Квиксорта. Я думаю вы этот алгоритм тоже понимаете. Доказательство там по настоящему взрослое. Попробуйте понять его.
    
    Вот поэтому формальные доказательства и не взлетели.
    
    wataru
    17.11.2023 13:44
    #26170480
    -1
    Мы наверно о разном уровне говорим. Совсем в формализм упарываться - конечно не надо. Но ввести инварианты, и показать, почему операция слияния выдает сортированный список и так же простые вычисления, показываюшие что там log n этажей и суммарно все это удовольствие будет O(n log n) - это вполне себе математическое и формальное доказательство.
    
    С квиксортом тоже - ввести инвариант (в зависимости от метода разбиения разный) и все.
    
    BugM
    17.11.2023 13:44
    #26170504
    +8
    Формальное доказательство алгоритма означает абсолютно конкретную штуку. Математическое доказательство вашего алгоритма как любой теоремы.
    
    То что вы написали это даже близко не доказательство. Доказывать как бы надо все. Вот это "очевидно" не работает. И базовые штуки доказаны. Остальное мы обычно просто на их основе строим.
    
    Сложные штуки построенные на основе доказанных базовых доказать обычно тоже можно. Но сложно. И не то чтобы нужно. Даже софт спутников не доказывают. Что про наши перекладыватели джейсонов говорить. Не стоит оно того.
    
    wataru
    17.11.2023 13:44
    #26170544
    Доказательство через инвариант - вполне себе формальное. Там нет никаких "очевидно". Как нет и записи вроде "M - это множество..." и всяких математических формул. Зато есть, допустим "после каждой итерации цикла по i первые j числа в массиве меньше равны Pivot, числа c j по i - больше Pivot, а остальные числа остались на своих местах".
    
    BugM
    17.11.2023 13:44
    #26170548
    +2
    Точно меньше? Точно больше? Докажете что это так? Для любого входного значения надо доказывать конечно же. Без множества сложно как-то. Сортировка это операция над множеством в конце концов.
    
    Остались на самом деле остались если не их не трогали. Это подойдет.
    
    Формальные доказательства они сложные не потому что кому-то делать нечего. Они просто такие есть. Доказывать вообще сложно.
    
    wataru
    17.11.2023 13:44
    #26171506
    Точно меньше? Точно больше? Докажете что это так?
    
    Легко. В цикле есть if. Если A[i] > pivot, то вот в цикле просто увеличивается i. Числа до j не поменялись, числа j..i-1 тоже не поменялись с прошлой итерации и там инвариант выполняется. Число Ф[i] удовлетворяет инварианту. Если A[i] <= pivot, то там делается swap j+1 и i. Увеличивается j. Числа до j-1 остались с прошлой итерации, новое число a[j] - по проверенному условию удовлетворяет инварианту. На мето i попало число, которое на прошлой итерации было после j, значит тоже инварианту удовлетворяет.
    
    Вообще, конечно, можно это все в виде леммы и тероемы оформить и по индукции доказывать, но в такой формализм не обязательно закапываться.
    
    orenty7
    17.11.2023 13:44
    #26171608
    но в такой формализм не обязательно закапываться
    
    В этом-то и дело, что чтобы убедить компилятор формально верифицированного языка нужно закапываться
    
    Могу сразу сказать где у вас возникнут трудности:
    
    "Если A[i]" Доступ к A[i], нужно показать, что i корректный индекс
    
    "не поменялись с прошлой итерации" -- итераций нет, нужно переделывать на рекурсию
    
    "делается swap" -- данные иммутабельные, нужно писать свой swap и доказывать, что все остальные элементы остались на своих местах
    
    "j + 1" -- доказать, что j + 1 корректный индекс
    
    "Числа до j - 1 остались с прошлой итерации" -- прошлой итерации нет, при рекурсии нужно требовать доказательство корректности входных данных
    
    Если интересно -- я могу дать названия книг и несколько сайтов с формальными доказательствами. Можете попробовать оформить ваше доказательство
    
    wataru
    17.11.2023 13:44
    #26171658
    +1
    В этом-то и дело, что чтобы убедить компилятор формально верифицированного языка нужно закапываться
    
    Мы о разных вещах говорим. Я не считаю, что формально ферифицировать программы специальными языками - стоит. Это действительно очень муторно. Я лишь говорил о том, что программист должен хотя бы сам себе логически обосновать почему вот этот код работает.
    
    antonkrechetov
    17.11.2023 13:44
    #26176022
    +1
    А потом посмотрите на формальное доказательство Квиксорта. Я думаю вы этот алгоритм тоже понимаете. Доказательство там по настоящему взрослое.
    
    Формальное доказательство алгоритма означает абсолютно конкретную штуку. Математическое доказательство вашего алгоритма как любой теоремы.
    
    Вы, наверное, имеете в виду конкретно доказательство, подходящее для верификации. Обычное-то математическое доказательство должно быть довольно простым - с использованием индукции по длине массива (которую при верфикации, конечно, не применить).
    
    orenty7
    17.11.2023 13:44
    #26170856
    +3
    Тут пару лет назад доказывали, что gcd корректен. https://0xd34df00d.me/posts/2020/09/agda-wf-rec.html
    
    Формальные доказательства это сложно. Это сложнее чем математические доказательства, потому что приходится писать на "математическом ассемблере"
    
    Из личного опыта: я неделю потратил пытаясь доказать корректность частичной реализации printf (поддерживает только %u и %s). На обычном языке на написание и проверки времени бы ушло не более часа
    
    VladimirFarshatov
    17.11.2023 13:44
    #26172364
    +2
    Акцент был сделан не на это. Взлетели или нет. Писалось за другое: когда-то это было штатным требованием для трудоустройства. А теперь про это даже не знают "про что это", но .. тоже "погромист".. падение "уровня входа" катастрофически влияет на КАЧЕСТВО результата - того ПО, которым пользуются миллионы. Откройте ЛЮБОЙ веб-сайт. Люблой. Посмотрите инспектором запросы к серверу, сообщения в консоли, сопоставьте ЭТО с тем, что видно на экране .. и расскажите "где тут эти мегабайты?"
    
    А теперь представьте, что Вы уехали в деревню и в ней нет ничего, кроме модемной связи пусть даже продвинутой 56кбод.. за 19200 молчу, молчу..
    
    gatoazul
    17.11.2023 13:44
    #26170650
    +3
    Для чуть более длинных алгоритмов математические методы доказательств просто погрязли в сложности, забуксовали и умерли.
    
    vkni
    17.11.2023 13:44
    #26170456
    +1
    Практическую пользу так и не продемонстрировали.
    
    Ну вот я сейчас работаю над программой, проводящей трансформации директив #include в C++ файлах. В конторе этих файлов 8 миллионов, группа наша из 4 человек, соответственно мы можем справится с потоком рекламаций из примерно 100 ошибок. Вы можете примерно посчитать, с какой точностью должен работать алгоритм, сколько там должно быть девяток.
    
    Соответственно, практическая польза — я утону в потоке сообщений об ошибках или нет.
    ____________________________
    То есть, это всё сильно зависит от области. От того, можете ли вы бросить 10 тыс безымянных Вась на ручную обработку или нет.
  1. Cerberuser
    17.11.2023 13:44
    #26170908
    Программист не должен смотреть в код применямых библиотек
    
    Это даже в "перекладывании джейсонов" не всегда работает. Иногда быстрее пробежаться с отладчиком по коду зависимости, например, чем перерывать тонну документации в поисках того единственного параметра, который внезапно ломает что-то вроде бы не связанное.
  1. bondeg
    17.11.2023 13:44
    #26171620
    +3
    У каждой sql БД общий +- синтаксис, но есть сильно свои особенности. Так что если ребятам нужны специалисты по конкретной БД - это вполне оправдано, т.к. не надо ждать пока кандидат втянется, изучит нюансы и т.д., им нужно, чтобы был готовый спец на данную позицию. Иногда это может быть и не сильно нужным, но тут мы можем только гадать.
    
    Иначе через год эксплуатации выяснится, что не был учтён какой либо нюанс и что-то можно сделать оптимальнее, но для этого потребуется простой сервиса и затраты сисадмина, разработчиков. И всё потому что дали задачу тому, кто ещё не готов на все 100%.
    
    Как к примеру в mysql нужно понимать разницу между myisam и innodb или особенности партиционирования.
    
    VladimirFarshatov
    17.11.2023 13:44
    #26174700
    Верно, у каждого инструмента есть свои особенности, тем они и различаются. Разделы по тюнингу и оптимизации достаточно обширны на любой СУБД. Но! Ни в вакансии ни в ответе кадровика .. нет НИ СЛОВА за Реляционную Алгебру! Как знание нюансов раскладки и применения, скажем партицирования или особенности индексации тем или иным способом или наличие/отсутствие триггеров спасет такую команду от проектирования в стиле 1НФ, без знания "что это за зверь"?
    
    Нюансы той или иной БД важны конечно же, но кмк "после" реляционной алгербы а не вместо..
  1. piton_nsk
    17.11.2023 13:44
    #26171788
    +1
    А то, что проектирование новой БД требует не столько знания нюансов той или иной реляционной СУБД, сколько знание реляционной алгебры в целом
    
    Это если что-то простое делать. А если лезть чуть поглубже (даже не в потроха), то уже все значительно сложнее. Я в свое время читал оракловый performance tuning guide, это были 2 хороших тома. И для каждой СУБД будет так же.
  1. GidraVydra
    17.11.2023 13:44
    #26175764
    +1
    При чем тут ваша молодость? 40 лет назад, точно так же, как и сейчас, были и программисты, и математики-программисты. Последних всегда было немного в силу высоких квалификационных требований. А потребность в коде возросла на порядки. Для бизнеса же лучше хоть какой-то код, чем вообще никакого.
    
    По поводу БД - надо понимать разницу между "я умею плавать" и "я знаю плавать". Тимлид, который вас собеседовал, разницу эту усвоил, причем скорее всего на своем горьком опыте.
    
    mvv-rus
    17.11.2023 13:44
    #26175844
    По поводу БД - надо понимать разницу между "я умею плавать" и "я знаю плавать".
    
    Тут есть нюанс: плавание - это навыык мышечный, там мало знать а надо наработать координацию движений. А работа с БД - нет. Там без тренировки навыка обойтись можно, знаний хватит - ну, разве что, работать получится поначалу немного медленнее.
  1. andmerk93
    17.11.2023 13:44
    #26176688
    +1
    У Вас не достаточные знания в Postgres...
    У Вас в резюме только MySql
    
    Я думаю, вам отказали по какой-то другой причине, а это просто формальная отговорка.
    За 40 лет стажа можно было научиться понимать такие вещи.
  1. nameisBegemot
    17.11.2023 13:44
    #26176704
    Снижение уровня входа в ит не всегда плохо. Это значит, что продукт ит становится легче в понимании. А ситуация, когда продукт могут понять только математики, да ещё и с специальными навыками может тормозить прогресс.
    
    Тот же персональный пк. Раньше для его запуска нужно было много знать. А сейчас в любой лавке на рынке используют пк. Прогресс.
1. qw1
  17.11.2023 13:44
  #26169842
  +15
  Я бы на месте потребителя оплачивал бы расширение памяти или покупку нового сервера из кармана того разработчика, который реализовал решение, работающее 0.15с вместо возможных 0.1с
  
  Это должно работать и в обратную сторону. Если договорились, что сервис должен держать 100к rps на Xeon 2288, а разработчик делает код, который держит на Pentium, то разница - в карман разработчику. Тогда к вам выстроится очередь олимпиадников, готовых сорвать куш на жётско оптимизированном ассемблерном коде с развёрнутыми циклами и сбежать в закат, а кому это потом поддерживать - не их дело.
  
  Ну, или вы говорите - хочу 100к rps на Xeon 2288, все смотрят, качают головой и проходят мимо, и вам приходится снижать планку требований.
  1. konst90
    17.11.2023 13:44
    #26169998
    +1
    Разница между остаточной ценой сервера на Xeon и (официально купленного) нового Pentium с сервером может быть не так велика, как кажется.
    
    SpiderEkb
    17.11.2023 13:44
    #26171188
    Я тут приводил параметры сервера с которым мы работаем. Это радикально иные мощности.
1. wataru
  17.11.2023 13:44
  #26169896
  +5
  В конце концов, можно докупить больше серверов или поставить немного больше памяти — и это будет гораздо более экономически оправданны решением, нежели тратить годы на разработку «оптимальнейшего» решения
  
  Я что-то этой фразы в статье не нахожу. Автор, вы ее убрали при редактировании?
  
  Но не могу пройти мимо и вставить свои 5 копеек.
  
  В фаангах, такие масштабы, что "докупить больше серверов" - это огроменные деньги. А сервера эти итак уже некуда ставить - новые датацентры строить не успевают. А память нельзя докупить, потому что ее у поставщиков физически больше нет.
  
  Поэтому помимо юнит и подобных тестов, многие части покрыты и performance тестами, и если что-то где-то ухудшается, это стараются чинить.
  
  Потом, это знание алгоритмов - это не "тратить годы на разработку оптимальнейшего решения". Это просто давать вот такие вот интервью. Итак от кандидатов отбоя нет, а так хоть какой-то объективный критерий появляется.
  1. SpiderEkb
    17.11.2023 13:44
    #26169938
    +8
    В фаангах, такие масштабы, что "докупить больше серверов" - это огроменные деньги. А сервера эти итак уже некуда ставить - новые датацентры строить не успевают. А память нельзя докупить, потому что ее у поставщиков физически больше нет.
    
    И не только в фаангах. Смотрю по нам - банк, центральные сервера. Никаких облаков. Все "во внутреннем периметре". Сервер, на котором мы работаем -
    
    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 мин.
    Заказчикам сервиса это может не понравиться :("
    
    И с этим надо срочно что-то делать.
    
    И подобного прилично прилетает от сопровождения - они постоянно процессы мониторят на сервере - кто долго выполняется, кто ресурсы жрет как не в себя и т.п.
    
    bondeg
    17.11.2023 13:44
    #26171636
    +1
    Так а какой смысл иметь 1 гипермощный сервер, когда можно разложить в кластер на несколько серверов?
    
    Навскидку - когда транзакция проходит в основное хранилище создаём в условную кафку событие и далее уже все неприоритетные сервисы, которые не работают непосредственно с баблом (траты, зачисление) её вычитывают к себе.
    
    Плюс какой-нибудь крон для проверки, что все транзакции попали в кафку.
    
    inkelyad
    17.11.2023 13:44
    #26171668
    Накладные расходы на обмен данными между узлами кластера - просто ну сильно больше, чем когда все данные сразу в одной здоровенной памяти лежат.
    
    bondeg
    17.11.2023 13:44
    #26171760
    Мы же говорим про банковскую сферу. Там всё, что не текущий год-два вообще на архивный сервер, что не требует высокой производительности и частых обращений можно вынести, нет?
    
    И какие там объемы данных гоняются, что условного гигабита не хватит? Не фоточки же. (Хотя они тоже могут быть, но это явно не забота центрального хранилища транзакций).
    
    inkelyad
    17.11.2023 13:44
    #26171866
    +2
    И какие там объемы данных гоняются, что условного гигабита не хватит?
    
    Одно дело, когда база, живущая прямо тут же в железе, выдает тебе сразу по 'SELECT ' по номеру счета и другое - когда это все проходит через десяток сериализаций-десереализаций на (микро)сервисах и потом по сетевым интерфейсам.
    
    Миллисекунды накапливаются.
    А так - смотрим в табличку 'Основные показатели развития национальной платежной системы'. За 2022 год только по картам - 69298 млн операций. Это, если я с арифметикой не ошибся 2197 операций в секунду в среднем, равномерно размазанном по времени. И каждая операция далеко не один запрос в базу и не одно сообщение.
    
    Ну да, это по всей платежной системе и в каждом конкретном банке только сильно меньшая часть. Но там же не только операции по картам а вообще много чего еще происходит.
    
    В общем, если надо быстро - то приходится таки вот железки иметь.
    
    SpiderEkb
    17.11.2023 13:44
    #26171834
    +2
    Смысл в том, что данных очень много. И они очень разнородные. Банк - это не только счета-проводки, но и клиентские данные (не поверите, но только адресов у клиента штук 5-6 разных типов может быть, а еще несколько ДУЛ - документов удостоверяющих личность). А еще риски (репутационные, страновые, региональные...), есть "запреты". У клиента могут быть "субъекты" (всякие доверенные лица и т.п.) у которых тоже данные.
    
    Есть комплаенс со своими заморочками - списки росфинмониторинга которые регулярно приходят и их надо раскладывать по БД, а потом прогонять всех клиентов на совпадение (по ряду параметров - ФИО+ДР для ФЛ или наименование для ЮЛ, ДУЛ для ФЛ, ИНН, адреса...) с субъектами списков и формирования стоп-листов. Выливается это условно в сравнение 50млн клиентов с 300-500тысяч субъектов списков (а субъект списка - это "Она же Анна Федоренко, она же Элла Коцнельбоген, она же Людмила Огуренкова, она же..., она же Изольда Меньшова, она же Валентина Понеяд" - несколько имен/наименований, несколько ДР, несколько ИНН, несколько ДУЛ и т.п.). Формально - каждого с каждым.
    
    Есть еще обязательная отчетность.
    
    Есть уведомления клиентам по всяким разным поводам типа "Проверка действительности ДУЛ по сроку для владельцев корпоративного пластика" (на самом деле там десяток разных проверок) с рассылкой уведомлений о том что срок действия ДУЛ истек или истекает через ... дней.
    
    А еще всякие тарифы, лимиты, кредиты-депозиты, проценты...
    
    И еще огромная куча всего-всего разного. И его реально много. И все это должно работать быстро. Потому что одновременно крутится десятки тысяч бизнес-процессов.
    
    А еще это должно быть меганадежно.
    
    А еще там не может быть никаких облаков. Все внутри закрытого периметра.
    
    Про закрытие банковского дня (EOD - end-of-day) в течении которого тоже огромное количество процессов идет уже молчу...
    
    Навскидку - когда транзакция проходит в основное хранилище создаём в условную кафку событие и далее уже все неприоритетные сервисы, которые не работают непосредственно с баблом (траты, зачисление) её вычитывают к себе.
    
    Все это было у мелких банков. Но работало очень медленно и там свои заморочки типа - есть счет, на счете 1000р. К нему привязано две карты. На каждой отражается остаток по карте 1000р. Платишь одной картой 1000р - на ней остаток становится 0. А на второй все еще 1000р (основное хранилище - т.н. "кешир", транзакция там, пока кто-то ее заберет оттуда...) Платишь второй 1000р и через несколько часов оп-па - влетел в технический офердрафт. На счете -1000р.
    
    Для крупных банков, работающих в режиме реального времени это недопустимо.
    
    Так что не все там так просто. И да, Сервер не один. Их там 2-3 штуки + горячий резерв на который можно в любой момент переключиться за считаные минуты если что не так пошло. Но, повторюсь, объемы информации, количество процессов (десятки тысяч параллельно) и операций (сотни миллионов в сутки) вынуждают думать за эффективность.
    
    И это только "центральные системы". Где на 90% mission critical. Все второстепенное вынесено на внешние системы - их тоже несколько десятков разных. Там уже business critical - попроще все.
    
    VladimirFarshatov
    17.11.2023 13:44
    #26172392
    Всё так. Но часто можно видеть вакансии "нужен бекендер на высокопроизводительный .. стартап".. Какова посещаемость (хотя бы)? Мы ещё проектируем систему, планируем пару миллионов в месяц .. блин, Вы хотябы выйдите из священной пятерки: директор, бухгалтер, разраб, менеджер и тестировщик.. ;)
    
    imanushin
    17.11.2023 13:44
    #26171930
    +5
    Так а какой смысл иметь 1 гипермощный сервер, когда можно разложить в кластер на несколько серверов?
    
    Статья именно про это. Если Вы хотите спроектировать систему так, чтобы она эффективно работала на кластере, а не на одном сервере, то Вам будет необходимо знание алгоритмов, технологий, а также наличие тех самых soft skills, кругозора в айти мире (чтобы не выбрать тот же Питон для крупного модуля, когда есть языки со строгой типизацией) и так далее.
    
    В противном случае получится долгострой, ибо постоянно будут встречаться неудачные решения, которые не позволят добавлять новые и новые функции.
    
    С одним сервером всё намного проще. Например, можно брать блокировки (а децентрализованная система скажет спасибо такой идее), можно не напрягаться с eventual consistency, а использовать строгую согласованность и так далее.
1. mvv-rus
  17.11.2023 13:44
  #26170332
  +7
  Я бы на месте потребителя оплачивал бы расширение памяти или покупку нового сервера из кармана того разработчика, который реализовал решение, работающее 0.15с вместо возможных 0.1с.
  
  Точнее, на месте потребителя вы бы оплачивали вместо покупки сервера дополнительное время работы разработчика, требуемое на оптимизиацию кода с 0,15 до 0,1с. Ну, или время разработчика, который умеет сразу писать такой код - а оно тоже дороже стоит, ибо не только лишь все в это умеют, ресурс этот более дефицитный, а потому на рынке стоит дороже. То есть дополнительные затраты - на разработку вместо на дополнительный сервер - у вас все равно бы были, только другие. А ещё ведь есть затраты на дальнейшую модернизацию, которые зависят от того, насколько удобен для понимания код. А удобство для понимания и эффективность выполнения (по времени, памяти и т.п.) кода - это те самые противоположности, которые хоть едины, но между собой борются.
  
  Как эффективнее совместить все эти противоположности - это вопрос, для каждого предприятия, и вопрос конкретный. И если в этом вашем банке такие экономически оправданы затраты именно на эффективность выполнения, то где-нибудь в вебе - ну, совсем не всегда. Каждое прежприятие должно искать свой баланс. А баланс в нынешней системе управления экономикой устанавивается рынком и конкуренцией на нем. Потому что рационально рассчитать и директивно установить баланс не получается. Если чо, в СССР (помните такой?) пробовали делать именно так - но получалось обычно, как известно, плохо.
  
  Собственно говоря, разработчик не обязан уметь быстро реализовать те алгоритмы, которые уже реализованы во множестве библиотек. Но он обязан знать как они работают и чем отличаются.
  
  Напрашивается вопрос: а почему бы не завести каталог алгоритмов и реализаций? Чтобы любой джун мог посмотреть и выбрать? "Хоть безумная идея, но не ругайте сгоряча"(с) - может, на этом получится и бизнес сделать?
1. xenon
  17.11.2023 13:44
  #26170858
  +1
  Хотел вам возразить, что очень важны затраты времени на разработку. Потом прочитал ваше последнее предложение. Сначала, на долю секунды подумал, не возражать, но потом понял, что надо!
  
  Как это у вас получилось, что "при тех же затратах"? Вы же говорите, что сначала код был "плохой". У этого есть причина. Пример задачи - что-то делаем с базой данных, дергая каждый раз из нее SELECTом разные записи, сравниваем, дергаем другие. Можно оптимизировать написав длинный сложный запрос с JOINами.
  
  Но плохой, неоптимизированный код часто бывает проще придумать, он более естественнен для нашего человеческого ума. Вот программист его и придумал и закоммитил. Если вы хотите, чтобы он дольше думал - на то чтобы думать, читать документацию, дебажить хитрый код - надо время. А это - лишние затраты на разработку.
  
  Или, можно нанять более толкового спеца, который не пил пиво на лекциях.Да, Чак Норрис эту же задачу сделал бы правильно и даже быстрее, но он и стоит дороже.
  1. SpiderEkb
    17.11.2023 13:44
    #26171204
    Вы же говорите, что сначала код был "плохой". У этого есть причина. Пример задачи - что-то делаем с базой данных, дергая каждый раз из нее SELECTом разные записи, сравниваем, дергаем другие. Можно оптимизировать написав длинный сложный запрос с JOINами.
    
    На самом деле есть много возможностей сделать одно и то же. В нашем конкретном случае, где язык поддерживает как встроенный SQL, так и прямой доступ к БД.
    
    Можно дергать выборку по одной записи, можно дергать блоками по 1000 (например) записей - это быстрее.
    
    Можно часть логики из SQL выдернуть на постобработку (например, лианеризовать запрос, убрав оттуда все агрегатные функции, избавившись от group by, order by по неиндексируемым полям и делать все это в процессе потоковой обработки - практика показывает что так можно в 3-4 раза ускориться). Один из простейших примеров приводил тут
    
    У меня был случай, когда решение "в лоб" давало время выполнения 3 секунды. При требованиях уложиться в 300мсек. А "если включить мозг и подумать", то получилось реализовать решение, работающее 150-200мсек. Но это если подумать...
    
    "Вася с курсов" просто скажет - это невозможно (реально были такие случаи - "невозможно потому что в фреймворке этого нет"). Для более-менее грамотного человека, привыкшего работать головой, а не тупо лепить из кирпичиков типовые решения, это просто "займет чуть больше времени".
    
    xenon
    17.11.2023 13:44
    #26171890
    Так приходим к неожиданному выводу, что более-менее грамотный - ценнее! Но беда в том, что он и дороже. Потому что этот неожиданный вывод понимают и в Сбере и в Яндексе и в Гугле и в СМУ-6 и Ростов-опт-шин-торге и все хотят более опытного заманить к себе высокой зарплатой и бесплатными ананасами. Тех же самых затрат на разработку не получается.
1. ogost
  17.11.2023 13:44
  #26172562
  Два цикла там, где все у один укладывается это еще не самое страшное.
  
  Я видел запросы к стороннему сервису, обёрнутые в два цикла, и всё это время фронт ожидает ответа. Если данных для обработки много, то нередко фронт отваливался с connection timeout. Написал это чувак, который в то время был сеньором, сейчас он тимлид. Пробежался по коду того бека, практически все его решения - в лоб. Но зато клепал таски со скоростью света. Поэтому, вероятно, он быстро поднялся по карьерной лестнице.
  1. mvv-rus
    17.11.2023 13:44
    #26172776
    И подозреваю, что с точки бизнеса он был прав: возможно у бизнеса была задача "все для уменьшения TTM". Потому что бизнес по классификации Белоусова попадал в категорию "крысить" (с вебом AFAIK это бывает нередко), и там главное было сделать быстрее, пока другие в эту нишу не залезли и все ништяки не растащили.
  1. SpiderEkb
    17.11.2023 13:44
    #26173584
    На самом деле, в последней "задаче на оптимизацию", помимо всего прочего, линеалиризировал все скули (а они там нетривиальные - 5-7 таблиц, 2-3 подзапроса и т.п.). Т.е. выкинул оттуда все group by и order by. Результат читается блоками по 1000 записей и складывается в список. На этом этапе происходит вся нужная агрегация и сортировка (список - key-value, быстрый поиск по key, элементы сразу размещаются "по месту", сортировка "автоматом").
    
    А потом уже быстрый проход по списку от first к next с конечной обработкой элементов.
    
    Да, два цикла. Да, избыточный скуль. Но там получается намного проще план запроса и он кратно быстрее работает. В сумме получилось в четыре раза ускориться.
    
    Но подобные вещи уже, естественно, в камментах к коду описываются - почему именно так.
1. ussrisback
  17.11.2023 13:44
  #26176634
  +1
  ваш работодатель обеспечивает вам идеальные условия труда? у вас достаточно времени на анализ требований, дизайн архитектуры, верификацию и т.д.? Вы получаете идеальные бизнес требования и необходимое время на реализацию?
  
  подозреваю, что ответ на большинство вопросов - нет. поэтому ваше предложение наказывать разработчика за неэффективное решение как минимум наивно.
  1. SpiderEkb
    17.11.2023 13:44
    #26176914
    ваш работодатель обеспечивает вам идеальные условия труда?
    
    Не знаю что есть "идеальные". Комфортные - да. Обеспечивает.
    
    у вас достаточно времени на анализ требований, дизайн архитектуры, верификацию и т.д.?
    
    Да. Никто никогда не гонит по срокам. Бывает "нормативка" (когда дедлайн строго и жестко задан), но это достаточно редкий случай.
    
    Вы получаете идеальные бизнес требования и необходимое время на реализацию?
    
    С бизнес-требованиями (BRD) работают архитекторы (согласование архитектурного решения) и аналитики (написание по ним FSD). Я работаю с FSD уже. Оценку сроков на реализацию даю я сам (и всегда делаю это с запасом).
    
    Если возникают какие-то вопросы по реализации - их всегда можно обсудить с аналитиком.
    
    Для нас во главе угла всегда стоит надежность и эффективность. Эффективность и надежность. Такая специфика. Потому что цена ошибки (в том числе потенциальная потеря производительности при пиковой нагрузке) для нас неиллюзорна и очень высока.
    
    Примеры я приводил уже. Был реальный случай когда нормально (казалось бы) работающий в обычных условиях модуль в условиях пиковой нагрузки начал дико тормозить что повлияло на смежные процессы. В результате у миллионов клиентов по всей стране в течении полутора-двух часов (пока сопровождение не организовало WA ситуации) были большие проблемы с оплатой картами банка в магазинах (оплата не проходила - "нет ответа от банка"). Ощущаете масштабы факапа? За такое можно от регулятора очень неслабые штрафы получить. Не говоря уже о репутационных издержках.
    
    Или известный мне случай из той же серии - запись детей в школу через ГУ. 1-е февраля, полночь, родители массово ломятся на портал записать ребенка в ту школу, куда хочется. Пиковая нагрузка. Портал ложится. Запись не проходит. А потом выясняется что в той школе куда хотели, мест уже нет. Жалобы, скандалы... Лет 5-7 назад, по-моему, это было на протяжении 2-3 лет. Сейчас не в курсе что и как, вроде нормализовали как-то...
    
    Одна из причин аварии на Чернобыльской АЭС знаете какая (на всякий случай - это моя институтская специальность - реакторы и учился как раз в те годы когда это случилось)? Дежурная смена просто не знала что прямо сейчас происходит в реакторе и что нужно делать. Там огромное количество датчиков, на основе показаний которых получают карту распределения плотности нейтронных потоков по АЗ, и по ней система выдает рекомендации по управлению реактором (там в определенных условиях нельзя просто взять и сбросить все стрежни - станет только хуже, положение каждого стержня рассчитывается индивидуально). В те времена просто не было таких вычислительных мощностей, которые могли бы обеспечить обработку такого объема информации в реальном времени. В штатном режиме все работало, но в аварийной ситуации мощности системы не хватило. Так что в общем случае - тоже проблема производительности.
    
    Областей разработки, где нельзя (очень дорого) забивать на производительность в угоду ТТМ немало. Да, конкретно Вы можете с этим не столкнуться никогда, но это не значит что такого нет.

Batalmv
17.11.2023 13:44
#26169436
+17
Но вот, какие знания для него точно избыточны и не нужны в работе — это, к примеру, та же гидродинамика. Ему попросту негде применить эти знания.

Интересно, а как тогда разводку проектировать? Как раз прикол в том, что есть конечно все по отдельности, но собрать это все в кучу тоже нужно много знаний :)

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

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

Мне кажется, вы, к сожалению, так и не поняли, что такое алгоритм :)

sleirsgoevy
17.11.2023 13:44
#26169466
+4
Вставлю свои пять копеек. Да, спортивное программирование — параллельный к промышленной разработке мир. Примерно как современный парусный спорт абсолютно параллелен современному водному транспорту. Да, если бы при приёме на работу во флот требовали проходить на время гоночные трассы на паруснике — это был бы полный бред, поэтому никто такого и не делает.

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

Немного напрягает, что вот такие вот продуктовики меряют всё исключительно по себе.
1. despair Автор
  17.11.2023 13:44
  #26169492
  +4
  Так поэтому я и пишу, что есть ниши — где это нужно и важно. Это ниши создания технологий / фреймворков / СУБД / высоконагруженных библиотек / языков программирования.
  Я пишу о том, что зачастую эти "алгоритмические" требования предъявляют к ситуациям и контекстам, когда они вообще не важны.
  1. SpiderEkb
    17.11.2023 13:44
    #26169614
    +2
    По мне так умение выбрать и использовать наиболее подходящий именно здесь алгоритм важно везде. А для этого надо понимать как они работают, чем отличаются и какой где лучше.
    
    В "нишах" - там отдельная песня. Там часто свои алгоритмы изорбретают.
  1. akhmelev
    17.11.2023 13:44
    #26169616
    +5
    Конкретно в Яндекс алгоритмы как раз критически важно. Часто высокие нагрузки, и код на общеупотребимых фреймворках там всяких не особо и нужен. Много всякого своего написано. Многое вообще моделируют на питоне и переписывают потом под прод на С. Так что собес очень зависит от позиции и задач. Круды писать так там не надо, вот и проверяют на алгоритмы. Несколько лет назад я был внутри и читал ручным тестировщикам(!) курсы как раз-таки по CS. Так что там это не хотелки а необходимость. Реально нужен этот скилл, чтобы не набокорезить.
    
    Кто же на круды набирает, тот и замороченные олимпиадные задачки давать не будет. Ну максимум спросит быструю сортировку или хеш-таблицу. Ну так это на самом деле любой инженер софтверный просто обязан знать, час времени на одно и час на другое надо (на изучение я имею ввиду). Почему бы и не проверить, потрачены они были или нет.
    
    xenon
    17.11.2023 13:44
    #26170868
    +1
    Честно говоря, я вот сейчас затрудняюсь вспомнить разные алгоритмы сортировки. Но как-то за 20+ лет карьеры - ни разу не приходилось их писать. Знание куда-то улетучилось. На практике (немного смешной пример) оказалось гораздо важнее не писать свой алгортим сортировки, а знать, что у SELECT есть атрибут ORDER BY. В общем, все уже украдено для нас. И если мне пригодится это знание раз в 20 лет - ничего страшного, если придется потратить час-два на то, чтобы прочитать снова и освежить.
    
    Понял, что я использовал хештейблы и списки (1-2 связные) тогда, когда программировал на С. А в более высоких языках это знание уже не требуется.
    
    Нужно ли про это знать? Наверное да, но как у Пелевина: "на уровне коллективного бессознательного". На практике, чтоб такие темы от зубов отскакивали - не слишком важно.
    
    Раньше я слышал, что в Древнем Китае когда набирали чиновников - оценивали их умения в стихосложении и прочей бесполезной гуманитарщине. Мне это показалось смешным и абсурдным фактом. А сейчас я понимаю, что да, так и надо. Конкретное техническое знание - либо недорого стоит и оно есть, либо его можно легко получить. Гораздо важнее понять, как человек мыслит, насколько широк кругозор, насколько он уязвим к когнитивным искажениям, насколько развито критическое мышление. Если по этим показателям все ОК (и чел из IT) - скорее всего и в IT он достаточно знает, и если даже где-то есть пробел - то этот пробел компенсируется знаниями в другой теме, которые тоже могут быть полезны.
    
    Вообще, у меня есть сомнения, что Джобс или Гейтс прошли бы собеседования так же блестяще, как их деловые успехи. Да и Торвальдс - хоть и неплохой программист, но любим мы его не за это. Все кто "выше чем программисты" (то есть, гораздо более ценные кадры) - скорее всего или не очень хорошие программисты, или вообще не очень важно, хорошие ли они программисты или нет.
    
    BugM
    17.11.2023 13:44
    #26170878
    Цитата чуть-чуть подредактирована без искажения смысла.
    
    Понял, что я использовал хештейблы тогда, когда программировал на С. А в более высоких языках это знание уже не требуется.
    
    Серьезно? Все пишущие код используют мапы примерно ежедневно. Это и есть тот самый хештейбл. Как можно писать нормальный код не зная наизусть его свойства и не понимая что ты используешь?
    
    xenon
    17.11.2023 13:44
    #26170894
    +3
    Смотрите как:
    
    mydict["key"] = value
    
    Это несложно. Даже человек, который не слышал про хэштейбл легко справится! Это как включать лампочку дома, которая запитана через сеть трансформаторов от АЭС. Не нужно знать ни про постоянный ток, ни про переменный, ни про трансформаторы, ни про сопротивления и тем более не обязательно знать про структуру атома. Просто щелкаешь выключателем и свет загорается.
    
    Я представляю, как работает хештейбл там внутри. Но еще я представляю, как работает 4-тактный ДВС. Оба глубоких знания мне примерно одинаково важны. Лучше знать, чем не знать, конечно. Но я б не сказал, что мне это знание сильно помогает.
    
    mvv-rus
    17.11.2023 13:44
    #26170986
    +2
    Это несложно. Даже человек, который не слышал про хэштейбл легко справится!
    
    Но есть нюанс. Человек, использующий хэш-таблицу, должен знать ее побоччные эффекты: большие избыточные требования к памяти (из-за необходимости избежания большого числа коллизий - когда несколько ключей ведут в одну ячейку таблицы, что ведет к деградации скорости поиска), и сложность определения необходимого размера памяти для постоянно растущего набора данных (хэш-таблицу меньшего размера нельзя просто взять и скопировать в большую: адреса ячеек для имеющихся элементов поменяются, и их надо переразместить, жтио называется рехэштрование). Эта информация мне кажется необходимой в достаточно большом числе практических применений, чтобы ее можно было проигнорировать.
    А вот какие есть и как работают методы избежания коллизий или алгоритм рехэширования или определения порога для него знать в первом приближении не обязательно.
    
    И я, кстати, сейчас пытаюсь выяснить для себя вопрос - может ли техник-программист, - алгоритмам специалльно не обученны, но имеющий под руками хороший, годный каталог алгоритмов (со всеми их свойствами) и их библиотечных реализаций - заменить инженера-разработчика, который алгоритмы должен знать. Подобно тому, как сейчас обычный человек с Гуглом вполне может заменить на прктике известного эрудита Онотоле.
    
    MiraclePtr
    17.11.2023 13:44
    #26171372
    +2
    Эта информация мне кажется необходимой в достаточно большом числе практических применений, чтобы ее можно было проигнорировать.
    
    Ну да. Для этого достаточно знать (прочитать в документации) что такой-то контейнер в библиотеке языка основан на штуке под названием "хеш-таблицы", а потом на википедии или в справочнике прочитать про их плюсы/минусы, сложность операций и границы применения. Значит, как они устроены и работают изнутри, а уж тем более уметь написать их свою реализацию - для их эффективного использования не обязательно, если только мы не ведём речь о каким-то совсем редких и узкоспецифичных случаях.
    
    Это как когда я выпекаю яблочный пирог, мне достаточно знать только общий рецепт, какой сорт яблок хорошо подходит для пирогов, как гасить соду уксусом, и как проверить, запеклось уже тесто или нет. Какие физические процессы и химические реакции происходят во время готовки, как выращивают яблоки, как мелят муку знать для получения хороших пирогов уже не обязательно. И уж тем более не обязательно самому уметь снести яйцо :)
    
    akhmelev
    17.11.2023 13:44
    #26171524
    +3
    Сразу скажу, что это не лично, и не ответ на коммент, а просто мысли вслух.
    
    Потеря время на доказательство бесполезности CS (я не про CS:GO а про Computer Science, хотя и первое не лишнее ))) обычно сильно больше собственно времени на изучение CS. Это феноменально простая инфа. База. Это вовсе не умение "нести яйца", а основа всех последующих абстракций. Пролистали Грокаем алгоритмы или посмотрели курс Кулешова на степике по алгоритмам. Для человека в теме это максимум два вечера и вот дискуссии по сабжу уже не так и нужны.
    
    А так аргументы "не хочу, не надо, не буду, все есть в wiki" чем-то неуловимо напоминают "а зачем мне while... когда на все всегда хватает for...".
    
    Я очень много лет изучал всякое разное, от железа, машинного кода и ассемблера, и заканчивая монструозными жабопитонными технологиями типа jee, или спрингами да джангами. Не использую 99% того, что изучал когда-то. Но сказать, что все это мне это не нужно у меня язык никогда не повернется.
    
    Шеф-повар от кухарки все же должен чем-то отличаться, и там и там пироги, но разница обычно очевидна. Шеф-повар не будет тратить время на википедию по пустякам.
    
    MiraclePtr
    17.11.2023 13:44
    #26171612
    +1
    обычно сильно больше собственно времени на изучение CS
    
    Такие рассуждения попахивают синдромом Даннинга-Крюгера. Тоже ничего личного, так, мысли вслух.
    
    "а зачем мне while... когда на все всегда хватает for...".
    
    Тут скорее "я знаю while, я знаю for, но я не знаю. в какие именно инструкции процессора или виртуальной машины они компилируются, да это мне для решаемых задач и не надо, чтобы использовать их" ;)
    
    Я очень много лет изучал всякое разное, от железа, машинного кода и ассемблера, и заканчивая монструозными жабопитонными технологиями типа jee, или спрингами да джангами.
    
    У меня абсолютно то же самое, и что?
    
    Шеф-повар от кухарки все же должен чем-то отличаться, и там и там пироги, но разница обычно очевидна. Шеф-повар не будет тратить время на википедию по пустякам.
    
    Нужно просто различать топовых шеф-поваров, которые придумывают новые блюда молекулярной кухни для именитых заведений и просто поваров, которые готовят блюда в обычных ресторанах. Работа и задачи у них разные, и у людей как раз вызывает недоумение, когда от вторых требуют навыков первых.
    
    akhmelev
    17.11.2023 13:44
    #26171682
    Да, конечно. В совке были пту техникум вышка и наука - сейчас не о качестве, а о градациях. Это важная идея. Но ведь сейчас действительно смешались в кучу люди-кони, градаций нет, есть стаж. Были бы - не возникало бы это проблемы. Вот и нужны везде шефы, а на проектах задачи кухарки. Се ля ви.
    
    Но ведь если позиция называется software engineer, то как-то надо проверять подготовку (в смысле готовился или не готовился)? Кроме сферических коней (алгосов) и последующих бесед про реальный опыт (технологии) вряд ли кто-то что-то придумает. Ну а раз назвался engineer, то и спрос соответвующий. Это же не местный перекос. Это мировая практика. Все HR одновременно ошибаться не могут.
    
    Наличие релевантного автоматического сортировщика по скилам с признаваемым в индустрии сертификатом - это был бы супербизнес, все мечтают его построить или заполучить. Но по сути это как диплом ВУЗа (не наших увы погибших, а к примеру MIT, или какого-то американского колледжа среднего уровня). А и там и там как раз оно. CS. В любом адекватном вузе планеты.
    
    Есть ли смысл спрашивать ракетные технологии, если человек вышку первого курса не знает и не видел даже? От простого к сложному, от планера к самолету. И так везде. Почему же в IT надо сразу самолет спрашивать? Может же просто нет смысла продолжать разговор.
    
    ЗЫ. Ну и про найм. Топ-поваров, которые придумывают новые блюда молекулярной кухни никто не ищет. Они сами владеют или управляют рестораном.
    
    ЗЫ2. Причем тут синдром Даннинга-Крюгера вообще не понял. Мы же ведь не о джунах сейчас беседуем? Или "ничего личного" - это ложь :D ?
    
    xenon
    17.11.2023 13:44
    #26171882
    +1
    Наличие релевантного автоматического сортировщика по скилам с признаваемым в индустрии сертификатом - это был бы супербизнес, все мечтают его построить или заполучить
    
    Сфера слишком быстро растет. Пока качественно вылижешь классификацию и сертификацих всех Fortran, Cobol и Perl программистов по их знаниям IBM System/360, уже какой-то интернет вылезет, какой-то HTTP, какие-то CORS и какие-то блокчейны (хакеры, куки, кряки).
    
    Да и работодателю это не слишком нужно, потому что программист, нанятый сегодня для VR проекта, через три года будет работать над криптовалютным, а еще через три года - все буду только LLM заниматься.
    
    xenon
    17.11.2023 13:44
    #26171876
    Я очень много лет изучал всякое разное ... Не использую 99% того, что изучал когда-то.
    
    С утверждением, что "лучше знать, чем не знать" - сложно спорить. Конечно, лучше знать. Но правильный вопрос, "Что мне лучше пройти сегодня, разобраться, как работают хештейблы или какую-то другую технологию?" (А может вообще не IT, а расширить кругозор, например, послушать лекцию по микроэкономике - это тоже важно)
    
    Как же выбрать? И тут для меня напрашивается идея из области кеширования. Не обязательно "прогревать кеш" (наш мозг) какими-то данными, которые теоретически в нем могут быть полезными (а могут и не очень). А так же как и с кешем - вот как появится первый запрос, с решением которого мы не можем достаточно хорошо справиться - так, значит, нам и придется эту тему разбирать, в которой у нас есть потребность и нехватка знаний. Учиться программисту нужно постоянно, тут, мне кажется, разногласий нет. Как бы "выбор тем по промаху кеша" часто (не всегда, но часто) выручает.
    
    Ну и мы же говорим на самом деле не про хеш-таблицы (этот пример, за который мы уцепились), а за всю необъятную тему IT и смежных областей (в наше время, хороший IT специалист в России должен даже и политологию немного знать и экономику и даже военное дело, чтобы понимать, когда принять важное IT решение ехать на Верхний Ларс :-) )
    
    akhmelev
    17.11.2023 13:44
    #26171918
    +2
    Ну конечно сидеть и все подряд учить это странно.
    
    Но вот к примеру: вот я такой весь из себя айтишник подписался в телеге на вакансии и че-то мне подошло, и вот я уже иду на собес в Яндекс. Черным по-белому написано, "мы начинаем с алгосов". Зачем же мне экономика и военное дело?
    
    У меня варианты другие: а) мне надо пойти на собес и поразить всех опытом да крутотой или б) все же стоит почитать чего от меня хотят и повторить/изучить это?
    
    По многим комментариям/статьям/дискуссиям заметно, что нередко люди после нескольких лет работы "ловят звезду" и идут а) поражать воображение. А когда их б) "сливают" на простейших задачках становится обидно и мы видим море статей на тему "алгосы не нужны".
    
    Мой поинт в том, что алгосы (без вышки и доказательств, а чисто практически) - это настолько примитившейшая первокурсная легкотня, что такое не знать - это просто "позор какой-то (с)".
    
    Конкретно для в Java алгосы - это Java Core - самая базовая база. Базовее некуда. Коллекции, деревья, хеши и вот это вот все. Как это можно вообще не знать? Правильно. Никак. Незнание таких примитивных вещей - гарантия некомпетентности. Ибо они примитивные.
    
    xenon
    17.11.2023 13:44
    #26171982
    б) "сливают" на простейших задачках становится обидно и мы видим море статей на тему "алгосы не нужны".
    
    Обидно, когда сливают. Но ведь в самом деле - не так уж и нужны. Вот мы (аналогия) ищем шеф-повара в ресторан, и что нам от него нужно? Нужна фантазия и утонченный вкус, чтобы он смешал селедку и малиновое варенье и весь город стоял бы к нам в очередь, чтобы попробовать этот невероятный вкус!
    
    Но разве мы можем проверить фантазию на собеседовании? Это сложно. Можем ли проверить вкус? Это еще сложнее. Зато му можем проверить за сколько времени он может нашинковать лук и как быстро бегает со сковородкой в руке. Работодателю реально важна магия, которую сложно даже сформулировать и невозможно измерить, а на собеседовании у него есть весы и рулетка.
    
    Это проверяется не потому, что это решающий фактор, а потому что это как-то можно проверить, а другое, реально важное - линейкой не замерить.
    
    wataru
    17.11.2023 13:44
    #26172152
    Это проверяется не потому, что это решающий фактор, а потому что это как-то можно проверить, а другое, реально важное - линейкой не замерить.
    
    И тем не менее это, хоть и не решаюший фактор, вполне релвантно. Повар показывает, что он на кухне вообще может сковородку от кастрюли отличить и занает, где у них ручки. И иногда ему, таки, придется именно быстро нашинковать лук. Хоть большую часть времени он будет, скажем, неспешно нарезать капусту.
    
    mvv-rus
    17.11.2023 13:44
    #26172722
    Я тут предложил делать каталоги алгоритмов и их реализаций, в рамках бизнеса сторонних сервисных фирм. Но сам я за это не возьмусь - в бизнес не умею.
    
    mvv-rus
    17.11.2023 13:44
    #26170974
    Все пишущие код используют мапы примерно ежедневно. Это и есть тот самый хештейбл.
    
    "Здесь всё не так однозначно"(с): мне вон @SpiderEkb в одном из комментариев написал, что мап может быть понят по-другому:
    
    В данном случае мап - любой список пар ключ-значение с быстрым поиском по ключу.
    
    Но вообще надо смотреть конкретно контекст: что за средство разработки используется. Возможны в данном контексте вы правы (не уточнял).
    
    SpiderEkb
    17.11.2023 13:44
    #26171224
    Реализация мапа может быть любой. Хеш, деревья, еще бог знает что. Суть в том, что мап по заданному ключу приводит нас к блоку данных с ним связанных. Можете назвать это индексацией.
    
    SpiderEkb
    17.11.2023 13:44
    #26171214
    +1
    оказалось гораздо важнее не писать свой алгортим сортировки, а знать, что у SELECT есть атрибут ORDER BY
    
    Угу-угу. Был случай. Отчет. Там для построения нужен был order by по 5-ти полям из разных таблиц. Работало минуты полторы даже на тестах (на проме кратно больше).
    
    Выкинул order by из запроса, сначала засунул результат выборки в сортирований по ключу список (ключ - суперпозиция тех самых полей), потом его обработал (просто проходом по списку от головы к хвосту). Ускорился в 5-6 раз.
    
    xenon
    17.11.2023 13:44
    #26171952
    "Болевая реакция". очень хороший принцип. Если от неэффективного решения кому-то больно - оно будет оптимизироваться. Если же никому не больно, или болевой сигнал не проходит (клиенты страдают, но руководство не в курсе) - то не будет.
    
    Все "умные" методы, которые призваны улучшить качество кода - все фейлятся так или иначе, а вот болевая реакция - гораздо надежнее.
    
    Она только в защите информации плохо работает. Если в вашей системе есть уязвимость - вас не замучают шквалом звонков, она не будет болеть. Программисты (даже подозревающие, что там может быть проблема) - будут решать другие мелкие маловажные задачи, потому что те задачи болят, а эта нет.
  1. sshikov
    17.11.2023 13:44
    #26169902
    +3
    Однако, примерно 98% программистов — не создают технологии или движки. О
    
    Ну давайте уж будем честными - такая разница конечно есть, тут вы правы. Но про 98% это вы же с потока взяли, правда?
    
    Потому что на практике вот это неумение изобретать алгоритмы сводится например к тому, что "инженер" в цикле на 1000 повторений столько же раз ищет элемент в массиве перебором, вместо того, чтобы один раз построить вместо массива хеш мап, и искать в нем за O(1). Ну т.е. к нему такие требования не предъявили - и он применяет единственный алгоритм, который знает. Не важно, плох он или хорош. Если хорош - повезло. Ну разве это дело?
    
    stackjava
    17.11.2023 13:44
    #26170212
    -2
    А если у вас уже массив из 1000 элементов и надо пройтись пару раз... И вдруг решили все переложить в мапу... Оптимизировать On на O1...
    
    Если человек не видет элементарного это одно, а когда он не может решить 2 задачи с литкода за час уровня медиум...
    
    То хз кто чудила... Может собеседующий?
    
    wataru
    17.11.2023 13:44
    #26170278
    Если человек может решшить 2 задачи с литкода за час уровня медиум, то он точно понимает, в каком случае имеет смысл перекладывать массив в мапу, а в каком случае - нет.
    
    stackjava
    17.11.2023 13:44
    #26170940
    Это поймет и человек без литкода, который знает что такое мапа и массив.
    
    wataru
    17.11.2023 13:44
    #26171522
    +2
    Ну, если человек действительно знает, что такое мапа и массив, и может писать код как-то кроме случайного изменения исходника, пока оно не заработает, то эти 2 задачи с литкода он легко сделает.
    
    faiwer
    17.11.2023 13:44
    #26170374
    +1
    А если у вас уже массив из 1000 элементов и надо пройтись пару раз
    
    По суть это часть вопроса: понимать применимость того или иного инструмента на практике, исходя из обстоятельств. Для этого требуется примерное понимание того, как оно работает.
    
    stackjava
    17.11.2023 13:44
    #26170942
    Да.
    
    Достаточно понимания как работает.
    
    А не шпреханье алгоритмов по ночам.
    
    faiwer
    17.11.2023 13:44
    #26172548
    А не шпреханье алгоритмов по ночам.
    
    Дык, контор, которые требуют хитрых алгоритмов, раз два и обчёлся. Большинству нужен какой-нибудь примитив, уровня объединения двух коллекций с группировкой. Или пробежаться по дереву в глубину и что-то найти. Ну и т.д.. Распарсить какую-нибудь строку по заданному формату. Какой-нибудь детский сад. Никто (ну почти) ведь не требует от вас эхо-корасиков.
  1. wataru
    17.11.2023 13:44
    #26169910
    Это ниши создания технологий / фреймворков / СУБД / высоконагруженных библиотек / языков программирования.
    
    А так же фаанги, где далеко не только формочки шлепают. Там тупо много данных, которые надо быстро обрабатывать. А разработчкики подвижны, поэтому нельзя нанимать отдельно алгоритмистов и кодеров. Плюс в том же яндексе и технологии с фреймворками создают, и высоконагруженныее библиотеки, и даже языки программирования.
    
    Кстати, поэтому в Фаангах еще и не спрашивают никакие популярные фреймворки - это бесполезно, потому что там везде свои самописные фреймворки, часто появившиеся на годы раньше публичных аналогов.
1. VladimirFarshatov
  17.11.2023 13:44
  #26169782
  +8
  Было дело, видел и такое. Продает сосед яхту, приходит покупатель, осматривает первым делом каюту, нравится, осматривается яхту внимательнее и произносит:
  
  -" А вот это что за палка торчит?" - "м.м.м Мачта" - "Её спилить можно?" -"м.м.м ну да"
  
  -"А вот это что внизу?" -"Киль, хороший - акулий плавник 600кг" -"а его убрать можно?" -"Ну .. если мачту спиливать, то да"
  
  -"А где тут мотор?"
  
  -"Слышь, мужик: топай отсюдова. Яхта не продается."
  
  :)
1. TimsTims
  17.11.2023 13:44
  #26171858
  +1
  Представьте себе, вы приходите в яхт-клуб и говорите: паруса не нужны, все 100 лет уже на дизеле ездят. Представляете, как на вас посмотрят?
  
  Глобально, если человек в конкретном месте будет прав, то должно быть пофиг как на него посмотрят. Представьте, что у нас не яхт-клуб, а конюшня 100 лет назад, и туда заходит Генри Форд. Говорит - лошади не нужны, все будут ездить на ДВС. Представьте, как на него посмотрели?)
  
  "Правда" она такая... Не постоянная. Вчера было нормой - сегодня может быть не актуальной. Раньше для того, чтобы писать код ты должен был быть хорош в математику, и считать каждый бит, выдумывать хаки процессора итд. А сейчас чтобы принести пользу, у тебя репозиторий npm в несколько гигабайт, и ты даже не знаешь что там. Если бы такое сказать нашим дедам - как бы они на нас посмотрели? А сейчас? Its fine!

konst90
17.11.2023 13:44
#26169578
+16
Очень спорно. Приведу пример из практики.

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

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

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

То есть, даже если ты делаешь из стандартных вроде бы компонентов (или делаешь их сам) - без глубокого понимания механики различных процессов при попытке сделать лучше можно влететь.
1. vkni
  17.11.2023 13:44
  #26169818
  +5
  Да. Инженер — это же творческая профессия, не конвейер. Наивно рассчитывать, что все задачи, которые ему поставят, будут укладываться в узкий коридор. Наверняка появится какая-то повышенной сложности, чуть выходящая за рамки обычных обязанностей.
  
  Кстати, обычно такие задачи решают, пользуясь запасом знаний, а потом долго вспоминают о них с любовью.
1. cijic
  17.11.2023 13:44
  #26171594
  -1
  И вот у клиента вылезает проблема - крепеж (они его делают сами) лопается.
  
  И как это относится к ВАШЕЙ задаче? Это их задача. И, как я понял, они же и нашли проблему, и решили.
  
  стандартных вроде бы
  
  Раз менялся техпроцесс, значит уже нестандарные.
1. haqreu
  17.11.2023 13:44
  #26176004
  Я совсем не прочнист, но слово "достаточный" меня заинтриговало. Достаточный или требуемый класс крепежа?
  1. konst90
    17.11.2023 13:44
    #26176386
    В подавляющем большинстве случаев - достаточный. То есть замена крепежа низкого класса на высокий не создаёт никаких проблем, кроме роста цены.
    
    Оно и в данном случае проблем бы не вызвало, если бы крепеж был не самодельный, а покупной. Но производство не учло, что высокая твердость (твердость и прочность - разные вещи, хотя и коррелируют) в данном случае - плохо, и задрало её так высоко, насколько смогло. В результате прочность получилась выше чем нужно для данного класса - процентов на 15, но шпилька стала хрупкой (обратная сторона твердости) и при небольшом изгибе лопнула. А без изгиба у них этот крепеж прошел. А когда снизили твердость - лопаться перестало, хотя прочность упала на те самые 15%, вернувшись к нормативной.
    
    haqreu
    17.11.2023 13:44
    #26176720
    Да про хрупкость пластилина я понимаю, мне хочется понять, кто именно виноват в производственной заминке. Вот вы сказали, что нужно взять крепёж как минимум 8.8 (или какие параметры задаются?), а я взял 12.9 и у меня сломалась коробочка. И тут я начинаю чесать голову и терять деньги на простое.
    
    В итоге: виноват ли прочнист, неточно (неполно) задавший параметры крепежа, или сборщик, неверно истолковавший указания?
    
    konst90
    17.11.2023 13:44
    #26176874
    В данном случае ребята не взяли готовый, а сами изготовили крепеж. И изготовили его максимально прочным - так, что он по твердости вылез за допускаемые для этого крепежа. То есть ошибка на стороне производства.
    
    Проблема именно в том, что они хотели как лучше, посчитав, что прочность ценой твердости - это хорошо. А оказалось в данном случае плохо.
    
    inkelyad
    17.11.2023 13:44
    #26177096
    +1
    Я, возможно, плохо читаю ветку, но так и не понял, было ли им (производству) где-то написано, что 'допускаемые' в данном случае - еще и сверху ограничивается, т.е. что прочнее делать нельзя?
    
    Или было ли написано, что 'хрупкость крепежа не должна превышать <в чем там оно меряется>'
    
    Или считается, что они сами должны были догадаться, что поднять прочность и увеличить хрупкость на 2% - это еще можно, а на 15% - это уже вылезаем за пределы допустимого по хрупкости?
    
    haqreu
    17.11.2023 13:44
    #26177530
    Именно об этом я и спрашиваю, спасибо. Были ли все характеристики крепежа указаны снизу и сверху, или там была часть неявно подразумеваемого?

miksir
17.11.2023 13:44
#26169756
+8
Как высшее образование учит вас работать с информацией, так алгоритмические задачи учат вас работать с задачами. Не даром на собеседованиях так много уделяют внимания тому, как вы работаете с условиями задачи и как прокладываете путь решения.

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

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

vkni
17.11.2023 13:44
#26169814
+7
Кмк, тут просто популярное заблуждение насчёт знаний, умений и работы. Из обще-оптимизационных соображений многим кажется, что знать и уметь нужно только то, что требуется для выполнения непосредственных обязанностей. Но нет, инженер — это не робот, периодически ему приходится решать задачи «повышенной сложности», которые выходят за пределы рутины.

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

Поэтому, увы, знания и умения должны покрывать больше, чем требуется для непосредственной работы. Как, знаете, доклад готовите — всегда должна быть область вокруг, в которой вы компетентны, но которую даже не планируете рассказывать. Для вопросов — чтобы не сесть в лужу на первом же, отходящем чуть в сторону.
1. gatoazul
  17.11.2023 13:44
  #26170656
  +6
  Почему надо быть знакомым именно с алгоритмами, а не, допустим, с законодательством? Или с основами пользовательского интерфейса? Или с серьезной математикой за пределами информатики? Повышенная сложность может оказаться где угодно.
  1. vkni
    17.11.2023 13:44
    #26170708
    +2
    Всё надо, вы правы. Нужно, чтобы вокруг задач, которые вы решаете, была область, в которой вы что-то понимаете.
  1. wataru
    17.11.2023 13:44
    #26171534
    Почему надо быть знакомым именно с алгоритмами
    
    Потому что алгоритм - это "набор инструкций, описывающих порядок действий исполнителя для решения определённой задачи". Программист в своей работе составляет именно этот набор инструкций на своем языке программирования, чтобы компьютер решал определенную задачу.
    
    Программирование по сути - написание алгоритмов абсолютно все время. Да, часто это совсем тривиальные алгоритмы. Но все программисты сталкиваются с алгоритмами. Не все сталкиваются с законодательством или дизайном интерфейса. На связанные с этим позиции в тех же фаангах проводят дополнительные интервью.

wataru
17.11.2023 13:44
#26169834
+6
Смотря какие алгоритмы. Знание какого-нибудь Ахо-Корасика - действительно не важно. Это редкая и нишевая вещь. Если знать, что вообще алгоритмы бывают, его можно и нагуглить, если он понадобится. Их на интервью и не спрашивают. По крайней мере в гуглах и прочих фаангах. Каким карго-культом страдают условные рога и копыта - я не в курсе.

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

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

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

Как при проверке водопроводчика вы можете попросить его собрать трубы, не подключенные ни к чему, просто на полу в большой просторной, хорошо освещенной комнате, что никогда в его практике скорее всего не встретится.
1. dom1n1k
  17.11.2023 13:44
  #26170106
  +5
  Я считаю, что нужно хотя бы понаслышке знать основные классические алгоритмы и структуры данных. Понаслышке это значит: что такой алгоритм вообще есть, для каких задач он применяется, в чем его основная идея и принцип работы, какие есть ограничения. Мелкие детали реализации и код наизусть знать не надо, для этого есть справочники.
  
  Но и вот в это — "вот когда понадобится, тогда и нагуглю, а до того оно мне не нужно" — я тоже не верю. Трудно нагуглить что-то осмысленное, когда даже приблизительно не знаешь куда копать. А если даже повезло и нагуглил, то как понять, что это то самое, что мне подойдёт лучше всего?
  
  Я не так давно копал новую для себя область. Ну думаю, на Ютубе туториалов много — разберусь. Смотрю один, второй, третий... В целом всё как будто понятно, но когда пытаешься погрузиться в нюансы и уйти в сторону от учебника, то вопросов всплывает очень много. Начинаешь искать ответы — поиск выдает какую-то фигню. Помыкавшись, я задал вопросы знающему человеку с академическим образованием в нужной области. Так мне за несколько минут разложили на пальцах всё то, что я не мог собрать в кучу несколько дней. Во-первых, я понял принцип, а во-вторых, я узнал несколько недостающих терминов — и о чудо, поиск по ним стал выдавать осмысленные результаты.
1. baguwka
  17.11.2023 13:44
  #26176682
  +1
  Знание алгоритмов которые вы перечислили - важны.
  Но умение имплементировать его в режиме лайв-кодинга ничего не говорит о специалисте.
  
  Я например так не умею и лайвкодинг всегда избегаю, так как рассматриваю это скорее как невежество. Литкод/хакерранк - красные флаги. Это значит, что компания скорее всего забила на процесс подбора кандидатов и решила выстроить no-brain фильтр.
  
  Все люди мыслят и думают по разному. Я не всегда могу за один присест решить какую-либо задачу, обычно они решаются в бэкграунде при отвлечении на кофе или типа того. В режиме лайв-кодинга просто невозможно это сделать.
1. tteehhbb
  17.11.2023 13:44
  #26176684
  +1
  Знание алгоритмов которые вы перечислили - важны.
  
  Но умение имплементировать его в режиме лайв-кодинга ничего не говорит о специалисте.
  
  Я например так не умею и лайвкодинг всегда избегаю, литкод/хакерранк - красные флаги. Для меня это значит, что компания скорее всего забила на процесс подбора кандидатов и решила выстроить no-brain фильтр.
  
  Все люди мыслят и думают по разному. Я не всегда могу за один присест решить какую-либо задачу, обычно они решаются в бэкграунде при отвлечении на кофе или типа того. В режиме лайв-кодинга просто невозможно это сделать.
  
  Когда я нанимаю людей мне в первую очередь важно знать какой опыт у человека, какие системы он проектировал, как выбирал технологии и почему. Мне абсолютно не интересно как он будет вращать бинарное дерево.

vadimr
17.11.2023 13:44
#26169860
+2
Когда вы берёте готовое решение, то неплохо бы понимать, во-первых, исходя из каких допущений оно работает, а во-вторых, насколько его при необходимости можно улучшить руками. Это предполагает определённую глубину познаний.

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

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

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

Если какой‑нибудь условный интернет‑магазин, написанный под конкретного заказчика, будет в полтора раза медленнее (или потреблять в полтора раза больше памяти) от теоретически/технологически‑достижимого предела — этого никто не заметит.

Обычно в современной практике программирования разница с достижимым при разумных усилиях пределом составляет сотни тысяч раз. Весь херак-херак-и-в-продакшен код очень неэффективен. Нужно ли ускорять интернет-магазин в сто тысяч раз – другой вопрос.
1. SpiderEkb
  17.11.2023 13:44
  #26169964
  +2
  Когда вы берёте готовое решение, то неплохо бы понимать, во-первых, исходя из каких допущений оно работает, а во-вторых, насколько его при необходимости можно улучшить руками. Это предполагает определённую глубину познаний.
  
  И насколько данное решение будет эффективным в вашем конкретном случае.
  
  Тех же сортировок много разных. И каждая в одном случае будет лучше других, а другом хуже. Ваш случай какой?
  
  Тех же контейнеров тоже много. И все разные. Какой для вас именно тут наиболее эффективен?
  
  Как пример - кеширование чего-то в памяти. Одно дело справочник - один раз прочитал, потом 100500 раз пользуешься без изменений. Тут обычный сортированный массив сгодится - на старте заполнил, отсортировал, а потом быстрый двоичный поиск по нему.
  
  Другое дело, когда что-то агрегируешь - надо по ключу искать что-то, если нашел - что-то делаем с данными, не нашел - добавляем. Тут уже массив не пройдет - много времени на сортировке после каждого добавления потеряешь. Тут лучше какой-нибудь список сортированный взять - там поиск медленней чем двоичный по сортированному массиву, но зато нет отдельной сортировки - новый элемент сразу "по месту" вставляется. В сумме будет быстрее.
  
  Но для этого надо знать и понимать какой контейнер как работает. И в каких условиях что лучше будет. А не просто схватить первое что под руку попало.

Asker1987
17.11.2023 13:44
#26169922
+5
Когда ты не владеешь инструментом и не знаешь, что он может дать и вообще никогда в жизни не видел, ты даже не можешь осмыслить, как он полезен и удобен, ведь никогда не пробовал и не сравнивал.

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

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

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

ЗЫ ненависть к олимпиадникам так сильно растёт, что уже много лет не упоминаю об этом в резюме и где бы то ни было. Уж поверьте никто не хочет видеть олимпиадников, даже интервьюеры. Они задают примитивные вопросы по алгоритмам для формальности. Но и это является непростительно высоким порогом для подавляющего большинства джунов.

Минусуйте????

kovriga25
17.11.2023 13:44
#26169982
+11
Инженер достал из стола свою таблицу объёмов красных резиновых мячей...
Физику, математику и инженеру дали задание — найти объём красного резинового мячика. Физик погрузил мяч в стакан с водой и измерил объём вытесненной жидкости. Математик измерил диаметр мяча и рассчитал тройной интеграл. Инженер достал из стола свою «Таблицу объёмов красных резиновых мячей» и нашёл нужное значение.

MANAB
17.11.2023 13:44
#26170288
+2
Я думаю нелюбовь к алгоритмам как раз проистекает из необходимости их выучивать, а не из интереса. Когда интересно работать и появляются задачи, где приходится оптимизировать - изучаешь эти алгоритмы с удовольствием и с другими также обсуждаешь. Но когда в реальности еще не известно, встретишься ли, а требуют знать - бесит и вызывает много сопротивления.
1. wataru
  17.11.2023 13:44
  #26170340
  +1
  Если не иметь какую-то минимальную базу, достаточную, чтобы решать вот такие задачи, то у кодера даже мысли не возникает, что где-то проходится оптимизировать и надо какие-то алгоритмы изучать. Вы, когда два числа складываете, просто пишете a+b и даже не задумываетесь над тем, а надо ли тут что-то соптимизировать. Так и "инженеры, создающие решения" - впендюрят n-квадрат на ровном месте и все.
  1. MANAB
    17.11.2023 13:44
    #26170370
    +1
    Если кого-то не устраивает производительность (пользователей, продуктоунера, себя, и т.д.) то рано или поздно придется сесть разбираться, а почему это медленно работает и как сделать быстрее. И так или иначе к алгоритмам придешь. Или даже тот же тимлид или коллега в код ревью подскажет, что тут может быть не очень. Может и не случиться конечно, но по мне вероятность сильно меньше, чем то, что столкнешься.
    
    wataru
    17.11.2023 13:44
    #26170406
    Ну вот пришли: Счет на сервера почти превышает доход. Или пользователи пишут гневные отзывы и уходят к конкурентам. Отпрофилировали - два бутылочных горлышка нашли, но все-еще торомзит примерно все - 100500 разных функций, все вроде нужные. Какой алгоритм вам нужен?
    
    Или даже тот же тимлид или коллега в код ревью подскажет, что тут может быть не очень
    
    Т.е. алгоритмическими интервью, по-вашему, надо гонять, но только некоторых разработчиков и тимлида? Которые будут ревьювить вообще весь код?
    
    MANAB
    17.11.2023 13:44
    #26170466
    Я ни слова не сказал, надо или не надо гонять алгоритмическими интервью. Я сказал, откуда нелюбовь к ним, по моему мнению.
    
    wataru
    17.11.2023 13:44
    #26170492
    Нет, вы сказали "Но когда в реальности еще не известно, встретишься ли, а требуют знать - бесит и вызывает много сопротивления." Это значит, что вы утверждаете, что спрашивают то, что может и не понадобится. И раз это бесит, то наверно вероятность этого "не понадобится" - значительная. А это можно интерпретировать так, что вы против таких интервью. Ну мало кто считает, что спрашивать что-то редко нужное - это хорошо.
    
    MANAB
    17.11.2023 13:44
    #26171002
    Это ваши фантазии, что я так считаю. Вот вам пример: когда приходится заучивать таблицу умножения - тоже злит, ведь хочется играть пойти.
    
    Не все, что бесит, значит против. И опять же приводил пример, когда это не бесит. Просто считаю, некоторые компании порой неадекватно упираются в алгоритмы. Но как и умножение, они нужны и процесс изучения может быть интересным.
    
    dom1n1k
    17.11.2023 13:44
    #26170702
    +13
    Тут проблема в том, что многие люди почему-то воспринимают оптимизацию как бинарный рубильник - она либо есть, либо нет. Либо простое прямолинейное решение, либо какая-то олимпиадно-яйцеголовая заумь. Но на самом деле там большой спектр полутонов.
    
    И зачастую базовый алгоритмический кругозор позволяет просто не делать заведомо тупых и тормозных решений. Не лезем ни в какие сложные дебри, просто делаем нормально. В многих случаях этого правда достаточно.
    
    Другой популярный миф в головах — если мы столкнемся с тормозами, мы посмотрим профайлер, быстренько найдем бутылочное горлышко и пофиксим его. Так тоже бывает, конечно. Но чаще в реальности, если упомянутого выше кругозора нет, со временем тормозить начинает примерно всё. Нет одного главного бутылочного горлышка — есть много мелких.
    
    BugM
    17.11.2023 13:44
    #26170736
    +3
    Профайлер переоценен на самом деле. Он поможет выжать производительность когда у вас уже оптимальные алгоритмы. Но если алгоритмы странные, то вы будете выжимать еще 10% из квадрата. И толку?
    
    Если надо выжать еще больше, то профайлер снова бесполезен. Надо понимать как работает железо. Все эти предсказатели, кеш линии и все такое.
    
    И в итоге профайлер нужен где-то после оптимизации алгоритмов и до оптимизации под железо. Применение у профайлера есть, но мало кто его применяет верно.
    
    dom1n1k
    17.11.2023 13:44
    #26170762
    +2
    Ну, я употребляю слово профайлер в широком смысле, не обязательно который под железо.
    Flamegraph в браузере — это ведь тоже профайлер. Идея в том, что мы посмотрим на эти графики, увидим функцию с самым длинным прямоугольником и дальше уже будем с ней разбираться, то ли там O(n^3), то ли другие причины.
    
    SpiderEkb
    17.11.2023 13:44
    #26171242
    Под профайлером можно понимать некий инструмент исследования производительности. У нас есть PEX - Performance EXplorer. Который покажет по стеку что где сколько выполняется, тратит ресурсов, покажет времена подготовки и выполнения встроенных SQL запросов, интенсивность обращения к БД, лишние переоткрытия файлов и еще много чего. Там сразу все "бутылочные горлышки" как на ладони.
    
    VADemon
    17.11.2023 13:44
    #26172082
    Даже в описанном вами случае пропускается главная причина, от которой вы даже с десятью профайлерами будете заниматься микрооптимизацией - плохая архитектура. На которую ни алгоритмы, не железо не уложить.
    
    Для себя подобрал пример: однопоточное против многопоточного алгоритма/приложения. Если понаписать однопоточку, потом без поломки работы алгоритма может не получиться его распараллелить, нежели не разрабатывать сразу с прицелом на многопоточность.
  1. BugM
    17.11.2023 13:44
    #26170496
    +1
    чтобы решать вот такие задачи
    
    Ее на доске за полчаса решит дай бог один из 50 кандидатов с хорошим резюме на мидла-сеньора-архитектора-лида. Она на самом деле не так чтобы совсем простая. Хотя формулировка проще некуда.
    
    wataru
    17.11.2023 13:44
    #26170536
    Во-первых, на доске уже давно не спрашивают, а дают ноутбуки, или вообще, с пандемией уже 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 - не крайний случай.
    
    BugM
    17.11.2023 13:44
    #26170556
    Я доску даю. Так даже удобнее как мне кажется. Кандидату не надо утыкаться в ноут, а мне не надо подглядывать из-за плеча. Или каждому в свой ноут смотреть не надо. Это даже еще хуже. Все таки поговорить пришли, а не в ноуты смотреть. И от удаленных кандидатов я отказываюсь. Но это лично мое. Кому не подходит - ну и ладно.
    
    Код я конечно написал до того как комментарий писать. Со второго раза верно вышло. Переполнение вниз забыл. На основе этого и оцениваю сколько кандидатов такое напишет за полчасика в стрессе. Если кандидатам заранее сказать что литкод будет, то шанс написания повышается с 1 из 50 до 1 из 10.
    
    wataru
    17.11.2023 13:44
    #26171544
    Кандидату не надо утыкаться в ноут, а мне не надо подглядывать из-за плеча
    
    Ну, у нас там не любимая IDE кандидата, а онлайн редактор, который я на своем ноутбуке всегда вижу. Главная проблема доски - что там код редактировать неудобно, да и сейчас многие вообще буквы писать разучились.
    
    Переполнение вниз забыл.
    
    Ну для этого интервьюверы дают подсказки. За пол часа-то можно это исправить. И использование подсказок - это не черная метка.
    
    Если кандидатам заранее сказать что литкод будет
    
    Ну в тех же фаангах вообще даже ссылки на книги дают, что почитать можно для подготовки к алгоритмическим интервью.
    
    Edit: И вообще, даже если вы забыли переполнение вниз, вы возможно получите максимальный бал за код, но плохо в графе "тестирует код". Если у вас такой косяк не во всех 3-5 интервью, то вас могут и нанять.
    
    BugM
    17.11.2023 13:44
    #26172056
    Меня то наймут. Точнее уже давно наняли. Я сам такие интервью провожу в довольно больших количествах и вижу кто приходит с какими резюме и что они на практике могут написать. Сложность определяю написав сам, а нормирую по уровню того что могут или не могут сделать кандидаты по опыту собеседований.
    
    Моя ошибка это вообще не проблема. Исправляется реально одним примером данных на которых не будет работать. Кандидат написавший так же прошел без проблем.
    
    Главная проблема доски - что там код редактировать неудобно, да и сейчас многие вообще буквы писать разучились.
    
    Губка нормально стирает. Доска большая. Даже написать рядом новые 10-20 строк и потом стереть предыдущие не проблема.
    
    Буковки ну как-то написать можно. Не красоту почерка оцениваем. Зато на доске можно квадратики систем дизайна порисовать. Вдруг кандидат достаточно хорош для этого?
    
    Ну, у нас там не любимая IDE кандидата, а онлайн редактор, который я на своем ноутбуке всегда вижу.
    
    И все смотрят в свои ноуты, а не друг на друга.
    
    wataru
    17.11.2023 13:44
    #26172132
    +1
    Буковки ну как-то написать можно. Не красоту почерка оцениваем. Зато на доске можно квадратики систем дизайна порисовать.
    
    Главное неудобство - невозможность вставлять новые строки и необходимость стирать всю строку при малейшем в ней измененнии. Кандидаты много времени тратят на стрирание и еще больше нервничают. А систем дизайн - это отдельное интервью. И там, да, доска удобнее будет.
    
    И все смотрят в свои ноуты, а не друг на друга.
    
    А в вашем случае тогда - все смотрят на доску, а не друг на друга?
    
    BugM
    17.11.2023 13:44
    #26172194
    Главное неудобство - невозможность вставлять новые строки и необходимость стирать всю строку при малейшем в ней измененнии. Кандидаты много времени тратят на стрирание и еще больше нервничают.
    
    Я это меняю на более простые задачки. Вроде смерджить Н отсортированных массивов. Точно такую же найти не могу. Между этой и этой. Тут и декомпозиция и продолжение о чем поговорить. И код простейший. И специальных знаний не нужно.
    
    Когда на доске заставляют писать огроменные штуки на много десятков строк это плохо. Я против, но ничего сделать не могу. Регулярно вижу как валятся на таком. Валятся именно из-за неудобства доски для написания связного кода больше 10-20 строк.
    
    А в вашем случае тогда - все смотрят на доску, а не друг на друга?
    
    Да, и так лучше как мне кажется. В целом не только мне. Я спрашивал вокруг.
    
    wataru
    17.11.2023 13:44
    #26172300
    Все еще не понимаю принципиальную разницу между смотрением в ноутбуки и на доску.
    
    faiwer
    17.11.2023 13:44
    #26172570
    +2
    Я доску даю. Так даже удобнее как мне кажется.
    
    Проходил собеседования и перед доской, и онлайн по зуму в любимой IDE. Мои ощущения: доску сжечь напалмом. Это разновидность пытки.
    
    vkni
    17.11.2023 13:44
    #26173740
    А на каком языке вы писали?
    
    faiwer
    17.11.2023 13:44
    #26174514
    JS
    
    vkni
    17.11.2023 13:44
    #26174894
    У меня просто есть теория, что на всех алгол-родственных это пытка. А вот на Хаскеле я вполне себе писал на доске для себя. Правда это был не абсолютно точный Хаскель, а псевдокод, напоминающий Хаскель.
  1. mvv-rus
    17.11.2023 13:44
    #26170546
    +1
    Если не иметь какую-то минимальную базу, достаточную, чтобы решать вот такие задачи,
    
    Вот ни хрена эта задача не на минимальную базу. Если бы ограничение по диапазону было -10^9..10^9 (а лучше 0..10^9), то тогда - на минимальную: разбить на цифры ( можно тупо - на 10^8 частное - первая цифра, остаток 0 поделить так же на 10^7 и т.д., но можно и немного упростить пойти с последней циры как остатка от деления на 10, затем остаток опять поделить на 10 - частное будет предпоследней цифрой и т.д.) а потом собрать из этих чисел число путем умножения в обратном порядке на степени 10 (опять-таки, можно тупо - унмножать на соответствующие степени 10, можно оптимизировать, взяв новую старшую цифру как результат и умножая последовательно на 10 и добавляя соответствующую цифру). Это все IMHO элементарно и что-то мне сомнительно, что есть технари, которые до этого не додумаются даже на собесе.
    
    А вот аккуратно проверить граничные условия на соответствие диапазону Int32, не имея в запасе дополнительных разрядов - это уже не совсем тривиально, на собесе можно запросто что-то уронить. Поэтому на собесе конкретно такая задача - это проверка натасканности, а не сообразительности.
    
    впендюрят n-квадрат на ровном месте и все
    
    ... и во многих случаях этот квадрат никому не помешает. Особенно, если знать, что число n будет заведомо небольшим. Я сам так делал, например когда надо было в таблице филиалов, меняющейся раз в несколько месяцев, т.е. - фактически при запуске программы-сервиса на Windows, и в которой даже по самым смелым ожиданиям вряд ли было бы больше сотни записей: читал конфигурацию этих самых филиалов, простыми вставками запихивал ее отсортированную в массив один раз при запуске, а потом сколько надо раз, столько надо искал бинарным поиском (который тоже был не столь частым, чтобы для него хэш-таблицу делать). К сожалению, в те давныие времена подходящей либы не было: это была древняя Delphi, и пишучи этот код, я тогда в течение целого дня люто завидовал плюсовикам с их STL (увы, по разным причинам на плюсах это было делать нельзя).
    
    Но таки да, согласен: техник программист для успешной работы должен иметь под руками каталог алгоритмов.
    
    wataru
    17.11.2023 13:44
    #26171598
    А вот аккуратно проверить граничные условия на соответствие диапазону Int32, не имея в запасе дополнительных разрядов - это уже не совсем тривиально
    
    Да ладно! Вот я ниже привел решение. Но, допустим, я олимпиадник-алгоритмист, который знает, как работает деление по модулю с отрицательными числами, помню со школы схему Горнера (название пришлось, правда, гуглить) и способен заметить, что функция 10x+d монотонно возрастает. Но даже без этого всего любой технарь способен проверить на переполнение, например, сравнив полученные цифры числа с массивом {2,1,4,7,4,8,3,6,4,7} до вычисления числа в int. Ну или сравнить со строкой. А отрицательные числа можно решить, развернув цифры абсолютного значения и вернуть минус ответ (правда, возникает один крайний случай с числом -2^31, которое по модулю не влезает в int. Но даже только забыв этот случай вы интервью не завалите).
    
    faiwer
    17.11.2023 13:44
    #26172584
    +1
    Действительно плохой выбор задачи. Много нюансов, которые морочат голову, и почти ничего не скажут вам про кандидата.
    
    wataru
    17.11.2023 13:44
    #26172598
    Это был лишь как пример сложности. Естественно, сами задачки с литкода обычно не даются. Я вообще спрашиваю то, что самому приходилось коммитить в прод, правда немного упрощенное и абстрагированное. Но редко когда можно какую-то часть вот так выделить.
    
    mvv-rus
    17.11.2023 13:44
    #26172756
    Я писал прежде всего о подвохе в задаче: она называется "Перевернуть число", а в реальности оказывается, что, внезапно, надо ещё и проверять, что не будет переполнения. Эта внезапность в условиях собеса может сыграть злую шутку, на что я и указал - собсвтенно, комментарий был именно про это. И играет: кто-то, к примеру, забыл коррект но проверить для отрицательных чисел.
    
    А как сделать эту проверку - это я уже начал думать позже, после нажатия кнопки Отправить. Только вот никакой монотонно возрастающей функции у меня в голове не появилось: сначала - проверка по цифрам (не понравилось), потом - аналог проверки в вашем коде, но только на 10-й цифре - в других местах переполнение возникнуть не может. На всё это ушло ещё где-то минут пять, так что я потом уверенно ответил, что на собесе я бы за полчаса явно решил (учитывая, что алгоритм переворачивания вообще тривиален, там думать-то особо негде, не говоря уж про зубрить).
    
    PS И я рад, что в Гугле мелкие ошибки на тесте прощают. Но, увы, так не везде.
    
    wataru
    17.11.2023 13:44
    #26172796
    Это не подвох в задаче. Оно дано прямо в условии. Да, эту задачу можно усложнить, не говоря этого, тогда это будет подводным камнем. Но тогда и проверку переполнения можно разрешить в int64 делать, а вот это ограничение на 32 бита оставить на дополнительный вопрос.
    
    сначала - проверка по цифрам (не понравилось)
    
    Вполне рабочий вариант.
    
    mvv-rus
    17.11.2023 13:44
    #26172808
    +1
    Это не подвох в задаче. Оно дано прямо в условии.
    
    Правильно, подвох - в условии. Именно это я и имел в виду, я условие от задачи не отделяю. Да и спрятать его больше негде было.
    
    Вполне рабочий вариант.
    
    Мне не понравилось, что нарушается мнемоническое правило "не использовать магичские числа" (оно даже не из опыта, AFAIK теперь этому даже студентов учат): там возникают магические числа (цифры), которые я, к тому же, наизусть не помню. Потому стал думать дальше, благо ничто меня не подгоняло.
    
    wataru
    17.11.2023 13:44
    #26172866
    Правильно, подвох - в условии.
    
    Нет, если вам прямо сказано об этом условии, то это никакой не подвох, который можно не заметить, как какой-то крайний случай. Подвох - это если надо как-то по иному интерпретировать условие или догадаться самому о чем-то.
    
    что нарушается мнемоническое правило "не использовать магичские числа"
    
    В моем решении тоже используется "магическое число": INT_MAX. Если константный массив/строку правильно обозвать, то код будет вполне отличный. Так-то там еще и "магическое число" 10 используется во всех решениях.
    
    к тому же, наизусть не помню.
    
    На интервью достаточно сказать, что "вот тут у нас массив с цифрами 2^31". Не надо эти цифры даже воспроизводить. Это же можно загуглить или подсчитать в калькуляторе за 2 секунды. Точно так же на интервью прощается незнание наизусть параметров стандартных функций, да и даже их имена. Я сам, когда интервью проходил (успешно), забыл, что там за lower_bound и upper_bound есть в stl - что конкретно они возвращают - больше-равное число или большее. Просто сказал интервьюверу, что какой-то такой метод есть. Вот допустим он возвращает самое левое строго большее число. Описал это в комментарии и все остались довольны. И сам на интервью к этому никогда не придираюсь.
    
    mvv-rus
    17.11.2023 13:44
    #26173100
    +1
    Нет, если вам прямо сказано об этом условии
    
    Согласитесь, что в названии подвох точно есть.
    
    В моем решении тоже используется "магическое число": INT_MAX
    
    Это не число - это идентификатор. На идентификаторы мнемоническое правило не распространяется.
    
    На интервью достаточно сказать, что "вот тут у нас массив с цифрами 2^31". Не надо эти цифры даже воспроизводить.
    
    Ещё раз респект Гуглу за отсутствие тупой упертости и буквоедства. Но не у всех эпигонов оно так, а большинство соискателей из РФ дело иметь будут, скорее, с эпигонами.

johnfound
17.11.2023 13:44
#26170306
+8
То что вы называете « инженеры, создающие решения», это не инженеры. Это квалификация уровня техникума. Среднее специальное образование – типа, специалист, который знаком с технологиями и может их правильно и грамотно применять. Есть фрезисты, слесари, токари и соответственно программисты. У программистов тоже есть «разряды» как у токарей. Только называются по другому – всякие джуны, миддлы и т.п. А ведь «программист 6-го разряда» не звучит хуже «токаря 6-го разряда».

В сфере ИТ, по сути 98% кадров являются именно такие специалисты. Другое дело почему считается что это инженерный уровень? Как по мне – инерция мышления. Отсюда и весь вой насчет вузовского образования – «мне эти знания никогда не понадобятся!». Конечно не понадобятся – ты хочешь работать на уровне среднего специалиста, почему тогда пошел учиться в университет?

В этом есть и другая проблема – есть тенденция из-за этого просто занижать и менять требования к высшему образованию, уменьшать теорию, увеличивать практику и знакомство с конкретными технологиями. Таким образом делая техникумы из вузов.
1. konst90
  17.11.2023 13:44
  #26170892
  +4
  А это следствие "без вышки никак" и "будешь плохо учиться - в ПТУ пойдешь". А ведь люди со средне-специальным образованием - это как раз те, кто работает по готовым инструкциям от людей с высшим, но работает так, как люди с высшим не умеют.
  
  Вот я, например, инженер. Я могу спроектировать деталь и рассчитать на прочность, но я не обработаю ее на станке и не (качественно) не сварю - для этого есть токарь, фрезеровщик и сварщик.
  
  Но так печально сложилось, что работа руками у многих людей считается чем-то плохим или унизительным, а сидеть в офисе и перекладывать договора - хорошо. Нет, для договоров тоже нужно многое знать и уметь, но хороший слесарь знает и умеет не меньше.
  
  В общем, да. ПТУ - это не плохое образование. ПТУ - это другое образование. И оно тоже нужно.

esisl
17.11.2023 13:44
#26170362
+4
Тут есть два нюанса:
1. "А как?" как отфильтровать "гожего" кандидата от "негожего"? Особенно силами HR, который, в титульной деятельности... скажем так "в пределах четкой должностной инструкции". Потому, в условиях, когда кандидатов реально много, просто задирают планочку по-выше, как умеют, в надежде, что так пройдут только самые самые. Тащем-то помогает плохо. Видел пару раз, как в яндекс(в яндекс Карл!) проскакивали ТАААКИЕ персонажи на испытательный срок...
2. Наша деятельность - это ковыряние в торте Наполеон. Только слои там - из абстракций. Лично я для себя оч давно усвоил "если работаешь со слоем абстракции N, то должен понимать N-1". Если работаешь с интерпретатором, знай как. Если с базой данных, знай, как она обрабатывает данные в памяти, ну и т.д. и т.п. Алгоримты - это один из "придонных" слоев. "НуивотЪ" (с)

ALexhha
17.11.2023 13:44
#26170458
+3
Знакомый работавший в кп/яндексе говорил, что часто проблему тормозов решали добавлением памяти/ssd/cpu, так как выходило намного дешевле. Чем неделями искать то самое проблемное место в коде
1. Tolomuco
  17.11.2023 13:44
  #26170570
  +4
  Которого может и не быть :)
1. vadimr
  17.11.2023 13:44
  #26171688
  +1
  Если проблему тормозов можно решить добавлением железа, то часто проще всего так и сделать. Однако железом вы, во-первых, даже в сотню раз обычно вряд ли ускорите (за исключением совсем патологических случаев), а во-вторых, что вы будете делать, когда кончится доступное железо?

Captain_in_the_Green_Hat
17.11.2023 13:44
#26170576
+2
Автор немного намудрил в классификации, на мой взгляд.

Инженер-исследователь и инженер по эксплуатации, вот как это называется.

Первый должен знать алгоритмы, доказывать теоремы, играть в науку и вызубрить все формулы с бумажки.

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

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

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

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

ImagineTables
17.11.2023 13:44
#26170632
+5
Я помню, как меня пригласили собеседоваться в ••••.ру на позицию специалиста по UI в группу •••. Это был очень известный в своё время продукт (можно сказать, Грааль моего детства, тем более, у меня в детстве не было Интернета), который на момент собеседования слегка подзачах (UI определённо вносил свою лепту). Я подумал: “Make ••• Great Again!” — весьма достойная миссия, было бы здорово над этим поработать. Тем более, на предыдущем месте начиная с одной только имплементации чужих UI-макетов, я закончил проектированием нового функционала, работой с юзерами и т.п.

На собеседовании меня первым делом спросили, какие примитивы синхронизации в Windows я знаю. Сначала я хотел переспросить, точно ли эта та позиция, про которую мы говорили. Потому что я бы хотел услышать вопросы, как писать десктопные приложения на основе разметки и не тащить стометрового бегемота по кличке Хромиум. Почему такой приятный для глаза скевоморфизм устарел (это можно обосновать не только модой, но и объективными причинами — могу набросать постик, если кому-то очень интересно). Как происходит падение через шрифтовую решётку, почему тофу это невкусно и чем goto отличается от noto. Как встроить своё окно куда-нибудь в виндовое (или наоборот). На худой конец, про baNaNa (Ecma в UI используется широко, и это не просто так). С другой стороны, подумал я, в последнем проекте я действительно использовал примитивы синхронизации, и нередко. Наверно, они хотят поговорить не о том, с чем работает интерфейсник (это банально), а о том, с чем он встречается редко, но метко (можно сильно запороть юз-кейсы, если не уметь в многопоточность). И я ответил: критические секции, мьютексы, семафоры.

«Хорошо, но мало!», услышал я в ответ. «А теперь расскажите, как устроен мьютекс». Тут уже пришлось переспросить про вакансию (оказалось, не перепутали). Я, как мог вежливо, сказал, что не то, что не знаю, а знать не хочу — если бы меня интересовало устройство мьютекса, я бы писал ядра-чистый-изумруд. Как специализирующийся в UI разработчик, я знаю, как ими пользоваться и считаю это абсолютно достаточным. Знаю, когда использовать более лёгкие внутрипроцессные примитивы, а когда — глобальные, как избежать гонок, даже знаю удобный способ шарить прагмами хендлы мьютексов между процессами. Ну и как прилежный читатель Феня Юаня с грехом пополам умею вызывать разные WinAPI-функции для всего этого дела ;)

Собеседующий как будто всего этого не услышал. «А вы возьмите лист бумаги и попробуйте спроектировать мьютекс! Как бы вы это сделали? Какой алгоритм должен лежать в основе?». Я понимаю, что это уже не смешно, и говорю: «Мне кажется, я вам не очень подхожу» (про себя думаю, естественно, наоборот). На этом мы и попрощались.

Через год ••••.ру закрыла ••• за полной невостребованностью у юзеров.

Я ни на что не намекаю.
1. agendasshanty
  17.11.2023 13:44
  #26176648
  +1
  классика, подобные собеседования и у меня были, был молод и глуп , а сейчас просто прерываю такие, это всегда сигнал там ищут такого чтоб и швец, и жнец, и на дуде игрец, а в нынешнем возрасте главным куда пошлют быть не хочется

werevolff
17.11.2023 13:44
#26170936
+2
1. Инженеры-технологи не компетентнее тех, кто пользуется их решениями. Зачастую, они не могут оперативно собирать финальные продукты, пользуясь стеком решений. Эти инженеры узкоспециализированы. Как и те, кто собирает решения в продукт. Я ещë не встречал универсалов с одинаковой эффективностью в 100% сценариев.
2. Алгоритмы важны для сборщиков. Только, не всегда от них требуется работа со сложными алгоритмами. Можно сколь угодно разглагольствовать на тему "но он же допустит ошибку, если не знает как уменьшить сложность алго за счëт дифференцирования функции", и, всë-равно, человек, который знает, как выполнить математическую оптимизацию алго-функции, либо не будет достаточно компетентным, чтобы организовать связку микросервисов с шиной данных, либо его зарплатные ожидания сильно выше того, что готовы предложить в областях, где собирают готовые решения. Дело не в необходимости опыта решения алгоритмов, а в углублëнности этого опыта.

Zara6502
17.11.2023 13:44
#26170938
+4
Я эти мысли озвучиваю всю свою жизнь и минусов понахватал за это время несчётное количество, хотя вроде всё же очевидно.

Для тех, кто любит рассказывать про гипотетического Васю, который из-за незнания O(n) накосячит и проект стоимостью 100000000000000 триллиардов квинтильонов долларов пойдёт в мусорку - не будьте детьми и перестаньте уже нести такую чушь - во-первых если ваш Вася занимает такую должность, что только от него зависит проект - то кто-то такого некомпетентного же поставил на эту должность?! Во-вторых, если Вася такой крутой и рулит таким проектом, он точно-точно будет банально сидеть кодить? В-третьих, ни за что не поверю, что у такого проекта нет "отдела качества" и тестировщиков.

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

Так что в 99.(9)% задач сортировать будет метод из стандартной библиотеки, так же как проще внедрить UE5 чем создавать свой движок, особенно с нуля и чтобы угнаться за конкурентами. Физика, освещение, звук - вполне вероятно уже люди поумнее всё написали, в конце концов сейчас 2023 год, а не 1972.
1. SinsI
  17.11.2023 13:44
  #26171258
  Зачем вводить в беседу заведомо глупые придуманные примеры?
  
  ...когда можно использовать примеры из реальной жизни ни на йоту не умнее?
  
  При этом проект собрал "всего" 8 миллиардов долларов!
  
  Снимите розовые очки - "отдел качества" и тестировщики - не всемогущи!
  1. Zara6502
    17.11.2023 13:44
    #26171766
    +1
    ...когда можно использовать примеры из реальной жизни ни на йоту не умнее?
    
    розовые очки - это думать что все и всюду будут мега-специалистами. А этот пример хорошее тому подтверждение что никакие "алгоритмы на собеседованиях" не работают, ведь это случилось в той самой парадигме, а не в моей, то есть я как раз прав.
    
    "отдел качества" и тестировщики - не всемогущи!
    
    конечно нет, когда у вас некомпетентны кадры в целом, включая топов.
    
    или вы думаете что при самодуре-начальнике великий программист будет писать идеальный код и программа будет идеальна от и до? у ваших розовых очков еще и +5 линзы.
    
    SinsI
    17.11.2023 13:44
    #26172222
    -1
    или вы думаете что при самодуре-начальнике великий программист будет писать идеальный код и программа будет идеальна от и до?
    
    Программист, не имеющий понятия об алгоритмах будет писать ужасный код при любом начальнике.
    
    А этот пример хорошее тому подтверждение что никакие "алгоритмы на собеседованиях" не работают, ведь это случилось в той самой парадигме, а не в моей, то есть я как раз прав.
    
    Нет, это показывает что проблемы иногда проскальзывают даже с "алгоритмами на собеседованиях" - и если б их знание не проверяли, то всё было бы значительно печальнее.
    
    Алгоритмы - это часть арсенала программиста; на собеседованиях никто не просит придумать их с нуля, проверяется их знание и то, какие критерии программист использует для выбора подходящего из них для поставленной на собеседовании задачи.
    
    Zara6502
    17.11.2023 13:44
    #26172566
    +2
    Программист, не имеющий понятия об алгоритмах будет писать ужасный код при любом начальнике
    
    Это не мешает им зарабатывать миллиарды. То есть вам нужно определиться что для вас важнее - алгоритмы и код или доход?
    
    Алгоритмы - это часть арсенала программиста
    
    Думаю алгоритмы пригождаются почти никогда, нужен только скилл на их правильное применение.
    
    SinsI
    17.11.2023 13:44
    #26173188
    +2
    Да с чего вы взяли, что не мешает?!
    
    Думаете, необходимость ждать в лобби по 25 минут не стоила Rock* нескольких миллиардов упущенной прибыли?
    
    Несчесть проектов, которые загублены багами и отвратительной производительностью...
    
    Думаю алгоритмы пригождаются почти никогда, нужен только скилл на их правильное применение.
    
    Скилл на их правильное применение требует хотя бы знание того, какие алгоритмы существуют..
    
    IgorAlentyev
    17.11.2023 13:44
    #26174274
    +1
    Думаете, необходимость ждать в лобби по 25 минут не стоила Rock* нескольких миллиардов упущенной прибыли?
    
    Точно не стоила, ведь у них просто нет конкурентов.
  1. VADemon
    17.11.2023 13:44
    #26173134
    +1
    Единственное, о чем говорит этот пример:
    
    человек скорее всего не дочитал документацию или взял первое попавшееся. (Или по вашему тут алгоритмист должен был с нуля что-то писать?) Уповать на "не знает O(n) от O(n²)" - нету смысла, маловероятно.
    
    В компании нет контроля качества, как и свободного времени заниматься улучшением кодовой базы (а ля менеджмент не поставил таск - ничего не делаю).
    
    О проблеме долгих загрузок GTA5 знал каждый игрок. В моем случае я лишь увидел 100% одного ядра во время загрузки и подумал "ну таким образом грузится значит..." Это надо годами не замечать слона.
    
    Как это сегодня бывает, не было бы античита - пофиксил бы кто-то из сообщества раньше. Будь открытый движок - ещё раньше. Прислушивались бы к отзывам пользователей + багтрекер - аналогично. Но что ожидать от компании, которая техподдержкой писала отписки пользователем, у которых не пришла оплаченная микротранзакция.
1. Emulyator
  17.11.2023 13:44
  #26171350
  Может люди поумнее все и написали, но при "умелом" подходе можно "один сломать другой потерять"(с). История хранит, а окружающее нас ПО каждый день напоминает пользователям, что некомпетентных сотрудников назначают некомпетентные начальники, и отдел тестирования это не панацея, а продукт надо выпустить вчера. Пользователю не легче от числа "Вась" в коллективе. А вот вокруг удачных архитектурных (включая алгоритмические) идей возникают удачные долгоживущие проекты, отправляющие тех самых конкурентов в историю. Заложить в основу проекта такие идеи способен даже один толковый человек понимающий алгоритмы, задача остальных - не утопить идею при реализации. Без понимания алгоритмов, можно и не реализовать, то заложенное конкурентно преимущество на "вау" уровне, способное привлечь пользователей.
1. vadimr
  17.11.2023 13:44
  #26171436
  Запомните, даже за самым-самым стоит человек или группа лиц, которые всегда скажут, если что-то не так, в одну голову ничего титанического сделать невозможно, та же наука работает от публикаций и рецензий, само научное сообщество фильтрует знания и новодел.
  
  Только отфильтровать можно в разные стороны. Можно путём изменения эффективности кода, можно путём изменений ожиданий публики, можно путём изменения требований, можно путём изменения бюджета и т.д.
  
  Про то, как работает научное сообщество, тоже можно очень даже поспорить. Публикаций и рецензий очень много, а движения научного знания вперёд мало.
1. vkni
  17.11.2023 13:44
  #26173768
  Для тех, кто любит рассказывать про гипотетического Васю, который из-за незнания O(n) накосячит и проект стоимостью 100000000000000 триллиардов квинтильонов долларов пойдёт в мусорку
  
  Вы правы, это крайне маловероятно. Типичный вариант - это Вася вставит O(n^2) вместо O(n), написав, к примеру strlen в условии цикла. Код слегка замедлит выполнение, что будет незаметно. Но в случае пика нагрузки (в 10), потоковая обработка, которая в теории должна сработать, катастрофически замедлится, пропустить timeout, после чего вам пойдёт звонок. И если Вася проработает год-другой, таких мест будет много, а, соответственно, спать вам будет нервно и неприятно. А значит, придётся тратить очень много времени на рецензирование PRов Васи. Это тоже неприятно.
  1. wataru
    17.11.2023 13:44
    #26174082
    +1
    Код слегка замедлит выполнение, что будет незаметно.
    
    Да тут не надо даже пика нагрузки. Просто примерно вся программа будет раз в 5 медленнее, чем могла бы. Потому что там за каждым уголом O(n^2) вместо O(n).
    
    vkni
    17.11.2023 13:44
    #26174908
    Это замедление как раз легко парируется методом «просто добавь машин». Сейчас это особенно легко с виртуальными машинами. Да, латентность таким образом не лечится, но это, обычно, не проблема.
    
    Проблема получается в динамике, может быть даже адиобатической, когда у вас система написана под 10к запросов в секунду и написана более-менее линейно-масштабируемой. А через год у вас всё возрастает до 30к, а какой-то участок тормозит не в 3 раза, а в 10.
1. netolyrg
  17.11.2023 13:44
  #26176668
  Отдел качества также может состоять из людей, которые знают только про функциональное тестирование, а про нагрузку им на курсах не рассказывали. Да и понимание, что под Интерфейсом лежит, часто заканчивается на HTML/CSS.
  
  У тестирования такая же проблема, а скорее всего это уже не QA, а QC, если не testers. Потому что «проще купить новую память», «нанять еще 5 тестировщиков», чем подумать, на что и реагирует индустрия.

alelam
17.11.2023 13:44
#26171018
+4
Я не собеседовался в Яндекс и достаточно поверхностно знаю алгоритмы. Но мне всегда казалось, что эти холивары имели бы смысл только в случае, когда нормальные работодатели смотрят резюме, проводят скрининги и т.п., а вот яндекс и фаанг выкатывают оферы и вешают лычки чисто по рейтингу на литкоде. Как один из критериев отбора алгоритмическая секция ничем не отличается от пресловутой строчки "коммерческий опыт" в резюме, эйчар-скринингов и т.п. В идеальном мире конечно любого желающего с вайти-курсами за плечами стоило бы взять на 3 мес испытательного и смотреть, вдруг он окажется лучше того олимпиадного программиста с солидным айти-дипломом, который умеет деревья балансировать. Подозреваю, что как только в том же Яндексе соотношение вакансия/резюме опустится ниже какой-то отметки, там моментально забудут про все эти секции и ничего при этом не потеряют. Но пока не перевалило, надо же как-то кандидатов отсеивать и алгоритмы способ далеко не самый плохой.

vagon333
17.11.2023 13:44
#26171046
+3
Почему эти «алгоритмические задачки» вообще так популярны на собеседованиях и почему руководство верит, что так они смогут отобрать хороших программистов — вопрос открытый.

Могу предположить - лень интервьювера.

panzerfaust
17.11.2023 13:44
#26171112
+3
Алгоритмы это как приправа в блюдо. Без приправы - не очень. Но и жрать одну только приправу - идиотизм. Если все 9000 этапов собеса крутятся вокруг алгоритмов, то это какое-то кровавое шапито, а не оценка кандидата.

vkomen
17.11.2023 13:44
#26171118
Вот в целом согласен, но не в случае с Яндекс! Потому как им нужны и "простые кодеры", и очень продвинутые ребята, и компания дает возможности роста чуть не до небес. Вторые только и могут вырасти из первых, все эти мечты "из грязи в стразы" сразу же - ну такое

esisl
17.11.2023 13:44
#26171238
Нет-нет. В Яндексе, если вы прошли первый фильтр(я прошел с третьего раза), то вас ждет нормальное дружелюбное собеседование с компетентными профессионалами.
Вот только там меня сразу спросили "статическое связывание". И залип.
Мне понадобилось минут 10 чтобы спросить у яндекса и хлопнуть себя по лбу "так этот способ вызова, оказывается НАЗВАНИЕ ИМЕЕТ!!!" :))))))))))))))))))))
Естессно мы вежливо распрощались :)))))
Прав ли был коллега? Прав!
Потому, что как любой крупной корпорации, яндексу нужны "детальки" которые сядут в посадочные места без допусков и начнут функционировать без раскачки.

Это если бы им понадобился реверс-инженер для поиска багов в забытых приложениях, я был бы к месте :) Наверное...
Больше удивляет, что через такой, вполне годный фильтр иногда проскакивают совершеннейшие "чуда-юда"
1. D7ILeucoH
  17.11.2023 13:44
  #26173400
  +2
  В Яндекс я собесился на зарплату Х, которая была на самом деле смешно малой даже по тому времени. Собесился с учётом того что у меня за плечами годы стажировок, успешных проектов, работ. Позиция - разработка ПО.
  
  Так вот, у меня почти сразу начали спрашивать за хитрые обходы деревьев, я что-то попытался ответить, но всё больше ловил в себе мысль "что вообще происходит?". Дали написать какой-то код, который я написал не самым оптимальным образом. И потом мне сказали что я им не подхожу.
  
  Поменяв в резюме ЗП с Х на 2Х я нашёл нормальную компанию Сбер, в которой мне задавали нормальные предметные вопросы. Была также и парочка предметных вопросов с подковыркой, но я ввиду своего многолетнего опыта смог ответить верно. Никакой ерунды ни про графы, ни про деревья, ни про алгоритмы.
  
  Естественно всё прошёл, кайфую, дорос до техлида, ЗП давно перевалила за 3Х. Соболезную тем кто уходит работать в Яндекс на подножный корм. Мало того что унижают, так ещё и не платят толком. А ещё руководство высказывает всякую херню в публичное поле, что стыдно становится.

titan_pc
17.11.2023 13:44
#26171240
Лучшее лекарство от всех болезней в коде - это нагрузочное тестирование. А реализацию любого алгоритма можно у чат джпт спросить. Отстали от жизни интервьюеры, которые требуют знания, которые в элементарном доступе и пригождаются только тогда, когда начинается пресловутая оптимизация после нагрузки. Я за свою жизнь ещё не разу не видел, чтобы написанные опен сорс решения не болели болячками. Хоть многие и считают что все эти вещи делаются супер умными людьми, но прикол в том что именно людьми.

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

И как знания алгоритмов помогут тебе в оптимизации СУБД например, которая тормозит на твоих кейсах. Да никак. Ишью повесишь разрабам и будешь ждать фикса.

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

Emulyator
17.11.2023 13:44
#26171284
Хорошо если тестировщик смог отловить ситуацию(например, нагрузочным тестом) когда программист по незнанию применил неэффективный подход, плохо, когда ни тот и другой по незнанию не сообразили где нагрузить и оптимизировать. Мне, как пользователю, ежедневно приходится сталкиваться с неадекватно длительными ожиданиями при работе с программами, созданными в таких парах. Прозвучит категорично, но соискатель с глубоким знанием алгоритмов перспективнее, чем без таковых, пусть даже на должность дворника (уверен даже там можно оптимизировать подходы). ))

arTk_ev
17.11.2023 13:44
#26171332
Есть разработка, а есть производство. Учить алгоритмы - означает возможность хотя бы прочитать научный пейпер со сложнейшей математики и реализовать его. А не зубрить алгоритмы сортировок - вы обязаны по-умолчанию их знать и уметь применять и создавать свои собственные.

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

Произвоство - это реализация оптимального решения и поддержка его. У производства есть четкие сроки.

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

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

Разработка нового решения почти всегда выгоднее использования готовый решений, из-за специфики программирования.
1. panzerfaust
  17.11.2023 13:44
  #26171348
  создавать свои собственные
  
  И как, много новых сортировок создали?
  1. arTk_ev
    17.11.2023 13:44
    #26171630
    +1
    Каждый год по одной, в среднем.
    
    Сортировка на gpu, различные сортирвки для отрисовки прозрачки, и не зависячищие от порядка, всякие аналоги-ZBuffer, быстрейшая сортировка для целочисленных массивов, сортировка для балансировки kd-деревьев, сортировка pointcloud для автоматического лодирования, стохастическая сортировка.
    
    В основном это эвристические алгоритмы, так как они самые быстрые, но они не универсальны. И их просто так не реализовать, нужно дорабатывать под конкретные задачи и являются объединением сразу нескольких алгоритмов.
    
    Лучший алгоритм сортировка - это отсутствие необходимости сортировать.
    
    panzerfaust
    17.11.2023 13:44
    #26171916
    +2
    Замечательно. Но как из этого следует, что каждый разраб обязан по умолчанию придумывать свои сортировки? Будет задача по работе - сядем и придумаем. Не будет - ну уж извините, не все игровые движки пишут. И тем более почему все должны по щучьему велению рожать это все на собесе за отведенные 45 минут? Чем этот снобизм отличается от "не служил - не мужик"?

hanzakkerman
17.11.2023 13:44
#26171340
+2
Опишу простой кейс, где знание алгоритмов must have: LiveJournal. Написан на Perl, его движок работает с точки зрения производительности чуть лучше, чем отвратительно. Единственный вариант сделать его чуть быстрее и адекватнее - найти самые медленные части и переписать алгоритмически эффективно. Желательно ещё и с применением XS (компилируемого в бинарь кода на Си, подключаемого как обычная перловая библиотека).
И это, к сожалению, очень типичный кейс, особенно, как мне кажется, в российском мире разработки, где основным заказчиком через пятые руки, но всё равно является государство (и это точно не про эффективность). В чём кейс? В том, что компании хотят что-то изменить, ничего принципиально не меняя. Улучшить давно сдохший в муках движок, но не переписывать его на другом языке с нуля, оптимизировать какие-то куски библиотек для взаимодействия с ЦБ, но не менять сами библиотеки, потому что ошибка может стоить слишком дорого, а "бизнес" устраивает статус-кво (работает - не трожь), заменить кусок последовательного кода без намёка на треды и асинк, алгоритмически оптимизировав в нём 10% (хотя можно было получить +300% прироста производительности, всё-таки переписав движок).
Бизнес очень консервативен сам по себе, даже в сфере IT. Бизнес, взаимодействующий с богатым, но чреватым безумными штрафами и даже уголовными делами государством, - часто и вовсе костенеет, становится пугливым и неповоротливым до (бес)предела. И всё, что он может себе позволить - это гальванизация трупов кода из юрского периода ботоксными подтяжками правильных алгоритмов. То есть бизнес конечно начинает в какой-то момент осознавать проблему и хочет что-то изменить, но... только ничего не меняя. И чем крупнее бизнес - тем безнадёжнее и абсурднее ситуация в этом плане. И Yandex здесь - совершенно не исключение, хотя там есть, куда применять навыки написания алгоритмов, особенно в таких штуках как проекты, завязанные на картографию и AI.

nikolz
17.11.2023 13:44
#26171384
+4
Не перестаю удивляться, почему люди начинают приводить аналогию из тех областей, в которых они сами дилетанты. При этом серьезно полагают, что их рассуждения дилетанта доказывают их правоту в совершенной иной области деятельности, где они считают себя профессионалами.

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

Если Вы программист -профессионал, то и рассказывайте на своем примере.

nikolz
17.11.2023 13:44
#26171404
+2
"Почему эти «алгоритмические задачки» вообще так популярны на собеседованиях и почему руководство верит, что так они смогут отобрать хороших программистов — вопрос открытый. "

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

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

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

akakoychenko
17.11.2023 13:44
#26171488
+4
Странно, что, пролистав все комменты, все разговоры об одном и том же, - CPU, RAM, риск случайного комбинаторного взрыва, и противоположная позиция, что всем этим можно пренебречь.

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

Проведу пример из жизни. Проект - терминал управления коэффициентами для букмекера. На вид что-то вроде эксель таблицы с фиксированным лейаутом в зависимости от вида спорта. Оператор может там часть ячеек запол руками, часть заполнится сама при помощи внешних (не входящих в скоуп) алгоритмов. Команда что-то около 10 чел. Архитектор в алгоритмах очень слаб, но опыт программирования имеет солидный. Что он делает: показывает мастер-класс команде, как надо сделать раздел для футбола, создав контроллеры, фронт, логику запрограммировав, с алгоритмами проинтегрировав. Это время он вместе с командой кодит. Потом говорит, мол, я вам указал путь, остальные 25 видов спорта делайте по образу и подобию. Команда начинает делать. По виду спорта за 2 месяца. Потом, набив руку в копипасте, ускоряется до 1 вида спорта за месяц. Потом самый алгоритмически продвинутый член команды пишет кодогенератор, и команда выходит на финишную прямую со скоростью 2 недели на спорт. Года за 2 они заканчивают и даже празднуют сие событие.

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

И это при том, что, будь архитектор алгоритмически подкованным, он бы понял сразу, какой взять уровень абстракции. Понял бы, что, условно, писать контроллер и dto для баскетбола бред. Что лейауты можно не кодить программистами, а загружать из того же экселя динамически. Фактически, проект можно было изначально сделать очень компактным и гибким. Отдать 90% конфигурирования бизнес-аналитикам (или линейным руководителям операторов системы), а программистам оставить лишь сложную алгоритмическую часть по преобразованию эксель таблицы с лейаутами, привязками ячеек к алгоритмам, условиями взаимодействия ячеек между собой, в работающий терминал в момент запуска. Тогда бы и заняло это не 2 года. И, что важно, решение бы вышло очень гибким. Операционные отделы продолжили бы настраивать его под себя, никого не беспокоя, пока программисты перешли бы на новые интересные задачи.
1. alexkolzov
  17.11.2023 13:44
  #26172042
  +2
  По вашему описанию проект больше пострадал от отсутствия грамотной проработки предметной области и проектных ошибок, нежели от незнания алгоритмов исполнителями. Автор скорее указывает на то, что программист зачастую выступает в роле транслятора пожеланий менеджера или заказчика в исполняемый код. В такой схеме места для реальной инженерной работы действительно практически не остаётся, и польза от "ворлдскиллов" и правда превышает профит с фундаментальных знаний. Но это только в ближней перспективе. А потом все ошибки проектирования, "временные" решения, дыры в алгоритмах из тысяч условий под каждый найденный тестированием "частный случай" начнут обваливать проект прямо на головы вот таких вот умников, для которых "алгоритмы не важны".
  1. akakoychenko
    17.11.2023 13:44
    #26172084
    Да, Вы определенно правы, что проект пострадал из-за отвратительного проектирования. Но, почему так вышло? Архитектор ведь не был классическим говнокодером. Он практически наизусть мог цитировать "Чистый код" Мартина и "DDD" Эванса, постоянно на конфы ходил, паттерны знал. Моё мнение, что его проблема (и проблема подчиненных, которые не нашли что возразить) была в неспособности мыслить на правильном уровне абстракции.
    
    И, тут уже моё наблюдение, что этот скилл отлично коррелирует с пониманием алгоритмов. Люди, которые показывали хорошее понимание алгоритмов на собеседовании, хорошо справлялись и с абстракцией в работе, и наоборот. Возможно, потому, что опыт с алгоритмами и пониманием, как оно работает внутри, заставляет задавать правильные вопросы, а не тупо транслировать документ с требованиями в доменную модель. Это причина, почему лично я всегда предпочту нанять человека, который, например, сможет запрограммировать вывод множества всех подмножеств и оценить сложность этой операции перед тем, кто зависает уже на объяснении задачи на примерах (чтобы незнание терминологии не стало преградой). Вот, как-то так сложилось, что такие люди способны выбрать правильный уровень абстракции и предложить изменение ТЗ, способное улучшить ценность значительно, а не просто где-то пол ялра сэкономить
    
    alexkolzov
    17.11.2023 13:44
    #26172178
    Ну, козырять цитатами из умных книжек по разработке горазд сейчас любой с парой тысяч на кармане и умением совершать покупки на Озоне. Я за свою практику таких "рецептов успешной разработки" наслушался. Причём не редко от людей, которые слыхом не слыхивали про бинарные деревья и хэштаблицы и начинают блеять, когда заводишь разговор о том, какую конкретно типовую проблему конкретно этот чудо-рецент призван был решить и какое она имеет отношение к конкретно нашим палестинам.
    
    "Уровень абстракции" - приятный уху программиста термин. Но тут всё проще. Образованного специалиста в любой области и отличает способность взглянуть на решаемую проблему комплексно. Зачастую заглядывая при этом за рамки предложенных регламентов и ТЗ - причём даже непроизвольно. Даже не в силу особого ума, у него просто асоциативный ряд априори больше.
    
    Но стоит признать, что автор отчасти прав. Я (и вы, думаю, тоже) по-старинке понимаю под программистом именно специалиста по составлению и реализации алгоритмов для решения прикладных вычислительных задач в определённой области. В то время как по должности программист часто - тот, кто заставляет компьютер выдавать удовлетворяющий заказчика результат. Неважно какими средствами. Продолжая (бестолковый) пример с водопроводчиком, задача программиста - хоть скотчем и жвачкой склеить трубы, лишь бы их при заказчике не пробило и он принял работу. Лопнут под нагрузкой из-за того, что не было "технологического инженера", пояснившего бы за закон Пуазейля - так нужно же было оформить соглашение о поддержке. Если цель заработать денег, а не сделать дело - это удачный подход с большими шансами на успех.
    
    VADemon
    17.11.2023 13:44
    #26173174
    и проблема подчиненных, которые не нашли что возразить
    
    А как была выстроена культура команды, разрешалось, поощрялось возражать и озвучивать идеи?
1. MechanicZelenyy
  17.11.2023 13:44
  #26172330
  +2
  И это при том, что, будь архитектор алгоритмически подкованным,
  Но ведь ваш пример как раз про другое, что именно ключевым было проектирование, а не алгоритмы. Архитектор вбрал заведомо не подходящую парадигму для проекта и алгоритмика в обычном понимании ему бы не очень то помогла.
  
  а программистам оставить лишь сложную алгоритмическую часть по преобразованию эксель таблицы с лейаутами, привязками ячеек к алгоритмам, условиями взаимодействия ячеек между собой, в работающий терминал в момент запуска.
  
  Вот как раз алгоритмически тут нет ничего сложного, сложно нормально спроектировать систему типов чтоб люди потом не умерли пытаясь расширить её не типовым лайутом.
1. vagon333
  17.11.2023 13:44
  #26173416
  +1
  Ваш пример несколько об ином - программист занялся работой архитектора.
  В вашем примере ошибка не столько алгоритмическая, сколько архитектурная: неэффективный дизайн решения.
  Ведь, как вы сами описали, исключить повторяющийся код, отдать подстройку под спорт бизнесу - это больше дизайн решения.

murkin-kot
17.11.2023 13:44
#26171504
Проблема хоть программирования, хоть какой угодно другой области применения человеческих усилий, одна - высшие посты занимают те, кто понятия не имеет об олимпиадных задачках. Всё остальное - следствие.

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

cijic
17.11.2023 13:44
#26171512
Помимо меня, также 20 лет занимающимся программированием, с вами, думаю, будет согласен Ли Кай-Фу, когда-то программист, а теперь ИТ-миллиардер, который в своей книге "Сверхдержавы искусственного интеллекта" писал также что есть два типа разработчиков - создатели моделей и иже с ними, и тех, кто их использует. И как вы писали, первые гораздо более технически подкованы, но для конечного пользователя и распространения ИИ нужны в большей степени вторые.

вообще этим должны заниматься скорее математики, а не инженеры

mirwide
17.11.2023 13:44
#26171628
А Вы знали, если неправильно расположить насос для водоснабжения или неправильно выбрать его мощность может возникнуть кавитация на лопастях, которая очень быстро их разрушит?

Ошибочно считать что знание алгоритмов бесполезно в коммерческой разработке. Компании которые проводят такие собеседования не разрабатывают сайты визитки на 100 пользователей. Была недавно статья на хабре от озона про 1 млн рпс. Сколько будет стоить ошибка которая приведет к росту потребления памяти в 1.5 раза в их сервисе? Порядок, думаю, сотни тысяч $ в месяц. Без учета того, что у них может не быть таких запасов, а значит сервис упадет и это будет стоить еще дороже. Яндекс и подобные, кроме нагруженных сервисов еще и БД свои пишут, балансировщики, поисковые движки. Те коммерческая разработка это не только рест контроллеры и раскрашивание кнопочек.
1. IgorAlentyev
  17.11.2023 13:44
  #26174346
  +2
  То что вы описали называется энтерпрайз хайлоад продукты. Помимо них существует бесчисленное множество компаний в тысячи раз меньше и им это всё не нужно.
  
  Не все хотят работать в ФААНгах и энтерпрайзе.
  
  Кто то хочет пилить стартап в команде из 1-5 человек, а не автоматизировать предприятия или писать банковские сервисы. Разные люди, разные задачи и разные навыки нужны.

StjarnornasFred
17.11.2023 13:44
#26171700
+1
Равно как я очень скептически отношусь ко всякому «спортивному программированию», где на скорость люди решают какие‑то полуматематические задачи — поскольку это совсем не те навыки, которые нужны программистам в реальной жизни и в реальной работе. Это какая‑то «параллельная вселенная».

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

igor_suhorukov
17.11.2023 13:44
#26171794
+1
Сознательно не трачу время на подготовку к алгоритмическим интервью, leetcode и работе в таких компаниях. Обычно где желающих очередь, там и отношение к сотрудникам как к легко заменяемому ресурсу.

Хотя мне иногда все же приходится освежать знания и использовать асимптотическую сложность алгоритмов при решении своих задач. Последний пример из своей практики для задач маршрутизации описал в Онлайн визуализация алгоритмов: жадного, Дейкстры, A* и двунаправленного поиска
1. wataru
  17.11.2023 13:44
  #26171808
  Обычно где желающих очередь, там и отношение к сотрудникам как к легко заменяемому ресурсу.
  
  Ну, в гугле отличное отношение. Хоть и портится потихоньку. Но все-равно - одно из лучших, как мне кажется. Сокращения-увольнения первый раз в истории случились в этом году. Удаленная работа, шикарный офис с плюшками и хорошая зарплата. Даже если вы плохо справляетесь со своими обязанностями, вас не уволят, а переведут на personal improvement plan, и будут долго пытаться вас вытащить.
  1. igor_suhorukov
    17.11.2023 13:44
    #26175042
    +1
    Хорошо, как удостоверюсь что это не просто PR - возьмут на испытательный без этих олимпиад, так возможно и пересмотрю свое отношение...

alekciy
17.11.2023 13:44
#26172006
+1
По моим наблюдениям история на собесах как с задачей о люках. Спрашивают потому что так спрашивает и Гугл. Культ Карго. Как это соотносится с практикой на конкретной позиции задумываются не очень сильно. А стоило бы. Ведь на сколько я знаю Гугл и сам на своей статистике признал, что хорошое прохождение алгосов не даёт в итоге хорошего инженера в работе. И задачки а-ля люки убрали.

alexkolzov
17.11.2023 13:44
#26172014
То есть в очередной раз предлагается рассматривать программиста как рабочую единицу, задействованную в выпуске на прилавок алгоритмосодержащего продукта с заданными потребительскими свойствами. Ок. Мысль не нова, приводимые аргументы, аналогии и выводы далеки от того, чтобы претендовать на оригинальность.

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

Но ваша точка зрения имеет право на жизнь.

Flux
17.11.2023 13:44
#26172044
+7
Классическое "не больно-то и хотелось".

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

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

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

Не так давно писал в соцсетях хейт‑пост по поводу «алгоритмических секций» при приёме на работу в Яндекс.

Не взяли и стало обидно, да? Трудно представить более классическую ситуацию чем эта.
А вы ведь ещё и новое поколение "инженеров реализаторов" обучаете, судя по инфе в профиле. Но это, в общем, даже радует - спрос на специалистов с нормальным багажом знаний будет только расти.
1. iig
  17.11.2023 13:44
  #26172168
  +1
  А потом оказалось что годами существует баг
  
  Но ведь задокументированные баги принято чинить же?
  1. Flux
    17.11.2023 13:44
    #26172368
    -1
    А в этом вся мораль истории.
    
    "Инженеры-реализаторы" которым алгоритмы не важны даже не подумают залезть исходники стдлибы, ведь она лишь инструмент который не подводит.
    Реализаторам писавшим эту стдлибу тоже алгоритмы были не важны, а потому персистентность была обеспечена копированием, мы тут делом занимаемся а не деревья на вайтборде крутим.
    
    Инженеры которым не важны алгоритмы зачастую принимают такие архитектурные решения что легче нанять студента-олимпиадника чем потом страдать от тормозов во всех конечных продуктах которых коснулась рука "реализатора".
    
    iig
    17.11.2023 13:44
    #26175746
    +1
    Если нет культуры производства (обнаружили баг - завели баг - починили баг - код ревью - и в продакшен к следующему релизу, например), то как бы и не особо важно, кто там код пишет - джамшуты или олимпиадники.
1. IgorAlentyev
  17.11.2023 13:44
  #26174360
  +1
  Раз баг годами существовал и не был пофикшен, значит никого это не беспокоило, и в чем проблема тогда?
  
  Не всегда нужно фиксить баг, который видит какой то 0.001% пользователей, особенно если профит от фикса не перекроит потери на реализацию.

dom1n1k
17.11.2023 13:44
#26172256
+4
На правах лирического отступления.
В JS есть тип данных BigInt. Кто интересовался методами быстрого умножения, слышал про алгоритмы Карацюбы, Тоома, FFT и пр. Угадайте, какой из них использует под капотом Хромиум? Правильный ответ — все, в зависимости от размера чисел. А ещё несколько быстрых алгоримов деления, форматирования чисел и т.д. А вот в Firefox реализация BigInt только базовая. Кому интересно, можете поэкспериментировать с бенчмарками и убедиться, что в FF идеально выходит O(n^2), а Хром намного быстрее. Ну и исходники можно посмотреть, там любопытно.
1. wataru
  17.11.2023 13:44
  #26172356
  Ну и исходники можно посмотреть, там любопытно.
  
  Вот, кому интересно.
1. VADemon
  17.11.2023 13:44
  #26173198
  Based on Golang? Ну и история введения очень позабавила, "revert, reland, revert^2", а так, конечно, интересно.

vvbob
17.11.2023 13:44
#26172388
+3
Почему эти «алгоритмические задачки» вообще так популярны на собеседованиях и почему руководство верит, что так они смогут отобрать хороших программистов — вопрос открытый.

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

shsv382
17.11.2023 13:44
#26172538
Потому что 99% программистов способны написать код для 99% ситуаций, а вот отбор по алгоритмическим задачам делают для того, чтобы быть уверенными, что когда настанет тот самый 1% ситуаций, где нужно будет не тупить, а решить что-то, возможно даже алгоритмически, потенциальный кандидат с этим справится. Как-то так
1. vvbob
  17.11.2023 13:44
  #26172662
  +4
  С таким подходом надо еще искать людей, способных в случае нападения октопусов с Марса вовремя открыть огонь из своего АКМ, как-то так..
  1. vkni
    17.11.2023 13:44
    #26173702
    Это маловероятно, а вот возможность влупить случайное O(n^2) вместо O(n) даже у перекладывателя JSON'ов случается еженедельно. Потом оно проходит тесты, а на случайном пике нагрузки встаёт колом.

iboltaev
17.11.2023 13:44
#26172646
Я вам сейчас напишу, почему вы не правы.

Случай 1, 2012 год, мы писали софт для DB2, и там один из авторов пихал данные транзакций в вектор, делал по нему линейный поиск и удалял из середины. Пока код не наткнулся на транзакцию из миллиона записей. Автозамена на std::set проблему решила, но она бы не появилась, если бы была грамотность.

Еще случай, 2011 год, товарищ по цеху делал поиск в мапе итератором.

Еще недавний случай, товарищ фильтровал/копировал односвчзный список вставкой в конец другого односвязного списка (O(N^2) на ровном месте).

Еще случай оттуда же, товарищ сделал выдачу паркетного файла с сервера постранично, на каждый запрос страницы файл читался с начала...
1. MiraclePtr
  17.11.2023 13:44
  #26172778
  +2
  Я вам сейчас напишу, почему вы не правы
  
  Ну так эти примеры мало опровергают сказанное автором. Как уже выше обсуждали, чтобы избежать такого, достаточно знать (прочитать в документации) что такие-то контейнеры в библиотеке языка основан на таких-то штуках (хэш-таблица, односвязный список, и т.д.), а потом на википедии или в справочнике прочитать про их плюсы/минусы, сложность операций и границы применения. Знать, как они устроены и работают изнутри, а уж тем более уметь написать их свою реализацию - для их эффективного использования не обязательно, если только мы не ведём речь о каким-то совсем редких и узкоспецифичных случаях.
  
  Это как когда я выпекаю яблочный пирог, мне достаточно знать только общий рецепт, какой сорт яблок хорошо подходит для пирогов, как гасить соду уксусом, и как проверить, запеклось уже тесто или нет. Какие физические процессы и химические реакции происходят во время готовки, как выращивают яблоки, как мелят муку знать для получения хороших пирогов уже не обязательно. И уж тем более не обязательно самому уметь снести яйцо :)
  
  выдачу паркетного файла с сервера постранично, на каждый запрос страницы файл читался с начала...
  
  Это же алгоритм маляра Шлемиэля!
1. dom1n1k
  17.11.2023 13:44
  #26172872
  на каждый запрос страницы файл читался с начала...
  
  Я такое тоже делал в курсовой работе на 1 курсе.

gandjustas
17.11.2023 13:44
#26172870
Подмена понятий.

Алгоритмическое собеседование как в Яндекс\Гугл\ГдеТоЕще не нужно. Нет никаких доказательств что оно как-то влияет на продуктивность сотрудников и вообще как-то помогает.

А само знание алгоритмов очень нужно, помогает не писать говнокод. Алгоритмов которые надо знать и понимать не очень много: массивы, списки, сортировка, бинарный поиск, кучи, деревья, хэш-таблицы, "динамическое программирование". Обычно это изучается первые полгода на курсе программирования, а при самостоятельном изучении заботать за пару ндель можно.
1. wataru
  17.11.2023 13:44
  #26173016
  +1
  У вас какие-то взаимоисключающие параграфы. По вашим словам, собеседование, которое проверяет знание алгоритмов не коррелирует с продуктивностью сотрудников, но при этом знание алгоритмов помогает не писать говнокод (а умение писать не говнокод очевидно на продуктивность влияет).
  
  Алгоритмическое собеседование в Яндекс/Гугл - это лучший из возможных вариантов для них:
  
  Во-первых, оно действительно коррелирует с производительностью, вы про это во втором параграфе написали. Плюс в Фаангах гораздо чаще возникают задачи с данными, где действительно эти алгоритмы надо применять. Я на интервью справшиваю то, что лично в прод коммитил.
  
  Во-вторых, такие интервью можно стандартизировать, масштабировать и ввести объективные критерии. Когда у вас такая большая кампания - это важно. Никак не получится, например, "поговорить по душам" про прошлые проекты. Откалибровать интервьюверов невозможно. Плюс, вас завалят исками за дискриминацию (был знаминитый иск, где гугл обвинили в дискриминации по возрасту за вопрос о количестве бит в байте. Представляете что будет, если спрашивать про фреймворки какие-нибудь). Правда, это к россии не так сильно применимо.
  
  В-третьих, такие интервью достаточно сложные. Когда у вас сотни кандидатов на место, вам нужно достаточно сложное интервью с большим диапозоном оценок, иначе у вас 80 кандидатов на место получат высший бал, и что с ними дальше делать?
  
  В-четвертых, тут очень сложно считерить. Натаскаться объяснять чужой проект на гитхабе, как свой - на порядки проще, чем зазубрить все возможные задачи. Выучить стандартные фразы о плюсах и минусах фреймворка без малейшего понимания - тоже просто. Но если человек задачу решил, то он с гораздо большей вероятностью умеет в алгоритмы и способен идею оформить в виде кода.
  
  Какие есть альтернативы вообще? Спрашивать фреймворки? Так в условном гугле своя кухня. Смотреть старые проекты? Как их оценивать? Как нанимать джунов? Как проверить, что это не состряпанный конторой "войти-в-айти" профиль? Условный срок? Идеальный почти по всем праметрам вариант, но физически невозможный из-за количества кандидатов, высоких зарплат и найма с релокацией даже из других стран. Тестовое задание? Их проверять на порядок сложнее. И читерить с ними проще.
  
  Да, это не лучший вариант для условных ООО "Рога и Копыта". Если вы, например, позицию пол года закрыть не можете, вам нужен кодер только формочки клепать для ваших 10 юзеров, то бездумно копировать алгоритмические собеседования не стоит - это карго-культ.
  
  Но для Фаангов - это лучший вариант.
  1. gandjustas
    17.11.2023 13:44
    #26174096
    +1
    У вас логическая ошибка в первом же предложении. Вы считаете что "алгоритмические собеседования как в гугле", которые по факту решение leetcode задач уровня medium-hard на время в стрессовой ситуации, как-то проверяют знание алгоритмов. Это не так, единственное что проверяют такие собеседования - сколько человек тренировался решать leetcode задачи на время. Это не знания, а навык, причем весьма специфический, практически не востребованный в коммерческой разработке.
    
    Этот навык довольно слабо коррелирует с производительностью, так как высокая производительность в разработке ПО достигается тем, что люди не делают того, чего делать не надо. Не пишут сложный общий алгоритм, когда достаточно реализации частного случая, не делают навороченную архитектуру, когда достаточно написать все в одной функции, используют готовые библиотеки вместо написания своего кода в конце концов. Это все никак не связано с решением leetcode задач на время.
    
    Более того, нет никаких исследований, что умение быстро решать leetcode задачи на время как-то коррелирует с производительностью. Я честно искал и не нашел.
    
    Вы все правильно пишите, про преимущества таких собеседований, что сложно считерить, надо готовиться, обеспечивает однозначную оценку кандидата. Но проблема в другом - это собеседование не проверяет нужных навыков.
    
    Если вы фаанг или хотя бы яндекс, то к вам могут стоять очереди хоямячков, готовых забесплатно поработать ради строчки в резюме. Но если у вас компания поменьше, то найти хотя бы 10 подходящих кандидатов по другим критериям, кроме знания алгоритмов будет уже проблемой.
    
    Что касается задач, то как в фаангах, так и в рогах-и-копытах примерно одинаковое соотношения задач нетривиальной обработки данных и банальных перекладываний json. И вероятность что натренировавшись решать 100500 задач с литкода в секунду вы не будете заниматься скучной фигней - крайне мала.
    
    Альтернативы всегда существуют.
    
    Обычное собеседование с разбором кейсов: "как бы вы решили [такую] задачу". Желательно кейсы практические из встречающихся на практике. Тут и знания фрейморков, и алгоритмов, и умение фокусироваться на задаче итд
    
    Чтение кода и поиск багов. Несмотря на банальность такая работа встречается в практической разработке гораздо чаще, чем реализация каких-то алгоритмов.
    
    Тестовое задание, близкое к тому, чем придется заниматься, желательно с ограничением времени, которое сам кандидат назначит. Это идеальная проверка, но к сожалению многие кандидаты откажутся решать.
    
    Эти варианты не взаимоисключающие, а взаимодополняющие. Если у вас поток кандидатов большой, а отобрать надо мало, то можно применить все три, а если поток маленький, то провести только обычное собеседование.
    
    wataru
    17.11.2023 13:44
    #26174134
    -1
    Это не так, единственное что проверяют такие собеседования - сколько человек тренировался решать leetcode задачи на время. Это не знания, а навык, причем весьма специфический, практически не востребованный в коммерческой разработке.
    
    Не согласен. Натренироваться решать задачи без понимания сложностей и базы (простых) алгоримтов невозможно. Зазубрить ответы на тест по знанию языка или сильные и слабые стороны фреймворка можно. Зазубрить все задачи - невозможно.
    
    Да, тренировка помогает справлятся с задачами более быстро. Ну это издержки огромного потока кандидатов. Если бы гугл спрашивал "Обычное собеседование с разбором кейсов", то там тоже быстро бы уровень вопросов и их количество сильно выросли бы, ведь им все-равно надо 90+% кандидатов отсекать. В итоге пришлось бы тоже тренироваться это интервью проходить, а форумы бы полнились гневными отзывами, что "мне не надо на работе быстро разбирать кейсы на доске - я, блин, код пишу!"
    
    Потом, я уже много раз говорил, в ФААНГах довольно часто встречаются задачи, почти как с литкода. Я на интервью даю ту задачу, которую сам в прод коммитил. Мне приходилось писать и динамическое программирование и бинпоиски по ответу, и хитрые структуры данных с переплетенными стеками или очередями. Потом, вся разработка состоит из такого решения задач: вам надо что-то сделать, вы формулируете в голове решение и кодите его. Чаще это задачи уровня easy с литкода, но и medium достаточно часто появляются, что бы навык, помогающий проходить интервью, был достаточно релевантен.
    
    Я пишу статью сейчас, а то мои комментарии итак слишком длинные получаются. Там я подробнее разберу почему альтернативы не работают.

Question_man
17.11.2023 13:44
#26173952
+1
Алгоритмы, алгоритмы, алгоритмы... А автор вообще на литкод когда-нибудь заходил? Подавляющее большинство зелененьких и львиная доля желтеньких задач вообще не требует знаний алгоритмов. Зачастую можно придумать свое решение, причем далеко не оптимальное, и оно пройдет. На алгоритмических секциях спрашивают как правило такое, чтобы понять, умеет ли человек банально программировать и хоть минимально думать (я надеюсь, вы не будете спорить, что любому программисту это нужно).

P.S. Как же меня коробит, когда кто-нибудь заявляет: "Зачем знать вот это и вот это?" Давайе червям уподобимся еще, у которых единственный скилл - рыть землю.
1. MiraclePtr
  17.11.2023 13:44
  #26173976
  Как же меня коробит, когда кто-нибудь заявляет: "Зачем знать вот это и вот это?" Давайе червям уподобимся еще, у которых единственный скилл - рыть землю.
  
  Тут скорее вопрос ставится как "зачем посвящать время/силы изучению именно вот этого вот, а не чего-то другого, что может оказаться более полезным?"
1. gandjustas
  17.11.2023 13:44
  #26174102
  +1
  На литкоде любое решение пройдет. На алгоритмической секции собеседования решение должно быть асимптотически оптимальным.

kharabass
17.11.2023 13:44
#26176286
+1
Не стоит дженерализировать.
Алгоритмическое мышление — это же не только Дийкстра, А* или динамическое программирование.
Это насмотренность, возможность подобрать правильный подход к решению стандартной задачи.
Например, исправить последовательность символов в "битом" потоке. Структуры данных, опять же. Можно ли обойтись битовым массивом или стоит с хэшмепом реализовать. Такие задачи встречаются достаточно часто на практике, если в твоей зоне ответственности что-то чуть более серьезное, чем непубличный API "для пацанов". Но даже в публичном API нужно, например, валидировать параметры по разным критериям. И для этого не всегда есть подходящие решения.
Дальше, про библиотеки, написанные "маэстро". Некоторые не получится использовать, не понимая специфику задачи. Например, KNN в рекомендательных системах ретейлера. Результат будет, но он будет мусорным, пока не разберешься, как работать с данными.
Собеседующий, если он не бревно, конечно, глядит на то, как человек мыслит, а не только на результат. Сразу видно, где есть пробелы, а куда нужно будет вкладывать дорогой образовательный ресурс. Рассказывать можно разное, на деле сразу видно — ну и делать скидку на стресс, конечно.
Резюмируя, алгоритмы — это способ реализации задачи эффективно и "понятным алгоритмическим языком". Как для водопроводчика понимание того, почему трубу не надо укладывать под таким углом.

icya
17.11.2023 13:44
#26176610
В конце концов, можно докупить больше серверов или поставить немного больше памяти — и это будет гораздо более экономически оправданны решением, нежели тратить годы на разработку «оптимальнейшего» решения.

Или переложить эти расходы на конечного потребителя (смотрим ААА (и не только) гейм-дев).

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

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

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

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

sgrb
17.11.2023 13:44
#26176622
Нужен баланс на самом деле. Плохими разработчиками являются как чистые "олимпиадники", так вообще не имеющие представление о том, что такое алгоритмическая сложность. Если ты не знаешь, как в общих чертах каждый "кубик" работает внутри, то да, ты можешь делать простые конструкции из них. Но любая проблема, когда оказывается, что твоя конструкция работает плохо или как-то не так, ставит тебя в тупик. Поэтому для профессионального роста (= способность решать более сложные задачи) разработчику приходится разбираться, а как оно работает внутри. А там и алгоритмы неизбежно вылезают.

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

alex20092
17.11.2023 13:44
#26176650
Почему эти «алгоритмические задачки» вообще так популярны на собеседованиях и почему руководство верит, что так они смогут отобрать хороших программистов — вопрос открытый.

Потому, что
1. Российское эффективные менеджеры пытаются копировать западное IT. Они даже не смогли придумать и внедрить свою методику, всё, на что они способны - копипаста.
2. Они НЕ популярны. Популярны они у критической низкой массы крайне конформистских людей ит-сообщества, которые ведутся на любые веяния моды, не задаваясь вопросом - "а зачем это надо?".
3. Спросите у разработчиков со стажем от 5 лет - интересно ли им теперь на собеседованиях доказывать, что они умеют работать и приносить пользу?
  Вот лично мне, после 10+ лет с сфере - нет. Я, оказывается, теперь изначально программист с сомнительным опытом, мне алгоритмы нужно теперь писать в режиме лайвкодинга, что бы просто получить РАБОТУ (это в придачу к крайне возросшим требованиям по стеку).
4. Мне всегда было интересно, что такого выдающегося пишут те, кто предлагает кандидатам задачи на алгоритмы? В итоге большинство в той или иной степени перекладывают джсоны,а не пишут код базы данных.
А больше всего обидно, что IT-сообщество всё это проглотило и теперь условия отбора стали настолько жёсткие, что теперь пробиваться в IT становится просто затратным и бессмысленным делом. Индустрия ставит какие-то нереальные рамки, что бы ПРОСТО ПОЛУЧИТЬ РАБОТУ.

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

Если бы сообщество это отвергло, не шло на поводу, вся эти алгоритмы ушли бы в небытие. Но вы этого не сделали - вы покорно согласились доказывать, что вы не верблюд. Это вас и погубит. Выиграют лишь те, кто кто надрочился эти задачки решать. А работодатели будут ныть о нехватке кадров в 1 000 000 голов.

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

stonefix
17.11.2023 13:44
#26176652
Скорее навыки написания алгоритмов ставят не столько на первый план, сколько на первые этапы/секции)) Да, возможно, все эти алгозадачи не будут использоваться на работе в явном виде. Но в фаанги, в которые огромная конкуренция данный этап отсева кандидатов все-таки имеет смысл и унифицирует процесс найма. Как минимум алгосекция отсеивает кандидатов, незамотивированных разобраться в алгоритмических задачках и в базовых вещах из computer science (все-таки некоторые паттерны мышления оттуда мы используем в разработке неосознанно). Она является лакмусовой бумажкой, уравнивает всех и позволяет более объективно сравнить кандидатов по общим принципам на первых этапах.

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

kkonevets
17.11.2023 13:44
#26176670
Слишком много воды в посте. Аналогии избыточны. Если коротко, то Яндекс ищет спортивных программистов потому что ему важна скорость выкатки решения для конечного пользователя. А Ядро ищет хороших инженеров, так как ему важнее архитектура и вакатка на рынок занимает гораздо больше времени, да и задачи более фундаментальные. Короче Яндекс это хипстер, а Ядро это Линукс Торвальдс

DeskundigeICT
17.11.2023 13:44
#26176678
+1
Подписываюсь под каждым словом автора. У меня был похожий разговор на групповом собеседовании (бегите, если видите неиндивидуальный подход) 1С-Рарус. Это было обучение программированию на 1С после полутора месяца отборочных испытаний. У меня уже был уровень джуна. Я сказал, что ценю правильный подбор решений, а не изобретение очередного велосипеда а-ля ускорьте сортировку как в олимпиадах по программированию. Мне весьма скоро отказали, так как "мы не сходимся в ценностях". Не хочу никого обидеть, но вот уверен, что девку с фиолетовыми волосами и грязными вещами взяли.

Я очень рад, так как сейчас работаю в международной компании, в которой важна практическая, а не теоретическая польза. А так мне пришлось бы получать 12000 рублей в месяц и увеличивать зарплату на столько же за сдачу очередных искусственных экзаменов по 1С.

Kurlic
17.11.2023 13:44
#26176714
В чем то вы правы, но все таки алгоритмические кружки далеко не бесполезны, решение логических задач вообще прокачивает мозг, и позволяет и в прикладных ситуациях лучше мыслить. Но да, простая зубрёжка алгоритмов - почти бесполезна

MiyuHogosha
17.11.2023 13:44
#26176724
Ваш "технологический" программист и есть математик. Программирование на таком уровне является разделом математики. Все ваши понятия - алгоритм, рекурсия, линейное программирование, класс, стратегия, транспорная задача - пришли из разделов математики на стыли с лингвистикой ("как это записать правильнее?")

Алгоритмы не важны +69

Комментарии (305)

despair Автор