Как стать автором
Обновить

Комментарии 397

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

Согласен. В процессе поиска работы вижу, что все вакансии существуют по принципу: не очень то и нужно.

закрыть позицию у бизнеса не горит

КМК идёт бесконечное просеивание кандидатов, чтоб из крупиц высеять золото по их критериям.
Цель забрать лучших к себе в команду.

Это не поиск лучших. Это агрессивная фильтрация худших.

Причем по критерию nor-and из списка, слабо пересекающегося с актуальной предметной областью: несколько минорных несовпадений со списком отбора, вместо целевого списка — и приплыли, даже если с целевым списком корреляция 146%.

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

Ты всего лишь возьмёшь уникальную (редкую) компетенцию.

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

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

Наверное, потому что он шёл на работу, чтобы приобретать квалификацию и зарабатывать деньги в том направлении, на которое он устроился, а не ради языковой практики? Как вы думаете?

НЛО прилетело и опубликовало эту надпись здесь

Между тем человек с 10 языками скорее всего овладел ими одинаково плохо.

Тогда и писали бы "нужен специалист по Литкоду"...

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

Сосна, дуб без вопросов. Но плотник и ореховое дерево? Красное?
Мутный тип, я бы не брал )

Или он вообще никогда не работал с фреймворками и не знает зачем они нужны

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

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

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

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

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

Плюсую, сразу скипаю такие вакухи

Иногда ещё и с тупыми тестовыми, по типу вычислить угол треугольника по 3м сторонам, ей богу, как будто не на мидла собеседуюсь, а на стажёра

НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь

Приходится в новой стране/городе заводить знакомства, что поделать ?

НЛО прилетело и опубликовало эту надпись здесь

Чтобы переехать в новую страну, нужно сначала найти там работу

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

Честно говоря, я иногда затрещину хочу дать человеку в формате: «А может, ты пойдешь поработаешь [вместо того, чтобы] рассказывать про то, как тебе комфортно или некомфортно работать в офисе?»

(c) Роман Маресов, директор по продукту в Yandex. Cвою карьеру начал со стажировки в Ernst & Young, а затем перешел на должность консультанта в McKinsey & Company, где меньше чем за два года дорос до позиции ассоциата. В «Яндекс» пришел в 2017 году во время поглощения Uber, алгоритмическое задание не сдавал.

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

Скоро и на конюшне пороть начнут...

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

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

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

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

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

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

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

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

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

Но как можно проверить вот эти вот навыки у кандидата?

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

Голос разума. Но вернее сказать - проповедь в борделе.

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

И я вот хз, что там в этой попытке решить пару задач типа "баз/физ" (или как оно там) и подобных так ломает юные дарования. Может они просто не могут? Скорее всего. А потом воют на весь интырнет о том, что да пошли они все с этими алгоритмами, ибо мы, крутые разрабы, научившиеся перекладывать джисоны и ответственность, и без них отлично живем. Детский лепет, конечно, но инфантилизм современного человека растет ближе к пупам земли семимильными шагами. И это хорошо.

НЛО прилетело и опубликовало эту надпись здесь

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

А причем тут алгоритмы, если налицо непонимание работы оператора

Понимание работы оператора как раз есть - чувак-то явно в курсе, что оператор проверяет условие, и если оно верное, то выполняет следующий код, а если не верное, то код после else,

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

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

В этом примере или грубая описка (бывает, но обычно выявляется на тестовом прогоне), или непонимание работы оператора ветвления. С условиями у него, с точки зрения перебора в лоб, все правильно ­— он выделил все необходимые к обработке случаи.
Написавший тот код не понимает, что если сложное условие в ветке else частично перекрывается условием выше, то переход в ветку не произойдет никогда. Это — работа оператора, именно она не до конца понятна автору кода.

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

Нам этот этап, если он был, не показали.

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

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

В этом примере или грубая описка (бывает, но обычно выявляется на тестовом прогоне)

Бывает, но это код в уме прогнать можно и нужно. И я не верю, что собеседующий не спросил что-то овида "а проверьте внимательно, всё ли корректно?"

Неработающий код или работающий неправильно на реализацию алгоритма, согласно определению, не тянет

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

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

Код, это и есть частный случай реализации алгоритма, в виде программы на ЭВМ

То есть, когда вам удобно — вы разделяете алгоритм и реализацию, а когда неудобно — нет.

Nuff said.

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

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

То есть, когда вам удобно — вы разделяете алгоритм и реализацию, а когда неудобно — нет.

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

Ах да, тут же аргументы нужны. Пардон. Проехали.

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

Засим бёрст на бесполезные споры закончился: вы сможете оставить пафосный комментарий в сабветке последним, чтобы все точно были уверены, кто победил. Прошу, не стесняйтесь в выражениях своей любви )

То есть, предметно вам возразить нечего

Дык эта... мяч на вашей стороне, загляните в свои ворота:

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

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

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

С этими пунктами вы согласны?

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

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

и язык тоже не алгоритм

Вообще никак не алгоритм

неправильная реализация алгоритма ≠ ошибка в алгоритме

Неправильный код ≠ неправильная реализация алгоритма. Простейшее доказательство: вот тут алгоритм сложения двух чисел на Паскале абсолютно верный: c = a + b;

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

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

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

В то же время, следите за руками: c := a - b;

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

Неправильный код ≠ неправильная реализация алгоритма

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

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

Это подмена. И кто-то, похоже, ее успешно заглотил…

вот тут алгоритм сложения двух чисел на Паскале абсолютно верный: c = a + b;

Нет. Или тут лишний Паскаль, или алгоритм.

Вот это — соломенное чучело. И дальше вы начинаете блестяще с ним бороться.

Так что ваш пас просто ушел в молоко, если немного уметь в логику. И никакого мячика на стороне каджита — нет.

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

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

  1. Неправильный код ≠ неправильная реализация алгоритма, но

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

Нет. Или тут лишний Паскаль, или алгоритм.

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

Почему нельзя, если это высказывание абсолютно корректно?

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

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

Код на Паскале, как частный случай реализации алгоритма

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

Реализация алгоритма - это частный случай записи алгоритма

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

С новым годом вас )

А в чем ошибка? Нет, конечно есть способы более эффективно проверить делимость на 5 (оканчивается на 0 или 5), что для больших х будет хорошо. Но всё-таки, чем не код джуна?

Для 15 оно сгенерирует "fizz" а не "fizzbuzz". Потому что тут вереница из if-else с не взаимосиключающими условиями. Делимость на 15 надо проверять в первую очередь.

вообще, "пахнет PHP" - почему то именно там я видел эти "лесенки" из else if-ов

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

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

И я вот хз, что там в этой попытке решить пару задач типа "баз/физ" (или как оно там) и подобных так ломает юные дарования.

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

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

Взять тот же пузырек,

Не знаю, где вы его взяли, но на интервью не просят писать пузырек. Иногда надо допереть, в каком порядке отсортировать массив и вызвать стандартный sort. Чаще просят как-то использовать стандартный же мап.

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

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

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

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

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

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

Причем жизнь регулярно же подкидывает такие задачи — совершенства ведь нет.

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

Нет, основа - это сортировка. И ее писать не просят. Просят ее использовать.

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

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

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

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

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

Одно дело, когда в работе действительно нужно умение решать алгоритмические задачи

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

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

А если в работе такие задачи не встречаются? Тогда какой смысл гонять по подобным задачам?

Для большинства мест работы - это 50% архитектура, 30% бест практикс, 10% умение просчитать пограничные случаи и 9 процентов знание языка, 1% знание О, что бы нечто типо O^2 по одному набору данных не делать.

Алгоритмы надо спрашивать там, где алгоритмы реально используются, а иначе это поиск дворника в ларек, но обязательно с высшим образованием и званием КМС по бальным танцам.

Любой булшитер сможет вас заболтать, а настоящий гений, но интроверт будет 10 минут только ээкать и нууукать.

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

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

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

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

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

А если в работе такие задачи не встречаются? Тогда какой смысл гонять по подобным задачам?

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

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

Где-то на форме контролы отображать/скрывать по сложным условиям.

Не сложнее классического физбаза.

Где-то данные будут иметь сложную структуру, и надо будет чуток обработать.

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

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

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

Чуток обработать - это далеко не найти "самую длинную подстроку первой строки, являющуюся подстрокой второй строки"

Это тоже не особо сложнее классического физзбаза. Я считаю, что не нужно требовать от соискателя наизусть помнить все структуры данных, вроде красно-чёрных деревьев, как написал @sergey-gornostaev чуть выше, но если задачка не требует вообще ничего, кроме как чуть поработать мозгами, почему бы её не задать?

Основная проблема - это время. Имея всего час на техинтервью, нужно проверить базовые знания языка, базовые знания архитектуры, базовые знания в области/основных библиотеках, опыт работы, да еще и успеть оценить кандидата как человека, на сколько хорошо он впишется в команду. При этом 5 минут в начале занимают расшаркивания и знакомства и еще минут 10-15 в конце занимают вопросы кандидата.

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

И т.к. люди на ТИ приходят именно как на экзамен, то выдернуть из этого состояния человека очень тяжело. Что я в ГЭКе в универе много лет сидел на защите дипломов, что я ТИ проводил. Возраст у людей вроде разный (и не всегда в пользу ITшнеков), опыта за плечами много, а поведение и состояние очень похожее. Так и ждешь в ответ на вопрос фразы "во валит, гад". И не дай бог он закуклится, как студент, и в молчанку играть начнет. Если студент после такого получит диплом и исчезнет, то у кандидата можно и адового токсика просмотреть. Прямо удивительно порой, как люди могут меняться, после того как скорлупу сбрасывают.

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

ЗЫ. Так, Остапа опять понесло немного не в ту степь, извиняюсь, стирать лень.

Под алгоритмическими задачами далеко не физбазы понимаются

Вообще-то именно они, если мы рассуждаем в контексте собеседований.

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

Именно физбазы и проверяются. Задачки сложнее ни кто не дает, за редчайшим исключением.

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

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

PS. На работе "физбазы" как раз применяются постоянно, ибо даже простые табличные круды покрываются ифами для отлавливания пограничных состояний. ))

Собственно, все задачи класса "а как это сделать", это и есть физбаз чистой воды.

>Большая часть литкода - это далеко не физбазы

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

Весьма специфично, но главное в том, что не понятен фактор мотивации. Время выполнение кода? Расход памяти? Запросы?

Напомнило мне одно из своих "просранных" собеседований, где я показал код скомпилированный в 19098 байт на TMTPascal и расходующий 9921855 байт памяти, но победило какое-то чмо с кодом на C#, с расходом памяти в 2 гигабайта.

Если там была вакансия по C#, то результат выглядит закономерным..

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

во вторых а нужна ли была оптимизация? я как то в конце 2000ых разрабатывал умные часы на 16кб флеша и 4кб озу и просто написал с нуля простенькую либу визуальных компонентов и их рендеринга, оно потребляло менее 10мА от часовой батарейки-таблетки и с оптимизацией даже тогда я не парился вообще, просто надо было написать аккуратно и без излишеств и свисто-перделок. Зато отлично понимаю что оптимизация порой путь в один конец, способ сделать код нечитаемым и не поддающимся правке другими из твоей команды. А исходный код он не для CPU/MCU код в основном для команды и для тебя в будущем.

НЛО прилетело и опубликовало эту надпись здесь

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

А почему именно TMTPL из девяностых? Активный пользователь OS/2? На момент C#/2Gb были популярны уже совсем другие языки программирования.

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

Не тратьте впустую ценное время кандидатов

Изучение алгоритмов, это время потраченное не впустую.

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

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

Да теоретически все возможно. А на практике как часто проекты проваливались из-за неправильных алгоритмов?

А на практике я видел легаси на Struts2 framework, Coherence кластеры связанные в спагети из его процессоров и несколько проектов реинжениринга которые умерли раньше системы которую пытались модернизировать, видел код состоящий из всех возможных паттернов, очень хорошо покрытый тестами всех возможных в компании перед банкротством, слышал в лифте разговор интервьюверов которые не понимали зачем они задают вопросы про последний стандарт C++, надувают щеки перед кандидатом и собеседуют в много этапов и с алгоритмами как в гугл, если их легаси система собирается только под 32разрядную x86.

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

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

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

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

Ну вот и сколько раз в жизни у вас такая потребность возникла? И сколько у вас было время на это? А профессиональная судьба ваша зависела от этого?

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

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

Заранее конечно нет, но некоторая базовая подготовка как правило сильно сокращает сроки оного РНД.

У нас тут в соседнем проекте напряглись

Знаком с людьми из QuestDB и из ClickHouse и изучал исходники этих проектов. Но такая работа единичная на рынке, а желающих обычно стоит очередь.

Есть что почитать про ваш графовую реализацию?

НЛО прилетело и опубликовало эту надпись здесь

Ваша поделочка была быстрее? Почему вы её ещё не продаете-то?

Я не автор, но с похожими ситуациями сталкивался.

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

Иными словами, оно будет работать быстрее, но только здесь и только с этими данными. Тогда как универсальная библиотека быстра "в среднем" и именно в данных условиях и именно с этими данными не так быстра как хотелось бы.

НЛО прилетело и опубликовало эту надпись здесь

А вы думаете, что авторы не пробовали эту вашу neo4j? Пробовали конечно, все что существовало на тот момент. Не устроило. Я не настолько знаком с ситуацией, чтобы детальнее комментировать, поэтому и не стану с вашего позволения.

Почему вы её ещё не продаете-то?

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

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

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

... или графовый алгоритм эффективнее чем он есть в доступных библиотеках.

Ну я делал. Java. И это было более чем оправданно. Обычно если у вас очень высокие требования по памяти/скорости, то не нулевая вероятность не найти готовое решение именно под ваши данные.

НЛО прилетело и опубликовало эту надпись здесь

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

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

В качестве языка запросов был написан свой вариант Apache Gremlin который поддерживает параллелизацию и GC free.

Выигрыш по памяти - х10

По скорости запросов - х20

НЛО прилетело и опубликовало эту надпись здесь

Почитайте, пожалуйста, что такой Apache Gremlin для начала.

Затем да. Если нет нужды во всех функциях Neo4j, то зачем тащить его в проект? К чему ваши претензии?

Инфа соточка

Конечно я вам верю. Т.к. имел возможность общаться с авторами Neo4j и OrientDB и отправлять патчи на рассмотрение.

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

1) Часто библиотек нет. Вот задача и такие на интервью дают часто. В задаче надо лишь в нужное место впендюрить map. Это слишком частный случай для библиотек.

2) Даже если библиотеки есть, их нельзя нагуглить, не зная ключевые слова. Например sliding window max (а эту задачку с литкода мне приходилось в прод коммитить).

3) Еще чаще вы даже не заметите, что тут нужен "сложный алгоритм". Потому что даже на литкоде большинство задач сформулированы "сделайте то-то и то-то" и можно буквально перевести условие в очень неэффективный код. А когда вам даже условие не дано, задача стоит - запилить фичу, то у вы в голове сформулируете "надо сделать то-то и то-то", и это у вас будет решение, а не задача.

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

Я вам практические примеры из личного опыта привел.

На практике в трёх крупных финансовых организациях я неоднократно видел как системы под чуть возросшей нагрузкой заваливались из-за "квадратов". Причём некоторые моменты весьма похожи: несколько "квадратов" на последовательной конкатенации строк, несколько на поиске в списке/массиве/таблице, которые пополняются в цикле.
Завалился ли из-за этого какой-то крупный проект? Нет. Если один неосторожный разработчик может завалить неэффективным локальным кодом весь крупный проект, то проблема точно не в разработчике.
Были ли заметные финансовые потери? Да. И явно несопоставимые даже с несколькими месяцами работы разработчика.

Завалился ли из-за этого какой-то крупный проект

Как пример из реальной жизни. Крупный банк. Внедряется патч. Вроде как в штатном режиме все работает, все оттестировано. Но... Наступает время пиковых нагрузок (предновогодняя суета и массовый шопинг). И... Патч начинает жрать ресурсы процессора, тормозить сам и все что с ним связано. В результате миллионы клиентов по все стране не могут в магазинах расплатиться картами банка - "нет ответа от банка". У кого-то с 3-5-го раза получается, у кого-то не получается вообще. Сопровождение в мыле откатывает патч, налаживает WA. Решили часа за два все, но эти два часа были адом для всех.

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

Вот считать это "завалом крупного проекта" или нет?

Вот считать это "завалом крупного проекта" или нет?

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

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

Обычно перформанс деградирует медленно, по мере увеличения кодовой базы, наростания слоев абстракций и каких-то костылей. У вас просто нет какой-то понятной точки, которую можно переписать с O(n^2) на O(n log n). Для того, чтобы с этим бороться нужно в первую очередь хорошо знать код своего проекта. При оптимизации вы оперируете не функциями, а компонентами или даже микро-сервисами.

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

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

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

Автор кода, который реализовывал задачу, доставал, скорил, вызывал .sort(), потом .slice(0, 100). Код был читабельным, работал за O (N log N). Автор заявил "ну оно ж влезает в память" и был прав. Всё вычисление повторялось и для второй страницы, только брался следующий slice из результата.

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

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

И тогда настал мой звёздный час как задрота литкода: я модифицировал k-th order statistic (работает за O(n)), чтоб она ещё могла порционно данные подгружать и не ломаться. Сервис заработал, код стал трудночитаемым неподготовленным человеком.

К чему всё это:

  1. Поймает ли тут проблему регрессионный тест или перформанс тест, если код не был ухудшен, а был изначально "плохо" написан?

  2. Считаем ли этот код "плохим", если на момент его создания он вписывался в имеющиеся требования, а новые требования сформированы были через год в связи с ростом сервиса?

  3. Окей, мы узнали, что код не вывозит. Что делать, если у нас нет leetcode-задрота? Просить начальство удвоить память на серверах в дц? а с O(N LogN), которое не укладывается в таймауты запросов что делать?

  4. За 7 лет работы это был один конкретный случай, где мне пригодилось знание, как самому организовать сортировку быстро. Стоит ли ожидать такое знание от всех кандидатов? до сих пор не могу ответить себе на этот вопрос.

Окей, мы узнали, что код не вывозит. Что делать, если у нас нет leetcode-задрота?

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

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

Верно ли, что тогда мы считаем обязательными понимание medium-алгоритмов с литкода или хотя бы информированность о подходах к их решению?

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

Почему бы просто не взять классическую книгу Кнута?

А там уже есть поиск? Быстрее тогда уже у gpt спросить

А потом пришёл унылый ПТУшник и реализовал это же одним запросом в БД или пайплайном спарка, собранным из готовых компонентов?

то есть всё-таки просим у начальства второй датацентр под бесконечные сортировки на спарке?)

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

Окей, мы узнали, что код не вывозит. Что делать, если у нас нет leetcode-задрота? Просить начальство удвоить память на серверах в дц? а с O(N LogN), которое не укладывается в таймауты запросов что делать?

Тут скорее не литкодовец нужен, а человек с "архитектурным мышлением".

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

В результате повысили производительность не одного, а многих процессов. Ценой небольшой доработки на один-два дня. А литкодовец условный начнет выжимать + 20% за счет накрутки хитрых алгоритмов которые обойдутся в +80% сложности кода для одной конкретной задачи.

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

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

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

У вас просто нет какой-то понятной точки, которую можно переписать с O(n^2) на O(n log n).

В данном случае она будет. Есть временное окно, в которое должен уложиться какой-либо процесс ("процесс" здесь общее понятие, на самом деле это может быть и цепочка связанных процессов). Пока у вас в системе N клиентов, все укладывается с запасом. По мере роста количества клиентов (1.1хN, 1.2хN...) ваш процесс начинает потихоньку подбираться к границе отведенного для него временного окна (а есть еще допустимый процент утилизации процессом ресурсов CPU - он тоже может расти). И в один прекрасный момент бах! и вы начинаете вылазить за пределы окна. Что недопустимо для всей системы в целом - ваше временное окно увязано на временные окна других процессов.

К сожалению, этой ситуации не избежать - рано-поздно оно случится все равно, но тут вопрос в том - а как скоро оно случится? Одно дело, вы сразу сделали все оптимально на 80% (те самые условные 80%, которые достигаются увеличением стоимости на условные 20%, следующие +20% производительности повышают сложность разработки уже на 80%) и у вас есть запас до 3хN (условно, 5 лет). Другое дало, когда "херак-херак, абы как и в продакшн" и запас у все мизерный - 1.3-1.5хN и через год (условно) вам придется опять все переделывать.

А на практике как часто проекты проваливались из-за неправильных алгоритмов?

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

Легко.

У меня (и не только у меня) в работе сейчас дополна задач по исправлению "дефектов производительности промсреды". Когда-то, когда клиентов было 20-25млн, все это укладывалось в заданные временные окна. Сейчас, когда клиентов стало 50млн оно "вдруг" перестало укладываться. И само тормозит и задерживает смежные процессы

И вот смотришь код и думаешь - ну вот как там можно писать-то было? Вообще ни о чем не думал? Все просто тупо "в лоб". Даже без мысли "а нельзя ли вот это быстрее сделать?"

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

Иногда в угоду бизнеса и\или на стадии MVP вводятся фичи как можно скорее, а об оптимизации потом подумаем.

У нас такое не проходит, к счастью. Есть "встанет" центральный сервер банка, то никакие фичи уже не спасут.

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

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

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

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

Чем вы и занимаетесь. КМК это вполне грамотный подход.

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

Чем вы и занимаетесь. КМК это вполне грамотный подход.

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

Вот есть некий бизнес-процесс. Очень ресурсоемкий. Временное окно под него 4-5 часов. Когда-то давно так и было. Но сейчас не укладывается - занимает 12-15 часов. Переделываем. Сейчас получаем в пределах часа (обычно 20-30 минут - чего это стило отдельная тема). Т.е. имеем очень большой запас.

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

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

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

Как правило, сложность кода не волнует никого. Волнует как он работает.

Да и 80% оптимизации значительно код не усложняют. Усложняют последние 20% (а то и меньше).

Оно неизбежно

Более 90% IT-кампаний столько не протянет

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

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

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

Ну... На нас бизнес не давит в плане скорости разработки. Потому что наша позиция - "вы хотите чтобы быстро, или чтобы рукава одинаковые?". Им нужно чтобы работало корректно и быстро. Тут вопросов нет - центральные сервера банка - это не фичи. Это мастер, mission-critical, мать ее, система.

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

У нас таки чаще речь о процессах, которые дергаются сотни миллионов раз в сутки. Или, даже если раз в сутки, то работают с десятками миллионов элементов (а есть процессы сравнения 50млн элементов с 300-500тыс элементов по 5-7 разным параметрам) и при этом имеют жесткие ограничения на время выполнения и потребляемые ресурсы процессора.

И там речь не о секундах, а о часах как правило.

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

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

НЛО прилетело и опубликовало эту надпись здесь

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

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

Об опасности вложенных циклов знали еще в 60-е годы, когда никаких алгоритмических задач не было.

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

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

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

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

PS Я не оправдываю 3 вложенных цикла, я скорее про сам подход. Что сейчас смотря назад можно много негативного думать про код, но он писался в других условиях и контексте )

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

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

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

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

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

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

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

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

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

понаписал квадратов на ровном месте

Только надо иметь в виду, что асимптотика важна только на большом количестве элементов. Если у вас их 10 штук, сойдёт даже экспоненциальная сложность.

Если у вас вход контролируемый, то может и сойдёт. А если это может сделать внешний пользователь, то можно на DoS нарваться.

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

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

https://tech.slashdot.org/story/13/12/16/1959259/exponential-algorithm-in-windows-update-slowing-xp-machines

https://arstechnica.com/information-technology/2013/12/exponential-algorithm-making-windows-xp-miserable-could-be-fixed/

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

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

В итоге там, как правило, замечательные вещи:

  • запросы к базе внутри цикла, который тоже внутри цикла - на сотни элементов каждый

  • запросы на массовое обновление записей в базе - без транзакций

  • использование вызовов api (с запросами к базе) вручную там, где этого можно было избежать просто поставив правильный параметр в вызове базового компонента

  • использование api способом, про который прямо написано в документации крупными красными буквами на выделенном фоне, что так делать не нужно

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

  • и еще многое-многое другое

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

Уверен, все эти люди вполне успешно проходили собеседования)

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

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

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

НЛО прилетело и опубликовало эту надпись здесь

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

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

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

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

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

Да, такое повсеместно есть. Вот например, простое grud приложение для локала, но используется в нем php, pyton и postgres, Web server. А все потому что разработчик решил на нем поизучать pyton и кроме php ничего не знает. Ни php ни pyton там вообще не нужен. Этого разработчика давно нет в конторе а приложение живёт своей жизнью и постоянно глючит, сбоит и тп. Там же приложение для настройки приборов сделано на C# а в качестве БД используется файл xml. Представьте, что разработчикам внутреннего софта нужно ещё редактировать тысячи строк xml файла с нехилой вложенностью. Этого разработчика тоже уже нет в компании, все придожение переписано под БД и добавлен человеческий интерфейс редактирования конфигурации прибора, сетевая и локальная версия под sqlite. Отдельно был квест с автоматическим переносом существующих 50 xml файлов сложной разной стуктуры в бд. Но в общем все получилось через специальную встроенную процедуру на сервере.

Пришлось придумать свой алгоритм переноса в таблицы без потери связи, так как структура xml варьировалась от файла к файлу. И это под sql кодом. В общем даже можно статью об этом написать, может кому пригодится.

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

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

ну эти примеры явно не про алгоритмы, а скорее про архитектуру

По поводу избыточных запросов - тут палка о двух концах.

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

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

Мне кажется, было бы интересно, если кандидату давалось задание оптимизировать там пару алгоритмов. Ну то есть, дается решенная кое как задача из леткода. Код рабочий, но он O(n^2). Кандидат должен определить "проблемы" в коде и исправить их доведя в идеале до О(1). Мне кажется – это позволит оценить мышление кандидата, а не просто насколько он зазубрил алгоритмы или типовые задачки.

Именно это и происходит на алгособесе, только O(n^2) тоже самостоятельно написать надо.

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

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

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

Так это и есть "задача с литкода". Вот, практически такая же: https://leetcode.com/problems/kth-largest-element-in-an-array/description/
А вот еще задача на удаление дубликатов из массива: https://leetcode.com/problems/remove-duplicates-from-sorted-array/description/

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

Так это и есть "задача с литкода".

А если на литкоде будет FizzBuzz и меня попросят его написать на собесе то я могу впоследствие говорить что я прошел литкод собеседование?

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

Ну так согласуйте контекст что такое "задачи с литкода" а то глаза устают от белизны пальто.

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

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

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

Много раз у вас такое на сабеседовании спрашивали? А вы часто такое спрашиваете? В подавляющем большинстве случаев речь про easy-medium, которые в спокойной обстановке программист способен решить за 5-7 минут, но с учетом стресса и доски на собесе даётся 20-30 минут.

Но нет, кто-то слышал как соседа брата жены в гугле dp hard спросили и сделал далеко идущие выводы, что алгособесы это плохо.

В подавляющем большинстве случаев речь про easy-medium, которые в спокойной обстановке программист способен решить за 5-7 минут, но с учетом стресса и доски на собесе даётся 20-30 минут.

Просто стало интересно, а вы сами решаете задачу, которую даете на собеседовании?

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

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

PS: Про автопилот для парусной лодки, это была попытка пошутить. Видимо не очень удачная)

Я бы на каком-нибудь C++-е в жизни бы не вспомнил, как обходить мапу.

Должен я просто написать
for (entry: map)
или должен ваять что-то типа
for (entry: map.entires())

И если второй случай, то что возвращает entries()? Аллоцированный массив элементов?

Или в каком-нибудь расте, можно ли обойти таким способом хэшмапу? Там вроде специально запрещено это

easy-medium, которые в спокойной обстановке программист способен решить за 5-7 минут, но с учетом стресса и доски на собесе даётся 20-30 минут.

Я проваливал на собеседованиях даже простые задачи. Здесь как в вузе. Если тема находится прямо сейчас в голове, то задача решается на рефлексах. Но через год уже нужно напрягать голову, что вспомнить. Через 20 лет это не немного грустный челенж. При этом вечером, когда есть возможность войти в поток и спокойно подумать, все решается действительно легко и без подсказок из гугла.

А если на литкоде будет FizzBuzz 

В смысле "если будет"?

https://leetcode.com/problems/fizz-buzz/

собственно, в 99 случаях из 100 "литкодовские задачи с собеса" - это вот и есть что-то уровня физзбуза.

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

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

А вам лично задачки на дп задавали на собесах? Или вы знаете людей, которым задавали? Или которые задают?

Я вот - нет.

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

Кстати, физбуз физбузу рознь. Вот такой запросто может приземлить кандидата (конечно же, давать подобное не рекомендуется - это ещё более спорный "жанр", чем то что здесь обсуждают).

А в чём сложность в указанной вами задаче?..

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

Если честно, то посмотрев на варианты решения мне кажется проблема не в задаче, а в языке :) :)

например найти N наибольших чисел в массиве, а потом спросить про вычислительную сложность решения

Но это и есть баянистая задача на интервью во всякие ФААНГИ. Это кровь и плоть от этих презираемых тут "алгоритмических задачек". Можно, конечно, просто обсудить, как бы кандидат это решал, а можно после этого потратить еще 10-15 минут на написание кода. Заодно можно посмотреть, что кандидат может свои мысли перевести в код, а не только случайным образом менять исходник, пока не заработает.

Интересно, есть хоть один язык программирования, в стандартной библиотеке которого heap sort уже не реализован?

JavaScript.

Вряд ли их очень много, но в C++ - реализован. Ну, правда, придется руками вызвать make_heap и в цикле pop_heap. Но в этой задаче и не надо heapsort делать, а надо лишь heap использовать. Который в огромном количестве языков есть (тот же priority_queue в C++).

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

весь софт теперь на электроне написан

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

Искренне не могу понять корреляцию. Если что мой стек сейчас Go.

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

Понимаю что не в тему, но я для себя нашел замену электрона в "лице" wails (golang).

НЛО прилетело и опубликовало эту надпись здесь

Везде есть оптимальная середина. Так что это нормально, что люди критикуют крайности.

Электрон писали какие-то неумехи, не знающие алгоритмов?

Без понимания, как оно всё работает, можно выбрать, например, библиотечный, но нестабильный алгоритм сортировки

Так а просто поговорить про стабильность сортировки и случаи, когда это нужно, а когда нет, почему нельзя? Ну поговорите на собеседовании про алгоритмы и структуры данных если это важно и критично на вашей работе. Если человек плавает и не знает чем отличается связный список от массива, то вы сразу сделаете для себя выводы. А если он знает и понимает, он возьмёт готовое и применит как надо и где надо. И не нужно ему мозг выносить и считать за дурака, потому что он не смог за 30 минут решить на бумажке какую-то хитрую задачу с литкода.

Если вы, например, занимаетесь прикладным ПО, в чём смысл задрачивать кандидата на реализацию очередной кучи и очереди с приоритетами для слияния отсортированных списков, чтобы что? Что это вам даст, что вы узнаете о способностях кандидата? Как вы поймёте, может он вам подойти или нет? Просто поговорить о таких вещах какая-то особая религия не позволяет? Собеседование - это от слова беседовать, ведь правда?

Зачем, казалось бы, умные люди превращают собеседования в идиотизм и дурдом? Давайте устроим 5 одинаковых сессий на алгоритмы как в Яндексе делают. А что такого? Такие собеседования просто не работают, не говоря уж о потраченном времени и стрессе, который от них испытывают кандидаты. Это нонсенс.

Что это вам даст, что вы узнаете о способностях кандидата?

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

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

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

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

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

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

Для этого и существует испытательный срок для сотрудников.

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

Почему?

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

Потому что увольнение на испытательном сроке, это всегда потери, и временнЫе, и материальные. И для компании, и для работника. И на них идут лишь потому, чтобы не понести ещё большие потери в будущем.

Так пока человека не взяли потери тоже есть: работа, которую мог бы делать кто-то не делается вообще! Это тоже временные и материальные потери. Как доказать, что потери от испытательного срока в общем случае больше, чем потери от того, что работа не выполняется, а специалисты тратят время на собеседования, а не на свою работу?

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

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

И это же время будет потеряно и для самого кандидата. Т.е. в минусе окажутся все.

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

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

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

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

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

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

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

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

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

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

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

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

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

Нет, тесты проверяют некоторые параметры, которые _скоррелированы_ с тем, что нужно на работе. В этом смысл тестов per se, как я выше и указал.

Но, если даже и проверять способность подготовиться

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

Что именно всё?

Так не надо знать все, надо уметь писать код на уровне школьника, который не прогуливал уроки информатики.

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

Вообще, вы не совсем понимаете, почему в принципе современные собеседования такие, какие есть.

hint: потому что профессиональная культура и, как следствие, уровень кандидатов, в какой-то момент опустились до уровня дна.

20+ лет назад, когда от джунов требовали знаний и навыков существенно более серьезных, чем сейчас есть у иных сеньоров, собеседования были совсем другие, ни кто там физбузы писать не просил. Это было бы просто смешно. Задавать такие вопросы специалисту? Нонсенс! Оскорбительно.

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

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

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

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

Это уже когда-то было:

Google: 90% of our engineers use the software you wrote (Homebrew), but you can't invert a binary tree on a whiteboard so fuck off

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

Человек, задрочивший литкод - это просто человек задрочивший лидкод

Еще раз - мы говорим о корреляциях, а не о причинно-следственной связи.

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

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

Что всех так прямо клинит на этих деревьях? 

Это просто хороший, прямо таки канонический пример задачки, которая легко отсеивает самозванцев.

Часто вам деревья вращать приходится?

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

Даже тем, кто занимается разработкой СУБД не приходится это делать, зачем такое спрашивать на собеседовании?

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

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

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

Разве такие были? Можно хоть один пример?

НЛО прилетело и опубликовало эту надпись здесь

Разве такие были? Можно хоть один пример?

Я же привел цитату создателя Homebrew :)

Создатель Rubi on Rails:

Hello, my name is David. I would fail to write bubble sort on a whiteboard. I look code up on the internet all the time. I don't do riddles.

Какой-то инженер из Google:

Hi, I'm Yonatan. I'm one of Google's most senior engineers, and I'll be damned if I can remember how quicksort works.

Там много таких примеров в twitter-треде.

Создателя WhatsApp Яна Кума не взяли в Facebook, он завалил собеседование. А потом Facebook купил WhatsApp за 16 миллиардов долларов.

Я же привел цитату создателя Homebrew :)

В случае с ним - это как раз хороший пример самозванца. Что даже сам автор Homebrew впоследствии признал.

Там много таких примеров в twitter-треде.

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

Опять же - вон Дэвид, по крайней мере, _знает_, что такое бабл сорт. А автор хоумбрю не знал, что такое бинарное дерево.

Создателя WhatsApp Яна Кума не взяли в Facebook, он завалил собеседование. 

По какой причине завалил?

 А потом Facebook купил WhatsApp за 16 миллиардов долларов.

Но это это же вообще ни чего не говорит о навыках Кума как разработчика.

Я напоминаю - мы говорим о _разработчиках_. Не об аналитиках, не о маркетологах, не о прожект менеджерах. О разработчиках.

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

С чего Вы так решили?

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

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

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

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

> Google: 90% of our engineers use the software you wrote (Homebrew), but you can't invert a binary tree on a whiteboard so fuck off

Что всех так прямо клинит на этих деревьях? Часто вам деревья вращать приходится?

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

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

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

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

Вот недавный пример с Маском. Знаменитость-знаменитостью, все его гением величайшим считали. А потом чувак ляпнул неподумав так, что ему пришлось 44 лярда за твиттер выложить. Пришел туда и стал лихорадочно пытаться деньги вернуть, обножая недальновидность: похоронил бренд, который просто культурный феномен! Много компаний создали глагол типа "твиттить", использующиеся по всему миру? Он умножил на ноль галочки верификации, уничтожив все доверие к платформе. А историю, где он просил принести ему распечатки своего кода помните? Ну не чувствуется тут гений, которого надо с руками отрывать в любую компанию.

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

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

НЛО прилетело и опубликовало эту надпись здесь

Солидарен с вами. Помню когда начал изучать Ruby on Rails, то был удивлен как на нем можно быстро делать решения вообще не зная Ruby.

И в последствии я встречал очень много людей которые годами пишут на RoR, но вот ничего не могут написать на Ruby вне этого фреймворка.

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

ну спорно, тот же Каспаров сказал - "Игра в шахматы развивает только умение играть в шахматы"

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

Это одна из причин, как мне кажется.

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

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

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

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

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

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

Это две крайности, есть объективные критерии и есть субъективные. Полностью переходить на субъективные тоже плохо - буду нанимать "талантливых и нестандартных" своих друзей и родственников. Тут же ещё вопрос в доверии руководства к тем кто нанимает.

>и как из-за этого всё будет весело работать у клиента

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

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

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

А если для нас избавление от излишней сложности — самоцель

Демагогия. Ложная альтернатива

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

И чего, по коду всех используемых фреймворков и библиотек тоже пробегаетесь, чтоб определить "проблемные места"?

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

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

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

Вы будете удивлены, но да! И даже, бывает, в исходники компилятора заглядываем. А некоторые даже под капот CPU залезают:

https://habr.com/ru/articles/778026/

Уметь определять производительность без замеров — действительно магия

Даже немного завидую вам. Живёте в мире с магией. Эх, мечта.

Я читаю код всех библиотек, что использую. И мой текущий проект держит 200к запросов в сек. При этом всё это использует всего 7Мб памяти. И не подвисает пердически из-за работы GC.

А потом на код ревью приходится объяснять человеку, что он понаписал
квадратов на ровном месте и как из-за этого всё будет весело работать у
клиента.

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

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

В смысле, испытательный срок? Вы предполагаете, что так делают только те, кто пришел в команду?

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

В смысле, испытательный срок?

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

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

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

И вы эти заблуждения приписываете всем оппонентам? Есть также заблужддение, что если человек написал в резюме, что он умеет программировать, то он и правда это умеет. У меня на собеседованиях часто всё заканчивается на задаче: распечатайте в консоль словарь, в котором ключи строки, а значения числа. Часть кандидатов не могут и этого. Вы можете говорить что угодно, но никогда не убедите меня, что человек с 5+ годами опыта на самом деле отличный программист и всё это умеет, просто у него стресс.

И вы эти заблуждения приписываете всем оппонентам?

...

никогда не убедите меня, что человек с 5+ годами опыта на самом деле отличный программист и всё это умеет, просто у него стресс

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

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

НЛО прилетело и опубликовало эту надпись здесь

Я не могу без гугла или без IDE. В питоне вот можно просто print(dict), в Java, уже сложнее, надо в цикле пробежаться по мапе. Сигнатуру for я знаю. Какой метод у Map? getEntries()? entries()? И вот я открыл IDE, оказалось, что метод называется entrySet(). Должен ли я это знать наизусть?

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

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

Должен ли я это знать наизусть?

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

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

Так подгорело, что аж зарегистрировался, а если человек интерируется обычно по списку, вот такой вот он странный, а по словарю раз в год, то что он без IDE должен помнить, что dictionary реализует ienumerable? а на собеседование стресс как говорилось, и он такой сидит и думает, а задачка то наверное с подвохом, и итератор есть у списка, а у словаря нет, а если уточню у интервьюера, то сразу в дураки запишет, вот как так может быть

System.out.println() вроде принимает Object, да и у стандартных реализаций Map человечески переопределен toString(), так что тут особой разницы между жабой и гадюкой Java и Python нет

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

Когда кандидатов на одно место порядка 40, то это уже не важно - могут хоть ламбаду заставить танцевать и стишок на табуретке прочитать (привет, поиск работы на .NET в Германии в 2023 без немецкого).

И вы эти заблуждения приписываете всем оппонентам?

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

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

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

И, вполне возможно, они правы. Преждевременная оптимизация - зло.

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

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

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

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

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

Почему? Требования изменились. Код тоже нужно поменять. Это нормально. Почему вы грустите?

Если бы всегда, когда требования меняются не нужно было бы менять код - программисты стали бы не нужны. Зачем нам это? :) так что живём дальше и радуемся, пока можем :)

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

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

  1. Цикл в цикле это не всегда плохо.

  2. Цикл в цикле даже не всегда увеличивает асимптотическую сложность.

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

И вот чтобы это понимать, нужно владеть теорией.

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

добавлять что-то к началу массива

Достаточно почти любой операции с zero-terminated string в цикле;)

Да много чего достаточно, всё перечислять смысла нет.

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

В этом и проблема таких собеседований.

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

а собеседующий, которому очень хочется показать

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

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

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

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

Ну и, наконец, как бывший препод и нынешний интервьювер, вы можете хоть на секунду представить, что общаетесь с человеком, который и обучением занимался, и получал самые сложные задачи в потоке в университете на алгоритмическом курсе потому, что "так ты обычные за 10 минут решишь и думать даже не будешь, сиди, развивайся", и который уже 6 лет собеседует людей в свою и смежные команды?

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

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

Это ваш вот этот комментарий так написан. А мой написан уставшим тоном.

Где здесь я сказал о вас что-то плохое?

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

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

НЛО прилетело и опубликовало эту надпись здесь

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

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

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

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

Не пролетают, для этогно есть секция ОО дизайна.

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

А об этом вы поговорите на секции системного дизайна.

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

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

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

Знание алгоритмов там вторично, на самом деле

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

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

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

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

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

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

Согласен, пока это про простые и интуитивные алгоритмы уровня "прицепи побольше hashmap'ов" и подобные, но когда идут задачи, которые не решаемы без знания подхода, по типу DFS или подобного, то это не связано с работой.
В работе не юзают рекурсию, потому что у нее в популярных языках ограничен стек, в целом рекурсию и протестить тяжело, и поддерживать, а многие middle/hard задачи не такие уж и сложные, но если не знаешь всякие DFS/мемоизации/backtracking и тп, то могут быть в принципе не решаемыми.
Пример - найти все возможные пермутации чисел из списка. Зная как такое решается - решается мгновенно, не зная - не решается в принципе.

Coding Challenges – отличный ресурс с задачами, подходящими под эти требования.

Открываем список тем: "Write Your Own Compression Tool", "Write Your Own Sort Tool", "Write Your Own Calculator". Ближе к концу: "Write Your Own Lisp Interpreter".

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

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

Step 3
In this step your goal is to allow the user of your sort program to select which sort algorithm to use. Checking man sort, we see that the standard Unix version offers radix sort, merge sort, quicksort and heapsort.

Step 4
In this step your goal is to implement random sort.

Сколько из них есть в стандартной библиотеке того же Питона?

Сколько из них есть в стандартной библиотеке того же Питона?

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

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

Let the срач begin! :D

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

Зависит от конторы.

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

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

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

зы Вот Just 4 Fun этот литкод погрызть под настроение - это можно, там занятные задачки попадаются. )

Литкод - зло (хотя сам я его люблю иногда порешать).

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

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

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

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

Единственный аргумент, который я слышал в пользу алгоритмов – это проверка интеллекта разработчика. Типа если он лутает алгосы, то и всякие реакты легко освоит. UPD: Но я с этим не согласен если что)

Типа если он лутает алгосы

А если ещё и русским языком владеет -- так вообще красавчик!

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

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

Ну, например, мне нужно было собрать некие данные - свойства объектов - вместе, позволить пользователю указать, какие свойства собирать и в каком виде объединяя свойства (своство1 - свойство2 - свойство Н) или собирая из них иерархию свойств. И я плохо представляю, как это сделать, не владея базовыми алгоритмами.

И да, было как-то развлечение, когда ФМС еще предоставляла файло с сотней миллионов недействительных паспортов. И пока все мучились, засовывая это г-но в свои СУБД, я просто построил битовую матрицу, которая формировалась за время скачивания архива с интернета и имела О(1) по эффективности вставки/поиска. Да, чертовы алгоритмы позволили не тратить часы времени на перекладывание CSV в базы данных с последующими селектами. Полная матрица занимала бы 1,25 Гигабайта, что для современных приложений ниачом, но т.к. половина серий еще не выдавались, то реально все занимало 600 метров и крутилось на какой-то репке пиай...

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

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

Например, попробуйте сосредоточиться на сигналах такого рода:

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

НЛО прилетело и опубликовало эту надпись здесь

(AlphaDev предложил алгоритм, который производит сортировку на 70% быстрее, чем существующие, для библиотеки libcc++)

Но есть нюанс: 70% - для последовательностей из пяти элементов. А в целом, новые алгоритмы сортировки AlphaDev на C++ на 1.7% эффективнее предыдущих методов при сортировке длинных последовательностей чисел.

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

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

Особенно если в стандартной библиотеке ЯП есть куча

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

Рискну быть заминусованным, но...

Если к вам прибежал менеджер с криком "Караул, все пропало, нужно срочно реализовать нашу Супер-Пупер-Новую-Функцию. У вас 30 минут, а то все уволю нафиг." Вы будете пытаться оптимизировать алгоритм до О(1) (ну в идеале) или "фиг с ним, пока и О(n^2) (ну да, другая крайность) сойдет, потом в спокойной обстановке исправлю". Просто хотелось бы услышать мнения.

Если ко мне прибежал менеджер с криком "Караул, все пропало, нужно срочно реализовать нашу Супер-Пупер-Новую-Функцию. У вас 30 минут, а то все уволю нафиг", я пожму плечами и предложу ему написать её самому, а потом спрошу у директора, зачам наняли этого психа. В общем, эта задача лежит не в технической плоскости, а в социальной :)

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

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

Если перефразировать вопрос, то суть от этого не сильно поменяется.

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

В реальности такие вещи бывают, конечно, но это не про супер-новые-функции, а про хотфиксы.

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

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

У вас 30 минут, а то все уволю нафиг

А потом через пару недель: "ну чо там как по той задаче?"

В общем, эта задача лежит не в технической плоскости, а в социальной :)

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

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

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

Это нереально.

Реальный сценарий - это когда вы просматриваете какие-то там логи, которых сотни мегабайт, в попытке понять, почему и что происходит не так в сервисе. В процессе этого набрасываете наколеночные скрипты на bash/python. Из-за большого кол-ва данных какие-то алгоритмические оптимизации, вроде вставки в конвейер sort -u, делать разумно. Также разумно не писать квадраты, а ограничиваться, по возможности, алгоритмами с O(N).

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

Я вообще не понял: вопрос задан так, будто знание алгоритма решения задачи делает решение задачи медленнее, чем не знание. Эээ... Это что сейчас было? Видимо имелось в виду, что некогда учить и применять алгоритмы на ходу. Но извините, речь о том, что алгоритмы надо знать на входе, именно в этом суть. Если в компанию берут без оглядки на алгоритмы, а потом вы отказываетесь в ситуации, в которой описали, то почему вопрос с претензией к алгоритмам поставлен? Я Вас удивлю, но алгоритмы всегда выглядят короче, эстетичнее, чем сумбурный код O(n^2). Какой-то алгоритм Дейкстра на графах буквально в 6-7 строчек. Если вы не знаете этот алгоритм, но за что не родите его, даже загуглив, уйдет уйма времени на осмысление. А если знаете, то это 1.5-2 минуты. Так что в вашем вопросе, как раз таки камень в огород антиалгоритмистов, а не наоборот.

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

Сильно зависит от того, кого и куда собеседуют.

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

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

Но есть ещё один нюанс. От сеньора/лида ожидается, что при возникновении проблем с производительностью именно они пойдут и устранят проблему а, в идеале, не допустят её возникновения на этапе ревью. То есть опять получаем сценарий, когда на проекте алгоритмика может быть не нужна в 99% случаев, но именно лиду/сеньору придётся разгребать оставшийся 1% и, зачастую, разгребать в относительно сжатые сроки.

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

буквально вчера мне поставщик софтины, в которой я обнаружил баг, впаривал, что мне надо добавить к каждой единице номенклатуре еще один дополнительный справочник настройками и заполнить его для 30000 единиц номенклатуры РУКАМИ (ибо табличного заполнения нет(!)), чтобы обойти ошибку, когда при включении функции проверки планового и фактического количества 10*1,56 устойчиво не равно 15,6.

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

Как бы не так. Предположим вам надо считать количество товаров по складам, которые разбросаны по всей стране. Можно просто проходить по массиву и суммировать элементы, а можно сделать дерево отрезков, которое может выдать ответ гораздо быстрее (якобы). Но тут легко забыть почему быстрее. Ничто не дается даром. Скорость обработки таких запросов мы увеличиваем за счет роста потребляемой алгоритмом памяти. Это раз. А два это то - что на алгоритмических секциях требуют достичь хорошую асимптотику. А она в большинстве случаев дает ухудшение производительности при малом количестве данных. Ведь необязательно у вас будет 1 миллион складов, когда два алгоритма можно сравнивать именно асимптотически.
Да и вы тут совсем не об алгоритмах пишите. Ваша проблема не связана напрямую с тем, знает ли программист алгоритмы или нет. Тут гораздо больше другого.