Comments 397
Вот эти все прогоны по алгоритмом с литкода и прочим задачам, не относящимся к потребностям позиции возникают потому, что закрыть позицию у бизнеса не горит, а ответственный за найм не терпит убытки. А вот когда начнёт пригорать, то основными критериями становятся: приходить каждый день, не косячить, соблюдать регламенты, разбираться в проекте, работать в команде.
Согласен. В процессе поиска работы вижу, что все вакансии существуют по принципу: не очень то и нужно.
закрыть позицию у бизнеса не горит
КМК идёт бесконечное просеивание кандидатов, чтоб из крупиц высеять золото по их критериям.
Цель забрать лучших к себе в команду.
Это не поиск лучших. Это агрессивная фильтрация худших.
Причем по критерию nor-and из списка, слабо пересекающегося с актуальной предметной областью: несколько минорных несовпадений со списком отбора, вместо целевого списка — и приплыли, даже если с целевым списком корреляция 146%.
Если у меня как у работодателя будет возможность взять человека с 10 языками (английский, испанский, немецкий), одновременно с этим он не хуже своих конкурентов, я возьму именно такого, ясное дело в работе это не нужно, я если у меня есть такая возможность я выберу именно такого, лучшего среди лучших.
Ты всего лишь возьмёшь уникальную (редкую) компетенцию.
И он уйдет от вас через полгода, потому что у вас нет испанского офиса и ему не с кем практиковаться. Работа тратит его время и если по-немецки никто не говорит, тогда зачем ему проводить время жизни с вами и терять квалификацию?
Работа тратит его время и если по-немецки никто не говорит, тогда зачем ему проводить время жизни с вами и терять квалификацию?
Наверное, потому что он шёл на работу, чтобы приобретать квалификацию и зарабатывать деньги в том направлении, на которое он устроился, а не ради языковой практики? Как вы думаете?
Это называется перфекционизм. По-хорошему это психическое расстройство. Которое уже следует лечить, когда оно заходит слишком далеко. Т.е. когда такой перфекционист-лид ищет ищет найти не может, вместо того чтобы взять +- подходящего и уже начать таски двигать.
Между тем человек с 10 языками скорее всего овладел ими одинаково плохо.
Тогда и писали бы "нужен специалист по Литкоду"...
да да, потом такие спецы по литкоду наяривают на килобайты и миллисекунды и удивляются почему их не хотят брать как например тут забывая что пишут код они пишут для команды и в команде тоже надо уметь работать. А литкод для одиночек но его можно использовать проверки работы в команде (обсуждать решение, просить изменить условия и тд, как sandbox он всё же не плохой и не все задачи там плохие, есть 10-20% прям хороших а это много сотен - огромный выбор)
Ды так-то килобайты и миллисекунды это тоже хорошо, но хорошего понемножку. Как говорится, ты сначала сделай, запустись, набери аудиторию и выйди на уровень, когда килобайты и миллисекунды начинают решать :)
Если человек смог разобраться в алгоритмах, то это точно не дурак и прочитать гайд по фреймворку, навешать линтеров для него не составит труда. Если будет выбор взять просто программиста или точно такое же, но со знаниями алгоритмов, конечно же предпочтение будет второму. Не понимаю почему все считают что литкодеры не умеют в фреймворки. Ну если не умеют, просто ищем того кто умеет) Мы например 50% собеса гоняем по фреймворку.
Упор на фреймворки часто выглядят вот так:
Интервьюер: Что насчёт Ореха?
Плотник: А что с ним?Интервьюер: Много ли вы работали с ореховым деревом?
Плотник: Конечно. Ореховое дерево, сосна, дуб, красное дерево — всё, что угодно.Интервьюер: Но сколько лет вы работали с Орехом?
Плотник: Да не знаю я, чёрт возьми. Я что, должен считать каждую доску?Интервьюер: Но сколько лет вы работали с Орехом?
Плотник: Да не знаю я, чёрт возьми. Я что, должен считать каждую доску?Интервьюер: Ну хотя бы примерно?
Плотник: Хорошо, тогда я бы сказал, что у меня есть полтора года опыта работы с ореховым деревом.Интервьюер: Но вы не ореховый гуру?
Плотник: Ну, я же плотник — я работаю с любыми типами дерева, которые, конечно, имеют некоторые отличия, но я считаю, что если ты хороший плотник…Интервьюер: Да, да, но мы используем ореховое дерево. Это нормально?
Плотник: Ореховое дерево — это прекрасно! Всё, чего пожелаете — я же плотник.Интервьюер: Что насчёт чёрного Ореха?
Плотник: А с ним что?Интервьюер: У нас было несколько ореховых плотников, но потом случайно выяснилось, что они не были плотниками по чёрному Ореху. Имеется ли у вас опыт с ним?
Или он вообще никогда не работал с фреймворками и не знает зачем они нужны
Абсолютно согласен. Это становится особенно очевидно, когда смотришь на список компаний, которые этот этап практикуют: Озон, Яндекс, ВК и т.д. - т.е. это компании, у которых входная воронка кандидатов такого размера, что они не только по алгоритмам могут гонять, но и по физическим параметрам отсеивать - и все равно закрывать свои вакансии.
Я для себя так решил: спрашиваю у рекрутера - будут задачи на алгоритмы на собесе? Прям задачи, а не просто про биг о поболтать? Если да - то я пас, у меня вообще нет никакого желания упарываться в литкод, чтобы пройти собес.
В корпорациях следят за тем, чтобы небыло незаменимых сотрудников. Строят матрицы компетентности, двигают сотрудников, следят за единообразностью подходов. Даже если разбежится пол проектной команды, то это не станет катастрофой. Так что да, в таких компаниям обычно нет требования срочно закрыть позицию.
В корпорациях следят за тем, чтобы небыло незаменимых сотрудников. Строят матрицы компетентности, двигают сотрудников, следят за единообразностью подходов
Это в корпорациях есть, но работает точно так же, как и любые другие распорядки в любом другом обществе. Т.е. как повезёт, в зависимости от желания руководства подразделений реально тратить на это своё время, или просто создавать видимость. От потерь компетенций пре уходе половины проектной команды в крупных корпорациях куда чаще спасает её серьёзная раздутость и избыточность, чем матрицы этих самых компетенций.
Плюсую, сразу скипаю такие вакухи
Иногда ещё и с тупыми тестовыми, по типу вычислить угол треугольника по 3м сторонам, ей богу, как будто не на мидла собеседуюсь, а на стажёра
Лучшие не ходят по собеседованиям. Их приглашают поработать в свою команду либо бывшие коллеги либо знакомые бывших коллег, которые посоветуют своим знакомым взять тебя в команду :)
Честно говоря, я иногда затрещину хочу дать человеку в формате: «А может, ты пойдешь поработаешь [вместо того, чтобы] рассказывать про то, как тебе комфортно или некомфортно работать в офисе?»
(c) Роман Маресов, директор по продукту в Yandex. Cвою карьеру начал со стажировки в Ernst & Young, а затем перешел на должность консультанта в McKinsey & Company, где меньше чем за два года дорос до позиции ассоциата. В «Яндекс» пришел в 2017 году во время поглощения Uber, алгоритмическое задание не сдавал.
Цель - забрать себе в команду тех, кого можно будет бить по морде и заставлять работать по 12 часов в день. Ишь чего захотели, холопы! Лучшими себя возомнили!
Скоро и на конюшне пороть начнут...
Иногда это просто тупая дедовщина: я прошёл этот барьер, я крутой. А ты, червяк, не прошёл - и нечего занимать место в нашей крутой компашке
Меня всегда умиляют вопросы про специализированные вещи, про которые ты никогда не слышал, но если бы поинтересовался, то разобрался бы в полчаса. А на собесе, надо достать их из кармана и, с придыханием, продемонстрировать
Ни разу я не сталкивался с более чем логичным продолжением: ну раз не знаете, давайте мы созвонимся через час и решим какие-нибудь задачки на эту тему. Это 100% тест на то, как кандидат будет выплывать в реальной ситуации собственными силами, а не на внезапно стоящей в кустах яхте
ну раз не знаете, давайте мы созвонимся через час и решим какие-нибудь задачки на эту тему.
Многие так и делают. Когда ведут собеседование тимлиды и руководители отдела как-то так и есть. Даже интересно пообсуждать какие-то задачи. Особо увлеченные сами объяснять начинают как решить задачу, а ты просто наблюдаешь и дополнить не успеваешь ))
На галеры идут задачи по опроснику, типа способы вывода в Excel и виды указателей. Обычно этого не помнишь, даже если пользуешься, проще глянуть в ранее написанный код или погуглить. И заваливаешь такие тесты. Но там обычно и компании особо не нужны новые сотрудники, ведут наем потоком на всякий случай, и собеседуемым тоже особо не надо. После успешного собеседования может оказаться что зарплату ниже ожидаемой предлагают.
Если мне наоборот поставят задачу провести собеседование, я вот даже не знаю как бы проводил. Наверное по шаблону типовому как все.
Меня всегда умиляют вопросы про специализированные вещи, про которые ты никогда не слышал, но если бы поинтересовался, то разобрался бы в полчаса. А на собесе, надо достать их из кармана и, с придыханием, продемонстрировать
Это чтобы сбить у кандидата уверенность, тем самым умерив аппетиты по зарплате.
Но как можно проверить вот эти вот навыки у кандидата?
А вдруг такие задачи следствие того, что часть разрабов, гуляют по собесам просто так?) Ну то есть им и у себя норм, но вот если получат оффер на 700к, то и будет пища для размышлений. А компании думают, ну пусть придет рокзвезда суперперформер и за два года даст такой рывок отделу, что менеджмент получит большие премии
Голос разума. Но вернее сказать - проповедь в борделе.
Да тут примерно раз в неделю кто-то пишет что-то типа: "Долой алгоритмы на собесах!", - а через день-другй кто-то еще пишет совершенно обратное, типа: "Народ прет войти в ИТ, а примитивно затестить, простое это число перед ним или нет, не может, при том самым элементарным способом".
И я вот хз, что там в этой попытке решить пару задач типа "баз/физ" (или как оно там) и подобных так ломает юные дарования. Может они просто не могут? Скорее всего. А потом воют на весь интырнет о том, что да пошли они все с этими алгоритмами, ибо мы, крутые разрабы, научившиеся перекладывать джисоны и ответственность, и без них отлично живем. Детский лепет, конечно, но инфантилизм современного человека растет ближе к пупам земли семимильными шагами. И это хорошо.
У меня на собеседовании кандидат написал:
if (x % 3 == 0) r = 'fizz'
else if (x % 5 == 0) r = 'buzz'
else if (x % 3 == 0) && (x % 5 == 0) r = 'fizz-buzz';Хотелось бы услышать мнение противников алгоритмов про этот код. lol
А причем тут алгоритмы, если налицо непонимание работы оператора — последняя ветка никогда не выполнится. Вот если бы она была первой, то можно было бы заводить речь об алгоритмах.
Алгоритм он и про последовательность действий в том числе, имхо. Данный пример хорош тем, что тут проблемы с самыми базовыми знаниями.
Скорее типичная грабля физбаза, которая по хорошему должна быть исправлена при вычитке своего же кода. Вот если кандидат упорно ее не видит, тогда да, можно кричать ахтунг.
А причем тут алгоритмы, если налицо непонимание работы оператора
Понимание работы оператора как раз есть - чувак-то явно в курсе, что оператор проверяет условие, и если оно верное, то выполняет следующий код, а если не верное, то код после else,
А вот сообразить верную последовательность из трёх проверок условий, т.е. алгоритм, чувак уже не смог.
Вам снова некуда потратить свое время и надо поспорить об определениях — или вы сообразили, что у каджита лимит на пустопорожние словесные баталии и решили прогнать его из этой статьи тоже? )
В этом примере или грубая описка (бывает, но обычно выявляется на тестовом прогоне), или непонимание работы оператора ветвления. С условиями у него, с точки зрения перебора в лоб, все правильно — он выделил все необходимые к обработке случаи.
Написавший тот код не понимает, что если сложное условие в ветке else частично перекрывается условием выше, то переход в ветку не произойдет никогда. Это — работа оператора, именно она не до конца понятна автору кода.
Т.к. из определения алгоритма следует, что, во-первых, алгоритм это не код, а во вторых он должен работать — то об умении работать с алгоритмами вести речь будет можно, когда подобная работа будет проделана. Неработающий код или работающий неправильно на реализацию алгоритма, согласно определению, не тянет.
Нам этот этап, если он был, не показали.
или вы сообразили, что у каджита лимит на пустопорожние словесные баталии
...не ограничен, как я уже не раз видел. И что пацан удаляется из словесных баталий, только когда он сам понимает, что совсем-совсем неправ, и уже оправдываться вообще нечем. И тогда он уходит молча. Но гордо :)
В этом примере или грубая описка (бывает, но обычно выявляется на тестовом прогоне)
Бывает, но это код в уме прогнать можно и нужно. И я не верю, что собеседующий не спросил что-то овида "а проверьте внимательно, всё ли корректно?"
Неработающий код или работающий неправильно на реализацию алгоритма, согласно определению, не тянет
Странные у вас определения. Код, это и есть частный случай реализации алгоритма, в виде программы на ЭВМ. Неработающий код бывает неработающим по разным причинам, одна из которых, это неправильная реализация алгоритма, и вот это как раз она и есть.
Доказывать что-то тем, кому ограниченность опыта и компетенций не позволяет наличие этих границ осознать, но позволяет натягивать сову на глобус — так себе удовольствие.
Код, это и есть частный случай реализации алгоритма, в виде программы на ЭВМ
То есть, когда вам удобно — вы разделяете алгоритм и реализацию, а когда неудобно — нет.
Nuff said.
Доказывать что-то тем, кому ограниченность опыта и компетенций не позволяет наличие этих границ осознать, но позволяет натягивать сову на глобус — так себе удовольствие.
Я же говорил, коронная атака пацана: нет аргументов - обзови как-нибудь собеседника и тем самым выгодно перехватишь инициативу.
То есть, когда вам удобно — вы разделяете алгоритм и реализацию, а когда неудобно — нет.
Ограниченность моего опыта и компетенций не позволяет понять, к чему пацан на этот раз пристебался, но вы лучше бы написали, что в моём утверждении было некорректным.
Ах да, тут же аргументы нужны. Пардон. Проехали.
То есть, предметно вам возразить нечего, парсер скобочки выкинул, но виноват в этом снова каджит.
Засим бёрст на бесполезные споры закончился: вы сможете оставить пафосный комментарий в сабветке последним, чтобы все точно были уверены, кто победил. Прошу, не стесняйтесь в выражениях своей любви )
То есть, предметно вам возразить нечего
Дык эта... мяч на вашей стороне, загляните в свои ворота:
Код, это и есть частный случай реализации алгоритма, в виде программы на ЭВМ. Неработающий код бывает неработающим по разным причинам, одна из которых, это неправильная реализация алгоритма, и вот это как раз она и есть.
Вы на это начали токсичить-пованивать вместо диалога. Вот ответите, будут вам и мои аргументы. Хотя вы и не собираетесь, в общем-то. Ну, скатертью дорожка.
Ну-с, давайте попробуем разобраться с мячом.
Начнем с очевидного:
* из вашей цитаты следует, что код — это не алгоритм, а его реализация
* и язык тоже не алгоритм
* неправильная реализация алгоритма ≠ ошибка в алгоритме
* из определения алгоритма следуют возможные типы ошибок реализации: пропуск шага, дублирование шага, неверный переход — но ничего что могло бы относиться к владению языком и его инструментами. Это абстракции совершенно другого уровня, к алгоритму отношения не имеющие
С этими пунктами вы согласны?
из вашей цитаты следует, что код — это не алгоритм, а его реализация
Да, естественно. Алгоритм, это последовательность действий для решения задачи, по определению. Это с одной стороны, куда более общее понятие, чем код, с другой - не каждый код реализует алгоритм.
и язык тоже не алгоритм
Вообще никак не алгоритм
неправильная реализация алгоритма ≠ ошибка в алгоритме
Неправильный код ≠ неправильная реализация алгоритма. Простейшее доказательство: вот тут алгоритм сложения двух чисел на Паскале абсолютно верный: c = a + b;
А код - неправильный, т.к. имеет место синтаксическая ошибка в операторе присваивания.
из определения алгоритма следуют возможные типы ошибок реализации: пропуск шага, дублирование шага, неверный переход — но ничего что могло бы относиться к владению языком и его инструментами. Это абстракции совершенно другого уровня, к алгоритму отношения не имеющие
Естественно, я как раз в предыдущем случае и привёл пример разницы между первым и вторым.
В то же время, следите за руками: c := a - b;
Вот вам неверный алгоритм сложения двух чисел, где мы имеем ошибку в коде, которая эквивалентна ошибке в алгоритме. Просто ошибка в коде не синтаксическая, как ранее, а логическая. Поэтому хотя "неправильный код" и не тождественно "неправильной реализации алгоритма", утверждение "неправильная реализация алгоритма не связана с неправильным кодом" тоже ложное. В частном случае, если алгоритм записан в виде программного кода, то ошибки в алгоритме = "неправильный код". Это одностороннее утверждение, в обратную сторону оно не работает, не каждый неправильный код = ошибки в алгоритме.
Неправильный код ≠ неправильная реализация алгоритма
Это естественно вытекает из определения алгоритма и упомянутого вами факта, что код не обязан реализовывать какой-либо алгоритм.
Однако, если код таки реализует какой-либо алгоритм — то применять к нему это высказывание нельзя. Потому что получается или что неправильный код === правильный код, или что код, реализующий какой-либо алгоритм — не является реализацией алгоритма.
Это подмена. И кто-то, похоже, ее успешно заглотил…
вот тут алгоритм сложения двух чисел на Паскале абсолютно верный: c = a + b;
Нет. Или тут лишний Паскаль, или алгоритм.
Вот это — соломенное чучело. И дальше вы начинаете блестяще с ним бороться.
Так что ваш пас просто ушел в молоко, если немного уметь в логику. И никакого мячика на стороне каджита — нет.
Однако, если код таки реализует какой-либо алгоритм — то применять к нему это высказывание нельзя.
Почему нельзя, если это высказывание абсолютно корректно? Код, реализующий алгоритм, может быть неправильным, и неправильно реализовать алгоритм. А может быть неправильным, но при этом правильно реализовать алгоритм. Отсюда естественным образом следует, что если код реализует алгоритм, то
Неправильный код ≠ неправильная реализация алгоритма, но
Неправильная реализация алгоритма = неправильный код, потому что первое есть подмножество второго в данном случае.
Нет. Или тут лишний Паскаль, или алгоритм.
Код на Паскале, как частный случай реализации алгоритма, никак не может быть лишним в обсуждении вопроса о коде, реализующем алгоритмы. Но если пацану не нравится какой-то мой аргумент, он всегда может сказать, что аргумент дурацкий, а у меня нет логики, или опять назвать меня мудаком, действуя в рамках своего воспитания. Это, скажем так, ожидаемо от данного собеседника.
Почему нельзя, если это высказывание абсолютно корректно?
Корректно обсуждать в контексте кода, реализующего алгоритм — код, никакого алгоритма не реализующий?
Корректно считать кодом, реалузющий алгоритм, только тот код, который реализует его правильно?
Вы бы хоть таблицу истинности составили для этих двух ваших утверждений, вместо надергивания частных случаев — раз уж взялись рассуждать логически.
Код на Паскале, как частный случай реализации алгоритма
То есть, вы не отрицаете, что намеренно подменили алгоритм — его реализацией, и прекрасно понимаете некорректность аргумента.
Что снова возращает нас к вашим любимым пацанским аргументам, которые вы любезно приписали каджиту.
Сообщите, когда сможете закончить с демагогией и разговаривать как разумный человек — может быть каджит еще не потеряет интереса к обсуждению.
намеренно подменили алгоритм — его реализацией
Реализация алгоритма - это частный случай записи алгоритма. Для алгоритма не принципиально записать его в форме блок-схемы или в форме реализации. Ошибка не являющаяся опечаткой или неверным выбором библиотеки/фреймворка - является именно ошибкой алгоритма.
А в чем ошибка? Нет, конечно есть способы более эффективно проверить делимость на 5 (оканчивается на 0 или 5), что для больших х будет хорошо. Но всё-таки, чем не код джуна?
вообще, "пахнет 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
Более того, если речь идёт о каком-то сложном алгоритме, то скорее всего лучше использовать протестированную библиотеку чем изобретать велосипед
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)), чтоб она ещё могла порционно данные подгружать и не ломаться. Сервис заработал, код стал трудночитаемым неподготовленным человеком.
К чему всё это:
Поймает ли тут проблему регрессионный тест или перформанс тест, если код не был ухудшен, а был изначально "плохо" написан?
Считаем ли этот код "плохим", если на момент его создания он вписывался в имеющиеся требования, а новые требования сформированы были через год в связи с ростом сервиса?
Окей, мы узнали, что код не вывозит. Что делать, если у нас нет leetcode-задрота? Просить начальство удвоить память на серверах в дц? а с O(N LogN), которое не укладывается в таймауты запросов что делать?
За 7 лет работы это был один конкретный случай, где мне пригодилось знание, как самому организовать сортировку быстро. Стоит ли ожидать такое знание от всех кандидатов? до сих пор не могу ответить себе на этот вопрос.
Окей, мы узнали, что код не вывозит. Что делать, если у нас нет leetcode-задрота?
Дать задачу на ресёрч обычному разработчику, не "leetcode-задроту". Если он профпригоден, то сможет определить класс задачи и исследовать, что в современной CS имеется для её решения.
Ну вот я и пишу, что средний разраб у нас оказался без подозрений, что именно гуглить в области cs, и начал упарываться кешами как единственным известным ему эффективным способом оптимизаций.
Верно ли, что тогда мы считаем обязательными понимание medium-алгоритмов с литкода или хотя бы информированность о подходах к их решению?
light-уровень не рассматриваю, так как он - необходимый минимум, чтоб держать хеш-мапы правильной стороной вверх
А потом пришёл унылый ПТУшник и реализовал это же одним запросом в БД или пайплайном спарка, собранным из готовых компонентов?
если нет литкод задрота, можно просто воспользоваться услугами разраба бд, благо их много и они не дорогие
Окей, мы узнали, что код не вывозит. Что делать, если у нас нет 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 разным параметрам) и при этом имеют жесткие ограничения на время выполнения и потребляемые ресурсы процессора.
И там речь не о секундах, а о часах как правило.
О том и речь. Автор статьи утверждает, что не надо все знать, ведь можно нагуглить, не торопясь, все антиалгоритмисты в тренде тоже твердят - можно изучить, почитать на досуге, поискать как решить оптимизационную проблему и т.д. И тут же летят оправдания "ой код кривой, потому что некогда вылизывать неделю". Так а может всё-таки надо знать хоть минимум по алгоритмике, чтобы не вылизывать неделю, а делать сразу нормально? Ведь это не отнимет время вовсе, когда знаешь.
В первую очередь нужно всё понимать! Обезьянка с chatGPT ничем не лучше попугая, который всё помнит, но ничего не понимает.
Тут скорее не про то что надо/не надо, знать. Знать это одно дело - иметь в постоянной оперативной памяти - совсем другое. Я вот, например, знаю как правильно рассчитать ферму для строительной конструкции, неоднократно это делал и если понадобится, то я смогу вспомнить и сделать расчет. Но если меня вот прямо сейчас попросить сделать расчет чего-то нетривиального, да в сжатое время, то я скорее всего не осилю, потому что я не занимаюсь этим постоянно, и многое забыл.
Так и с алгоритмами на собесах. Если человек сходу не может развернуть бинарное дерево, то это вообще ничего не говорит о нем как о специалисте. Возможно он плохой специалист, а возможно просто уже забыл как это делается, потому что в обычной работе этим никогда не занимался (я вот, за 20+ лет работы, ни разу, кроме как на собесах, этого не делал).
С другой стороны - если он бодро все описанное сделает, то это означает только то, что он готовился именно к этому собесу, во всех остальных профессиональных задачах он может оказаться полным нулем. Так мы проверяем только мотивированность и способность к обучению, что, конечно, неплохо, если мы ищем джуна, например. А вот когда нужен специалист уровня повыше, то это антипаттерн. Крутой спец и без надрачивания леткода работу легко найдет, если он все-же этим занимается, то тут уже возникает некоторое сомнение..
Как-то пришли ко мне с такой задачей:
Есть код, который запускается раз в сутки и на основе статистики веб-сервера списывает с клиентов деньги за трафик. Проблема заключалась в том, что код (сервис) с какого-то момента не успевал отработать за сутки.
После переделки код отрабатывал за 5 минут. Предыдущий автор, видимо, не понимал, чем плохи три вложенных цикла. Предполагаю, что если бы он время от времени баловался решением алгоритмических задач, то не написал бы такой код.
После переделки код отрабатывал за 5 минут. Предыдущий автор, видимо, не понимал, чем плохи три вложенных цикла
Видел случай, когда функция вызывала функцию вызывающую функцию с вложенностью свыше десятка раз от чего всё дико тормозило. А ведь, людей на полном серьёзе учат, что подобное является правильным подходом.
Об опасности вложенных циклов знали еще в 60-е годы, когда никаких алгоритмических задач не было.
Я не спорю с основной идеей, но все же добавлю.
Возможно для бизнеса долгое время это было вполне нормальное время работы, а разработчик все таки решает задачи бизнеса. На этапе развития, возможно, это делалось на коленке и за пол часа работы, потому что сроки горели, возможно это даже было MVP, которое так и осталось в проде. Возможно бизнес на тот момент нанимал очень дешевого программиста и получил вполне себе работающий прототип, да, плохо работающий, но долгое время этот код приносил деньги. Когда начались проблемы, бизнес попросил более хорошего программиста оптимизировать код и получил улучшенный вариант. С точки зрения бизнеса это все не выглядит как трагедия, скорее как систематическое развитие.
У меня был пример, когда сделали небольшую фичу, при входе на каждую страницу проверка идет ли в текущий момент урок, на который записан пользователь. И работала она супер быстро, отрабатывала где-то за 40-60мс. Потом пришел продакт и попросил другого программиста добавить в запрос проверки еще одно условие. Потом пришел продакт другой команды и попросил другого разработчика добавить еще условие. И каждое из этих условий глобально ничего не ухудшало критически, но скорость запроса упала где-то раза в 3-4. А потом из-за маркетинговой активности резко выросло число пользователей и все стало резко хуже.
Можно придумать множество гипотез. И оборачиваясь назад кажется: "Ну как можно было написать такой ужас?". Но в момент создания этого кода могло быть множество причин почему оно сделано так, а не иначе.
PS Я не оправдываю 3 вложенных цикла, я скорее про сам подход. Что сейчас смотря назад можно много негативного думать про код, но он писался в других условиях и контексте )
Помню работал еще в самом начале трудовой карьеры кем-то вроде продвинутого админа. Управлял локалкой с компами, немного программировал на чем придется. И вот приходит ко мне директор и говорит - у нас тут есть один очень важный отчет, очень сложный, формируется он много часов, перелопачивает всю базу, но он нам очень нужен, там много важной информации о работе фирмы. И вот сегодня этот отчет перестал работать - после многих часов формирования выдает какую-то ошибку. Посмотри, пожалуйста, можно ли его исправить!
Ладно, открываю тот отчет, и .. обалдеваю.. Писал его какой-то дядька аналитик, который на тот момент уже давно не работал там, сначала для своих нужд, а потом поделился с коллегами и те его активно использовали. Дядька был, видимо, хороший аналитик, раз создал такую полезную программку, но программист был так себе. Отчет выгребал из БД содержимое нескольких таблиц полностью, фильтровал их потом подбивал всякую сводную информацию по этим данным. По словам пользователей - раньше он работал достаточно быстро, ну как быстро, за пол часа можно было результата дождаться. Но база росла, объем данных увеличивался, и видимо, со временем просто перестало хватать памяти для работы.
В общем посидел, разобрался что этот отчет вообще должен считать, и переписал его заново, оставив неизменным только интерфейс и формат результата. Отчет стал выполняться за считанные секунды, потому что всю фильтрацию и многие подсчеты я перенес на SQL, о котором первый автор видимо имел довольно смутные представления.
Сначала даже посмеялся над глупым предшественником, но потом, подумав перестал, человек написал очень нужную и актуальную штуку, которая при всех недостатках приносила большую пользу, реализовал ее как смог, но переписать все правильно, это оказалось намного проще чем её придумать. Переписать-то я смог, а вот сам такой отчет изобрести - это нет, на тот момент, тут бы моих скилов не хватило, так что кто тут дурачок это было еще под вопросом.
на практике у меня однажды был в команде человек который неплохо решал задачи на leetcode. Но когда надо было оптимизировать обход данных на продакшене (достать запись из очереди -> обновить очередь обработав связанные записи) вместо оптимизации квадратичного алгоритма он добавил кучу кэшей и низкоуровневых оптимизаций, что уменьшило константу в 10 раз.
На тестовой окружении записей были тысячи, на продакшене - миллионы и помогла его оптимизация ровно на неделю.
Очень многие проекты которые я видел, провалилась из-за неправильных алгоритмов. Почему-то люди думают что алгоритм это какой-то изолированный кусочек, но вся система целиком это тоже алгоритм. И вот он часто спроектирован очень паршиво, причины бывают разные, далеко не всегда некомпетентность тех кто его писал. Но знание алгоритмов, как минимум, помогает увидеть эти вещи.
А я работал на одном проекте, где код был просто крутейший. Работала там очень сильная команда, ни одного мидла, все на уровне хороших прошаренных синьоров. Очень мне там нравилось работать ,потому что было у кого и чему поучиться, и код был великолепный.. Проект с треском провалился. Причина, на мой взгляд - оверинжиниринг и провал менеджмента. Там так всего накрутили, что для старта работы нужно было немало вложиться в инфраструктуру, для объема данных в несколько сот мегабайт, было запущено с десяток микросервисов со всем что их связывало, и бизнес так и не удалось этой идеей заинтересовать.
При том что я практически уверен, будь там небольшой монолитик, пускай даже кривоватый и глюковатый, идея бы взлетела.
понаписал квадратов на ровном месте
Только надо иметь в виду, что асимптотика важна только на большом количестве элементов. Если у вас их 10 штук, сойдёт даже экспоненциальная сложность.
Если у вас вход контролируемый, то может и сойдёт. А если это может сделать внешний пользователь, то можно на DoS нарваться.
во времена выхода XP не предполагали что патчи на OS будут валиться один за одним, поэтому залепили туда экспоненциональную функцию выбора апдейтов. Уж не знаю как именно они умудрились, но видимо думали "откуда может быть сразу больше 5 штук обновлений в очереди"?
Алгоритмы не нужны, да... А потом на код ревью приходится объяснять человеку, что он понаписал квадратов на ровном месте и как из-за этого всё будет весело работать у клиента.
Алгоритмы - это, несомненно, замечательная штука. Но вот у меня в реальной жизни - поддержка сайтов интернет-магазинов, которые уже кто-то за много лет до меня пилил и поддерживал. И делал это далеко не один человек, последовательно друг за другом.
В итоге там, как правило, замечательные вещи:
запросы к базе внутри цикла, который тоже внутри цикла - на сотни элементов каждый
запросы на массовое обновление записей в базе - без транзакций
использование вызовов 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). Мне кажется – это позволит оценить мышление кандидата, а не просто насколько он зазубрил алгоритмы или типовые задачки.
достаточно спросить чтонибудь совсем простое - например найти 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.
Везде есть оптимальная середина. Так что это нормально, что люди критикуют крайности.
Электрон писали какие-то неумехи, не знающие алгоритмов?
Без понимания, как оно всё работает, можно выбрать, например, библиотечный, но нестабильный алгоритм сортировки
Так а просто поговорить про стабильность сортировки и случаи, когда это нужно, а когда нет, почему нельзя? Ну поговорите на собеседовании про алгоритмы и структуры данных если это важно и критично на вашей работе. Если человек плавает и не знает чем отличается связный список от массива, то вы сразу сделаете для себя выводы. А если он знает и понимает, он возьмёт готовое и применит как надо и где надо. И не нужно ему мозг выносить и считать за дурака, потому что он не смог за 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% умеет, и на собесе я вряд ли что-то более достоверное в этом плане смогу выяснить.
Да нет, здравый смысл тут подсказывает что корреляция должна быть.
Человек задрочивший литкод будет буквально с любыми задачами
справляться значимо лучше. Не только в контексте программирования.
ну спорно, тот же Каспаров сказал - "Игра в шахматы развивает только умение играть в шахматы"
Крупные кампании стараются внести объективность в найм, а не отдавать это на откуп местным руководителям. Стандартизованная система найма позволяет переводить людей между командами, а не увольнять их вместе с руководителем, который набирал под себя.
Это одна из причин, как мне кажется.
Мне кажется, то, что вы описали: "стандартизованная система найма" - это "работает" только в умах тех, кто придумывает такие системы и в их отчётах и сопроводительных записках.
Люди - это не унифицированные роботы, каждый человек индивидуален, со своим багажом опыта, навыками, чертами характера, сильными и слабыми сторонами. Нельзя просто разработать "стандарт найма унифицированных людей" и нанимать на все случаи жизни с одинаковой эффективностью, прогоняя всех кандидатов по занимательным задачам в полном отрыве от реальности, предметной области и рабочих проблем.
И в то же время, люди обладают интеллектом и умением обучаться, подстраиваться и перестраиваться если нужно. Не нужно упрощать людей и обесценивать их способности, отталкиваясь только от того, смог человек решить задачу с литкода за 30 минут в условиях стресса или не смог. Так что наняв однажды хорошего инженера/разработчика не надо переживать, что он сможет крутить только одну гайку работать только на одном конкретном проекте только с одним руководителем, а на другом вдруг резко сломается как искусственная нейросетка.
И вот вопрос, как же выматывающие "стандартные" собеседования с элементами бессмысленного и беспощадного олимпиадного программирования помогают находить хороших инженеров с правильным мышлением, которые смогут работать на разных проектах, решать сложные задачи, прокачивать свои навыки и расширять кругозор? Что тестируют такие собеседования? Умение решать задачки с литкода (которые надо решать несколько месяцев, чтобы достичь успеха, как в книжках написано)?
Это попытка упростить то, что не упрощается. Нет никакой серебряной пули. Компании нужно готовиться к собеседованиям и проводить их разумно, а не по чьей-то глупой методичке.
Вы зря так категоричны. Стандартная процедура не означает стандартных людей. Каждый собеседующий тоже человек, и оценивает комплексно, ему ничего не мешает ставить хороший был даже если человек не решил, но думал правильно.
Это две крайности, есть объективные критерии и есть субъективные. Полностью переходить на субъективные тоже плохо - буду нанимать "талантливых и нестандартных" своих друзей и родственников. Тут же ещё вопрос в доверии руководства к тем кто нанимает.
>и как из-за этого всё будет весело работать у клиента
И... как? Вы производительность решения "с квадратами на ровном месте" замеряли? Или "интуитивно" решили, что оно плохое? Само по себе это ещё не значит, что что-то будет работать недопустимо медленно с точки зрения продукта. А если для нас избавление от излишней сложности — самоцель, так можно дойти и до полного отказа от чужих библиотек и фреймворков в ущерб скорости и стоимости разработки.
Замеряли. Для этого существует тестирование. Ну и, к сожалению, иногда квадраты или что-то похуже обнаруживались после жалоб клиентов, а не на ревью и после переписывания проблемных кусков с нормальной сложностью, всё начинало летать.
Еще до замеров человек, умеющий в алгоритмы и оценку сложности способен определить проблемные места в коде. Конечно, для тех, что "высшее образование не нужно, алгоритмы не нужны, я вон фигачу и всё нормально", это магия, я понимаю.
А если для нас избавление от излишней сложности — самоцель
Еще до замеров человек, умеющий в алгоритмы и оценку сложности способен определить проблемные места в коде.
И чего, по коду всех используемых фреймворков и библиотек тоже пробегаетесь, чтоб определить "проблемные места"?
Конечно, для тех, что "высшее образование не нужно, алгоритмы не нужны, я вон фигачу и всё нормально", это магия, я понимаю
Уметь определять производительность без замеров — действительно магия. А, может, просто бездоказательный снобизм.
по коду всех используемых фреймворков и библиотек тоже пробегаетесь
Вы будете удивлены, но да! И даже, бывает, в исходники компилятора заглядываем. А некоторые даже под капот CPU залезают:
https://habr.com/ru/articles/778026/
Уметь определять производительность без замеров — действительно магия
Даже немного завидую вам. Живёте в мире с магией. Эх, мечта.
Я читаю код всех библиотек, что использую. И мой текущий проект держит 200к запросов в сек. При этом всё это использует всего 7Мб памяти. И не подвисает пердически из-за работы GC.
А потом на код ревью приходится объяснять человеку, что он понаписал
квадратов на ровном месте и как из-за этого всё будет весело работать у
клиента.
Ну объясните один раз. В чем проблема-то? На второй раз атата сделайте. На третий раз - забракуйте испытательный срок. Обычный процесс обучения. И вас так учили, даже если сейчас кажется, что уже родились сеньором-помидором.
Я в этом году джуна менторил. В первых пулл-реквестах было по 20-30 мажорных замечаний и по неоптимальностям и по стайлу, а потом вышли на 2-3 минорных максимум. Я прям сильно сомневаюсь, что у литкод-маньяка результат был бы другой.
В смысле, испытательный срок? Вы предполагаете, что так делают только те, кто пришел в команду?
Я такие вещи видел у опытных, умудренных сеньоров, которые сидели в команде годами. Они застали еще те времена, когда клиентов было 5, а весь монолит запускался на бесплатном дино на хероку. Поэтому проблем по производительности не было. А сейчас смотришь и грустишь.
В смысле, испытательный срок?
Ну мы ж про собесы и найм говорим, исходя из контекста статьи.
Есть заблуждение, что мол вот мы сейчас обмажемся десятью этапами собеса с дрочкой литкода - и к нам придут только лучшие из лучших. Я б поверил в этот булшит, если б не был плотно связан с наймом уже 5 лет. На практике вы хоть колесом ходите - все равно к вам придут люди с разными скиллами и особенностями. И с этим надо уметь работать.
Есть заблуждение, что мол вот мы сейчас обмажемся десятью этапами собеса с дрочкой литкода - и к нам придут только лучшие из лучших.
И вы эти заблуждения приписываете всем оппонентам? Есть также заблужддение, что если человек написал в резюме, что он умеет программировать, то он и правда это умеет. У меня на собеседованиях часто всё заканчивается на задаче: распечатайте в консоль словарь, в котором ключи строки, а значения числа. Часть кандидатов не могут и этого. Вы можете говорить что угодно, но никогда не убедите меня, что человек с 5+ годами опыта на самом деле отличный программист и всё это умеет, просто у него стресс.
И вы эти заблуждения приписываете всем оппонентам?
...
никогда не убедите меня, что человек с 5+ годами опыта на самом деле отличный программист и всё это умеет, просто у него стресс
Ну если вам можно вешать ярлыки "не отличных программистов" на совершенно незнакомых людей, то и мне можно приписывать заблуждения кому угодно. Все честно, вроде.
Я не навешиваю ярлыки, я оцениваю квалификацию. Если программист не может написать цикл без гугла, то оне не плохой программист, он вообще не программист. И проверить это очень просто - попросить написать этот самый цикл. А вы занимаетесь демагогией.
Сейчас среди джунов встречаются умники, которые вместо гугла используют chatGPT.
Я не могу без гугла или без 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 циклом без вложенного, если, например, на каждом шаге цикла добавлять что-то к началу массива вполне себе библиотечной функцией.
И вот чтобы это понимать, нужно владеть теорией.
Алгоритмы не нужно учить наизусть, это не стихи. Чтобы понимать, что сортировка может быть нестабильной и что это не ошибка также нужно понимать, как эта самая сортировка работает и чем один алгоритм отличается от другого. Иначе это всё превращается в набор магических догм, которым тупо следуют, не задумываясь. Вот прямо как у вас с циклами получилось.
добавлять что-то к началу массива
Достаточно почти любой операции с zero-terminated string в цикле;)
Вот именно это и происходит на собеседованиях с алгоритмами: ты говоришь что-то общими словами, а собеседующий, которому очень хочется показать, что он правее всех правых вместо уточняющих вопросов по одному предложению делает вывод о вашей подготовке, точнее о профнепригодности.
В этом и проблема таких собеседований.
Мой тезис остался таким же: да, вы правы в своих уточняющих пунктах, но чтобы всё это объяснить и перечислить опасные с со стороны производительности места, чтобы сверяться с ними в команде по мере разработки достаточно вечера. А для пятиклассника хватит первого тезиса про циклы, и будет круто, когда он разберётся и скажет: "Смотри, оказалось ты был не прав, говоря, про цикл в цикле".
а собеседующий, которому очень хочется показать
Вы сами интервью проводите? Мне ничего не хочется показать, мне хочется найти вменяемого коллегу в команду. Это какой-то детский сад считать, что препод или интервьювер вас непременно пытается завалить. Это я вам как бывший препод и нынешний интервьювер говорю. Конечно, упоротые личности с комплексами есть, но их отнюдь не большинство, не надо по ним всех судить. Знали бы вы сколько раз я видел удивленные глаза человека, который получал оффер после того, как в конце собеседования говорил: "наверное, я завалил собес, плохо отвечал"...
А если речь о фаангах, где несколько раундов интервью, такой упоротый быстро получит по шапке, если он постоянно будет давать отказ в то время как другие будут рекомендовать к найму.
Ваш предыдущий комментарий написан в пассивно-агрессивном тоне, я именно поэтому и посчитал, что вы хотите всеми силами доказать, что правы, заодно, невзначай, унизив собеседника, мол, он там просто заучил магические догмы и всё.
В текущем комментарии вы опять занимаетесь обобщением, говоря, что я, видите ли, считаю, что все преподы и интервьюверы хотят меня завалить. Хотя я говорил только о примере вашего неконструктивного общения выше, ну и, на основе его, высказывал предположения о том, зачем другим собеседующим, алгоритмическая сессия.
Ну и, наконец, как бывший препод и нынешний интервьювер, вы можете хоть на секунду представить, что общаетесь с человеком, который и обучением занимался, и получал самые сложные задачи в потоке в университете на алгоритмическом курсе потому, что "так ты обычные за 10 минут решишь и думать даже не будешь, сиди, развивайся", и который уже 6 лет собеседует людей в свою и смежные команды?
Только вот это не доказательство ничего, это переход на личности. То, что и вы, и я проводим много интервью, ничего не говорит об их качестве. И даже если прошедшие интервью люди могут работать и их редко увольняют тоже ничего об качестве не говорит, может быть, можно было вообще не проводить никакого интервью, и результат был бы тот же.
а собеседующий, которому очень хочется показать, что он правее всех правых вместо уточняющих вопросов по одному предложению делает вывод о вашей подготовке,
Точно таким же воспаленным самоутверждением могут страдать и другие интервьювью - от разговоров по душам о прошлых проектов, до просмотра гитхаба кандидата. Это не врожденное свойство алгоритмических интервью. Если где-то интервьювер - мудак, то это проблема человека, а не алгоритмических задачек.
Алгоритмы не нужны, да... А потом на код ревью приходится объяснять человеку, что он понаписал квадратов на ровном месте и как из-за этого всё будет весело работать у клиента.
Данный аргумент - по сути, единственный адекватный, который приводит защитники алгоритмов. С ним, несомненно, можно согласиться. Да вот только на 146% алгоритмических секций ух слишком упарываются в тонкости, скорость исполнения куска кода и минимизацию ресурсов. И тут понятия, такие как читаемость кода, разделение кода на идиоматические части в виде функций/классов и создание поддерживаемого/масштабируемого кода пролетают - они уменьшают оптимальность его выполнения и не годятся для алгоритмов. В итоге мы имеем олимпиадников, которые нанимаются, спокойно пройдя алгосы и мб теорию, и пишут абсолютно ужасные партянки.
Ну и оптимизация приложений - это не только написание функции, это оптимизация запросов в бд, корректное масштабирование сервисов и уменьшение нагрузки на сеть, а сортировка, которая отработает на 1 наносекунду быстрее, чем другая, по факту ничего не улучшит
И тут понятия, такие как читаемость кода, разделение кода на идиоматические части в виде функций/классов и создание поддерживаемого/масштабируемого кода пролетают
Не пролетают, для этогно есть секция ОО дизайна.
Ну и оптимизация приложений - это не только написание функции, это оптимизация запросов в бд, корректное масштабирование сервисов и уменьшение нагрузки на сеть
А об этом вы поговорите на секции системного дизайна.
Это если мы говорим про фаанги. Если речь про обычную компанию, всё это легко в равках одного собеса будет.
Да вот только на 146% алгоритмических секций ух слишком упарываются в тонкости, скорость исполнения куска кода и минимизацию ресурсов.
Алгоритмическая секция нужна прежде всего для того, чтобы понять, может ли человек решить простую задачу, знает ли он о существовании граничных условий, уточняет ли он требования или сразу бежит что-то писать, не разбираясь, имеет ли он привычку проверять то, что он написал и, в конце концов, способен ли он хотя бы простой код написать. Знание алгоритмов там вторично, на самом деле.
Знаете у меня ниразу не было задачи где есть связный список или граф, зато в 100% задач есть набор сырых данных которые надо обработать, алгоритм не я придумал он исходит от бизнес-требований и часто вообще описан задолго до моего рождения. Я примерно помню все структуры данных и алгоритмы, если мне нужны их сложности у меня есть табличка на столе. Я не запоминаю наизусть то что могу найти в интернете или книге, то что я пользую достаточно часто и само оседает в памяти.
Меня на одном собеседование спросили про B-деревья. Я вместо ответа захотел узнать как часто в компании стоит задача написать свою СУБД или провести оптимизацию доступа к данным на жёстком диске? Собеседник не понял к чему я задаю эти вопросы, лучше давайте накидаем примерно код реализации.
Вся суть в том что клоун на собеседующем просто спрашивает *последняя фигня о которой я читал*. Если клоун не читал ничего интересного в последнию неделю, то он спросит *100 тупорылых задач для собеседования если ты тупой* самый умный клоун скопирует рандомную задачу из литкода, решение он конечно тупо посмотрел в разделе с ответами.
P.S. В следующий раз предложите собеседнику прям сейчас с мобилы выбрать рандомную hard задачу с литкода и решить её в режиме соревнования вы против него, спортивный интерес. На моем опыте все отказываются, не знаю даже почему.
Согласен, пока это про простые и интуитивные алгоритмы уровня "прицепи побольше 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 миллион складов, когда два алгоритма можно сравнивать именно асимптотически.
Да и вы тут совсем не об алгоритмах пишите. Ваша проблема не связана напрямую с тем, знает ли программист алгоритмы или нет. Тут гораздо больше другого.
Что-то похожее регулярно замечаю в приложении одной доставки из одной сети супермаркетов: добавляем сферическую колбасу в вакууме из коня в вакууме в корзину, переходим к оформлению: "ой, всю уже раскупили". Возвращаемся в каталог - она есть, добавляем в корзину, идём в оформление - её опять нету. Такая вот колбаса из кота Шрёдингера в коробке вместо нужной мне колбасы из коня в вакууме.
Меня как конечного пользователя приложения вообще не интересует, отрезками или огрызками там асимптотически считается наличие товара на складе, но считайте уж по одному алгоритму и корзину и каталог. А то об алгоритмике-то позаботились, а конечному пользователю вместо колбасы показывают интимный орган то сферического кота, то упакованного в коробку кота.
А причем тут знание алгоритмов ? Тут скорее проблемы с архитектурой приложения
10*1,56 устойчиво не равно 15,6.
Это потому, что внутре компьютера двоичная система, что надо учитывать (где-то тут была чудесная статья про то, почему 0.3/3 * 10 != 1.0). То есть, тоже, у разработчика не очень хорошо было с базой по информатике.
Хз, я и по сей день даю 1-2 задачки на алгоритмы во время собеса - причем задачки довольно простые. Я провёл около 400 собеседований за последние 8 лет, и корреляция очень сильная - кандидаты, которые их решают, почти всегда сильнее и лучше в прикладных задачах, чем те, кто их решить не может.
Я не могу дать человеку бизнес-задачу или попросить сделать небольшое веб-приложение - это не поместится ни в полчаса, ни в час, а тестовые вообще мало кто любит (да и смысла я в них особого не вижу).
Но удивительная закономерность такова - если человек на собесе смог смерджить два отсортированных массива в третий отсортированный - то обычно, когда после этого я прошу написать простенький React-компонент для асинхронной загрузки картинки - он справляется отлично.
А если чел два массива соединить не смог, и начал мне рассказывать "зачем эти алгоритмы, мы же веб-приложения делаем", то когда я говорю "окей, без проблем, давай напишем input, у которого при фокусе placeholder поднимается вверх над полем ввода", то я вижу какую-нибудь дичь с точки зрения качества кода - неадекватное управление state'ом, непонимание замыканий, и прочее.
Мой личный вывод - если чел потратил время на понимание того, как работает память и выполнение кода, то вероятно, он такое же время потратил на понимание как внутри устроен тот или иной фреймворк/библиотека/движок, и умеет качественно её использовать.
Если же чел топит за "зачем мне эта теория, мы тут формы шлепаем" - ну, скорее всего он и формы шлёпать будет довольно криво.
P.S. Я говорю про довольно простые алгоритмические задачи - никаких оптимизаций графов или каких-нибудь черно-красных деревьев, и прочего.
P.P.S. Да, даже простые алгоритмические задачки не решают 80% кандидатов. При том, что собеседую я в основном синьоров с 5+ годами опыта. До сих пор не укладывается в голове, как это возможно.
Ну вот у меня 10+ лет опыта. И я недавно зарегался на leetcode. Выяснилось, что я:
Могу затупить на Easy. Сильно затупить. Долго.
Могу порвать 100% за чашкой кофе на Medium.
Могу решить Hard не зная типового алгоритма и прочитать о нём уже потом (топологическая сортировка).
Могу не справиться с Medium просидев с ним весь день.
И чо?) Это же ненадёжно для собеседования на такие роли, где программирование больше "законотворческое" (выстроить отношения между сущностями), нежели числодробильное.
Ок, наверняка между знающими алгоритмы и способными кодить есть корреляция. Но тогда пропадают люди, способные кодить и не знающие алгоритмов.
У меня 30+ лет опыта и на литкодовских задачах могу зависнуть просто потому что это абстрактная задача.
При этом реальные рабочие задачи, значительно большие по объему, вполне нормально решаю (ну как коллеги говорят и показывают результаты нагрузочного тестирования :-)
может ElKornacio проверяет чтоб просто тестовые примеры проходило? и смотрит как он справляется с кодингом и отладкой а не проходит или нет?
по крайнее мерее я не вижу надобности на собесе доводить таск литкода до прохождения всех тестов. Зато литкодом можно проверить на навыки коммуникации и командной работы или попросить изменить сделанный алгоритм (бывает что у кандидата таск уже решён - а давать рандомный я не хочу т.к. там свыше 60% тотальный булшит аля шахматный конь скачет по num клавиатуре 4х3 без крайних двух что побокам нуля, подсчитайте какую унылую комбинаторику или непрактичную DP по модулю 100000007 - поэтому я всегда даю хорошие годные таски из своего списка, которые я знаю и решал и знаю что решить крайне легко например выровнять блок текста по ширине или на имплементацию простого стека например)
Я предпочту обозначить задачу из реальной практики и спросить как ее планируется решать. Не в коде, а план решения, основные моменты.
Но у нас своя специфика - очень специфичная платформа и очень специфичный стек.
Людей, которые просто смогут ответить на вопрос "о чем это вообще и что оно делает"
CPYF FROMFILE(ASRCPGM/CPOSRC100) TOFILE(ASRCD09/CPOSRC100) FROMMBR(*ALL) TOMBR(*FROMMBR) MBROPT(*REPLACE) CRTFILE(*YES)
CRTBNDCL PGM(ASRCD09/@CRTCPO100) SRCFILE(ASRCD09/CPOSRC100) DFTACTGRP(*NO) ACTGRP(*CALLER)
CALL ASRCD09/@CRTCPO100На всю страну несколько сотен наберется.
Так что больше интересует "как у человека голова работает вообще". Применительно к тем задачам, которые тут придется решать.
Сразу JCL запахло - языком, на котором матерно ругаются программисты.
Очевидно, копирует файл, потом создает что-то (ссылку какую-то?) и вызывает некую стандартную процедуру.
Это язык системных команд (CL) на IBM i Используется как "средство общения" с системой в терминале, так и для написания небольших программ (он типизированный, компилируемый) для манипуляции с системными объектами.
Команда CPYF - копирует "PF-SRC - физический файл исходных текстов" (содержащий все исходники поставки) CPOSRC100 (в нашей нотации это поставка линейки CPO версия 100) из библиотеки ASRCPGM (опять в нашей нотации - библиотека где хранятся исходники поставок на юните PGM) в библиотеку ASRCD09.
Команда CRTBNDCL - компилирует программу-инсталлятор @CRTCPO(на том же CL - она генерируется автоматически на основе гредловых скриптов с описанием поставки) исходник которой лежит в том же CPOSRC100
Ну а третий просто запускает скомпилированный инсталлятор - устанавливает поставку в юнит D09.
На всю страну несколько сотен наберется.
Та побольше, он же не только на мейнфреймах юзается, но и на куда более распространённых iSeries. Тем более что его в ряде контор используют не только разработчики, но и продвинутые пользователи.
Так мы и работаем на iSeries - IBM i. Это не мейнфреймы, middleware. Но не слышал чтобы у нас в стране их много было.
CL мало используется в разработке. Ну разве как вспомогательный, для коротеньких программ, работающих с системными объектами. Больше сопровождение использует.
Но каждый пользователь его так или иначе знает - это же средство общения с системой. Даже если не пишешь на нем программки, то все равно его команды используешь при работе в терминале.
Но не слышал чтобы у нас в стране их много было.
Да в принципе много, на них до последних лет работали и Пенсионный фонд, и Федеральная служба занятости, и не один десяток банков.
Про ПФР слышал, но были слухи что ушли с нее (или их ушли). Про службу занятости не слышал. Кто-то говорил, что в РЖД что-то было, но старое, давно не обновлялось.
Из банков точно знаю что мы (альфа), росбанк и райф. Кто еще не в курсе.
Но CL - это в основном команды для работы с системой в терминале. Ну мы еще на нем пишем программы-инсталляторы для поставок (точнее, раньше писали руками, сейчас оно автоматом генерируется по гредловым скриптам). Сопровождение какие-то свои скрипты пишет на нем.
А так более 80% кода под эту систему на RPG пишется. Вся работа с БД и бизнес-логика. Ну и немного на С/С++ (все низкоуровневое)
Там сложность немного рандомная и завязана количество шагов/алгоритмов для решения; еще medium - это иногда easy с дополнительными условиями. На собеседованиях обычно адекватные задачи задают, пару раз было что решается довольно легко и просто, а на литкоде помечена как hard.
17 лет опыта в 80% случаев не решу на собесе задачку 🤷🏻
Мне тут уже несколько комментов написали формата "я опытный и классный, но могу затупить на интервью", так что решил ответить)
Моя главная задача как интервьюера не в том, чтобы сказать "да" каждому подходящему кандидату, а в том, чтобы ни в коем случае не сказать "да" неподходящему. Если я упустил крутого программиста в результате моего тупого интервью - ну, жаль, но в момент найма у меня 2-3 собеса в день, 5 дней в неделю - может я потрачу больше времени, но крутого программиста найду.
А вот если я сказал "да" тому, кто в реальности под работу не подходит - это ад для компании - это куча потерянного времени, денег, и напряг для большого кол-ва людей, и запуск найма снова. Нанять некомпетентного чувака - это прям ужас-ужас, его будут вводить в курс дела, обучать, давать задачи, разбираться почему он не справляется - может несколько месяцев уйти, пока станет ясно, что с ним просто надо попрощаться, и он не подходит.
Поэтому, если кто-то у меня на собесе затупил и задачки не решил - это ничего не значит, вполне реально, что это замечательный разработчик, у которого выдался плохой день - я пару раз видел ребят, которым я отказывал, на крутых должностях в других компаниях.
Но у меня в арсенале нет хорошего способа отличить человека, который "затупил на собесе" от человека, который "тупит всегда", и поэтому мне приходится им отказывать.
Надеюсь, со временем я такой способ найду, но пока что увы - независимо от кол-ва лет опыта, я не могу пропустить дальше кандидата, который задачки не решил(
Алгоритмы это очень хорошо чтобы прям отсеять пару сотен или даже тысяч человек которые о компьютерах и программировании знают "я после курсов".
Когда обсуждают «алгоритмы на собеседованиях» часто ставят знак равенства между пониманием принципов работы стандартных алгоритмов и структур данных (с оценкам сложностей) и вот такими вот «олимпиадными» задачками на сообразительность. Но это фундаментальные разные вещи. Можно отлично разбираться в стандартных алгоритмах и быть в курсе таких продвинутых техник как динамическое программирование, но когда в конкретной (как правило очень искусственной) задаче тебе в ограниченное время предлагается догадаться до «трюка» с которым ты не сталкивался — тут в принципе мало какие знания помогут
Статья огонь, о том как с одного портала задротства пересесть на другой
Может быть 1-2 простых алгоритмических задачи на собеседовании и уместны, но когда весь собес превращается в полуторачасовое разжевывание кишков языка, которые не имеют ничего общего с реальной работой, это бред. Яндекс например этим маразмом занимается. А отсеивать кандидатов можно и в автоматическом режиме, для этого есть различные опросники, тесты, с автоматической проверкой, рекомендательные и сопроводительные письма. Собеседующий человек в первую очередь должен смотреть на опыт, проекты и увлеченность потенциального работника, а не это вот все.
как то в одной японской компании меня попросили перед собесом в течении недели сделать несколько easy medium задач ЛЮБЫХ, не меньше пяти штук, и на собесах мы обсуждали как их улучшить или почему то или иное было сделано именно так или как доработать до другого типа входных данных, прошло интересно но не наняли - я перенервничал на следующем поведенческом.
и это был единственный случай когда литкод вообще упоминали в собесах когда собеседовали меня.
Если вам на собеседовании дают алгоритмическую задачу, то помните, что:
Если собеседующий адекватный, то от вас не требуется обязательно решить задачу (написать работающий код). Достаточно продемонстрировать умение разбивать задачу на подзадачи, выбирать правильные структуры данных и оценивать сложность алгоритма. Можно, не решить задачу и получить за неё плюс, а можно выдать правильное (зазубренное) решение и получить за неё минус, не так ответив на дополнительные вопросы.
Если собеседующий неадекватный и вам отказали, не смотря на правильные рассуждения в процессе решения, то это только к лучшему. Зачем вам неадекватный начальник?
Для примера возьмём задачи и статьи. Я не знаю правильного решения (даже не уверен, что правильно понял условие, так как по ссылкам не ходил и примеры входа/выхода не видел), но попробую рассуждать логически.
Максимальная площадь.
Берём единицу, добавляем в очередь. Для первой единицы из очереди добавляем в очередь все соседние единицы. При этом считаем количество единиц (площадь) и заменяем единицы на двойки (помечаем обработанные).
Решение: проходим по массиву и для каждой единицы запускаем описанную выше рекурсивную функцию (считающую площадь связанной области). В отдельной переменной храним максимальный на текущий момент результат работы функции.Самая длинная подстрока.
Текущая подстрока - это "окно" (левый и правый конец). Пока строка содержит только уникальные символы, двигаем правый конец. Пока строка содержит дубли, двигаем левый конец.
Для подсчёта дублей используем словарь с количествами символов в подстроке (меняем при каждом сдвиге границы). В отдельной переменной храним количество дубликатов (меняем при изменении значения в словаре с 1 на 2 и с 2 на 1 в словаре).
В начале левый и правый конец указывают на первый элемент. Останавливаемся, когда правый конец дойдёт до конца строки.Слияние списков (считаю, что дан массив связанных списков)
Кладём все первые элементы в коллекцию. Достаточно хранить индексы списков в массиве, так как значение можем узнать за О(1), а можно хранить пары индекс-значение.
На каждом шаге выбираем минимальный первый элемент, удаляем его из соответствующего списка и добавляем в результирующий список.
Исходя из задачи, в качестве коллекции выбираем очередь с приоритетом. Библиотечной в моём языке я не знаю, но легко написать двоичную кучу (binary heap), в которой корнем будет индекс (в массиве списков) с минимальным значением (первым элементом). Для этого нужно два метода - "всплытие" и "погружение".
p.s. Я не решаю задачи на LeetCode и не уверен, что смог бы довести эти задачи до рабочего кода за 30 минут на собеседовании.
Самая длинная подстрока
Что пришло в голову сразу.
Берем таблицу символов. Изначально заполнена нулями.
Берем счетчик. Изначально 0.
Берем максимальное значение счетчика. Изначально 0.
Берем индекс начала максимальной подстроки. Изначально - начало строки
Берем индекс начала текущей подстроки
Идем по строке от первого символа к последнему. Берем очередной символ, смотри м таблице (символ - индекс). Если там 0, ставим туда 1, увеличиваем значение счетчика.
Если не 0 - обнуляем таблицу, если значение счетчика больше максимального, присваиваем максимальному значения значение счетчика и индексу максимальной подстроки индекс текущей подстроки.
Обнуляем счетчик, индекс начала текущей строки ставим на текущий символ.
Ну как-то так на пальцах.
Там можно просто запоминать последнюю позицию для каждого символа. И если последняя сохраненная позиция очередного str[i] оказалась правее начала текущего отрезка, сдвигаем оное начало на ту сохраненную позицию + 1.
Отличная идея! Мне такая в голову не пришла. Правда, я потратил 15 минут на 3 задачи (5 на решение и 10 на формулирование/набор текста).
А вот мне кажется, что +1 не надо. Надо на позицию того символа, который оказался первым дублем. Но да - в целом так лучше - не надо каждый раз таблицу чистить.
Наверное, сам бы додумался, но уже "на второй итерации" - посмотреть на код и подумать "а нельзя ли тут на чем-то скроить еще"? Сходу в голову не пришло, конечно.
заменяем единицы на двойки
Матрица бинарная, только 0 и 1. Понадобится вторая матрица, чтобы отмечать просчитанные области.
Максимальная площадь.
Там в оригинале квадрат, а не площадь. Maximal Square. Ну и собственно, задача в том, чтобы решить её за O(m*n). Большее time complexity не пройдёт тесты.
Авторам в личку кидал информацию об ошибке, они не исправили.
А я не понимаю, а чего бы тогда просто не требовать ссылку на тот же самый LeetCode? Пускай в требованиях к вакансии пишут: "200 решённых задач сложности medium на LeetCode. Ссылка на профиль в резюме/сопроводительном письме"
А я не понимаю, а чего бы тогда просто не требовать ссылку на тот же самый LeetCode?
Потому что в общем случае на собеседовании интересуют не ваши результаты на литкоде, а просто умение решить задачку, где надо включить мозги. Литкод тут просто инструмент, где всё готово для решения задачек.
Потому что не интересен сам факт решения. Интересен процесс решения (ваши рассуждения).
Кроме того, если будет спрос, то тут же появятся предложения типа "200 задач на литкоде за Х рублей".
Будут фирмы "делаем профиль на литкод под ключ". Каждый второй прошедший - будет вайтишник с крусов "с 0 до мидла за месяц".
ИМХО мода на знание алгоритмов тянется из 50-60- - когда профессия математик-численник и программист было одним целым. Сейчас же... кажется программисту важно знать, что алгоритмы существуют, знать библиотеки где они реализованы или быть способным (редко) закодировать алгоритм описанный где-то.
Пример. Мне нужен был алгоритм сдвига узлов сетки - я нашел математическую статью где их было описано несколько штук, взял самый простой и запрограммировал. Всё. Зачем этот алгоритм знать программисту?
Мне нужно было решить уравнение Пуассона на CUDA, я дал статью с описанием алгоритма программисту аспиранту, он закодировал даже не особо вникая. Задача решена.
(Я не программист, я научный работник если что).
С тех пор как исчезли чистые кодеры писавшие код по полученному алгоритму в виде блок-схемы, от программиста ожидается, что в случае необходимости он сможет создать алгоритм самостоятельно.
Это странно. Простые алгоритмы и нужные алгоритмы - описаны и закодированы 100500 раз, сложные и нужные - это задача не программиста, а математика с соответствующим профильным матобразованием. А вот знание какую память как для чего использовать, как организовывать многопоточность, избегать всяких гонок и дедлоков, организовывать структуры данных, знать как работать с драйверами с железом, и т.п... кажется именно вот это и есть работа программиста. Но видимо я просто отстал от программисткой жизни.
Я в IT с 90х, и за все эти годы ни разу не видел живьём математика, который рисует блок-схемы с алгоритмами для кодеров являющихся тупыми исполнителями его воли. Все виденные мной в IT математики - сами работали программистами и лично писали код, а не рисовали блок-схемы с алгоритмами для кодеров.
Видел я код, написанный математиками. Лучше бы не видел.
Вы путаете математиков и программистов. Математик по сути должен нарисовать алгоритм. А архитектура программы это другое.
Именно таких математиков я на работе ни разу в жизни не видел.
Математики должны решать мат задачи, а не писать код. Код пишут разработчики.
Это тоже самое как филолога ну или на край физика заставить писать код. Вы увидите красивый код?
Простые алгоритмы и нужные алгоритмы - описаны и закодированы 100500 раз
Динамическое программирование не абстрагируется в библиотеку, увы.
А вот знание какую память как для чего использовать, как организовывать многопоточность, избегать всяких гонок и дедлоков
Ну зачем это, если вы пишете на Хаскеле с STM? Там гонки и дедлоки надо очень потрудиться сделать. Или если у вас акторы. Или если у вас однопоточные программы. Вон, компиляторщики всю жизнь в однопотоке проводят и всё у них хорошо.
знать как работать с драйверами с железом
Кому надо, а кому и нет.
Я имел ввиду, что есть специальные программисткие знания, и знание алгоритмов к ним не относится. Я вот не знаю ни Хаскеля, ни STM, а какие-то алгоритмы - знаю, т.е. я ближе к условным математикам, чем к программистам.
Насколько я понимаю, они, эти специальные программистские, то есть, которые должны иметь все программисты — это какая-то базовая информатика. Вроде того, что внутре компьютера числа в двоичной системе, поэтому 0.3/3.0*10.0!=1.0, что есть время вполнения и время компиляции, что один и тот же результат может быть получен несколькими разными программами, выполнявшимися разное время, какие-то выводы из проблемы остановки. И тому подобное, очень и очень базовое, что у нас проходит по разряду здравого смысла, и формулировки чего напрочь забыты.
А специальные навыки — это умение формализовать всякое, и работа с системами: построение, эволюция, отладка.
На мой взгляд, такой подход вполне оправдан для топовых компаний, где количество откликов на вакансию значительно превышает количество вакантных мест (Google, Microsoft, другие).
Допустим, есть вакансия и откликов на неё было 1000 (реально, учитывая весь мир), отсеем неподходящие резюме/опыт/английский/soft skills, всё равно останется очень много кандидатов, кто точно сможет успешно справляться с рабочими задачами, будет лояльным и т. д. Я порядка цифр не знаю, но пусть, очень грубо, это будет каждый 20-й.
Каким образом из 50 кандидатов выбрать 5 для найма? Должен быть какой-то фильтр, на который можно будет сослаться, формируя отказ, не жребий бросать. Можно, конечно, устроить среди кандидатов соревнование по пятиборью, но это не очень связано с рабочими обязанностями, поэтому выбрали leetcode: задачи универсальны (не зависят от стека технологий) и долгое время остаются актуальными, как и computer science.
Важно для разработчика правильно поставить задачу? Несомненно, да. В статье приводится пример: "Нужно определить наибольшую по размеру область, которая содержит в себе только единицы, и рассчитать ее площадь.". Ссылка на Литкоде ведёт к задаче "найти максимальный квадрат". Есть три подобные задачи: максимальный квадрат, максимальный прямоугольник, максимальная связная область. Все решаются различными способами.
Мы настолько собираемся кончать с задачами на Литкоде, что и постановки задач чёткие уже не нужны?
В последние годы стараюсь не упоминать на собеседованиях, что есть хороший бэкграунд по алгоритмам - олимпиады и все такое. Так как ненависть к олимпиадникам растет стремительно. В любой команде олимпиадники вызывали ехидство и отторжение у коллег. За последнюю неделю это примерно третья статья только на Хабре, где утверждается прямо в заголовке, что алгоритмы не нужны. Поколение войтишников требует новые стандарты. Скоро будут заставлять извиняться за знание алгоритма Дейкстры.
Всегда умилялся чисто фреймворковским программистам: прочитать килотонны материала по фреймворкам - легко, а пару глав из Кормена - нереально. А в чем дело?! Ведь автор утверждает, что алгоритмике - это шаблоны, зазубренные знания. Почему это вызывает сложность у всех хейтеров, ведь объем очень маленький? А потому что для изучения алгоритма, нужно построить в голове новые нейронные связи, сформировать логические цепочки, а очередной фреймворк как раз-таки можно за пол дня зазубрить и даже на лету применять, хотя документации по ним обычно больше, чем по алгоритмам.
В пользу автора скажу: на собеседованиях знание алгоритмов вам не поможет. Хоть задачи и примитивные дают на собеседованиях, но на них нужно отвечать ровно так, чтобы ты был чуть хуже интервьюера.
Автор говорит: любые задачи на оптимизацию можно решать, просто нужно время, а не сжатые сроки здесь и сейчас. Алгохейтеры в комментах оправдывают медленный код не незнанием алгоритмов, а сделать сделать, которые ставит заказчику и PM. Так может, потому что никто не хочет знать алгоритмы изначально, как автор? Хотите погрузиться в эти дебри потом, а когда наступает потом - некогда погружаться, хай будут вложенные циклы.
Печально, господа. Очень печально. Можно минусовать.
Так как ненависть к олимпиадникам растет стремительно.
Вполне справедливо и началось не вчера и даже не лет 5 назад. Очень часто олимпиадники и краснодипломники демонстрируют что у них проблемы с тем чтобы написать простой и поддерживаемый код. Или просто написать что-то что не является решением олимпиадной задачи. Далеко за примером того как не надо делать ходить не надо.
Учитывая, что это скорее всего выпускники, то с культурой кода могу быть не знакомы. На сколько сложно обучить олимпиадника облачать мысли в код согласно утверждённым требованиям? По идее, это же интеллектуальные, обучаем люди.
Там еще часто бывает проблема в том, чтобы полностью и в срок выполнить поставленную задачу. Не какие-то ее интересные кусочки, а всю целиком - и скучную часть и нескучную. И при этом еще правильно расставить приоритеты - где написать просто чтобы работало (потому что он работает 0.0001% общего времени и нет смысла тратить время на предельную оптимизацию), а где подумать над оптимальным решением потому что вот этот кусок критичный.
Если провести аналогию, олимпиадники - спринтеры - все силы в один рывок. А тут нужны марафонцы - нужно уметь правильно силы по дистанции распределить
За последнюю неделю это примерно третья статья только на Хабре, где утверждается прямо в заголовке, что алгоритмы не нужны. Поколение войтишников требует новые стандарты. Скоро будут заставлять извиняться за знание алгоритма Дейкстры.
А начиналось всё это с "математика не нужна", а "нужны софт-скиллсы".
Не могу похвастаться уж слишком обширным опытом найма, но могу поделиться опытом работы в средне-больших командах, где были разные люди. Одни любили leetкод-задачи, другие не очень.
В целом, это слабо коррелировало с тем кто пишет хорошо, а кто плохо. Тут, скорее, какой-то навык аккуратности, и, не думаю что он хоть как-то к leet-задачам относится. Но, в минус leetcode тусовке я могу записать следующее - часто они кидались решать задачу каким-то "ручным" способом, игнорируя что некие абстракции и библиотеки для этого давно есть, отлажены и стабильны. С большей вероятностью, когда-то что-то падало из-за промаха индекса - это оказывался именно подобный подход - тип ручного прохода с индексом по каким-то данным. Добавлю, что все эти решение всегда оказывались хуже чем готовые библиотеки, что не удивительно - их отлаживали и оптимизировали годами
Если же подобные задачи возникают в ходе реальной работы, я использую библиотеки (обычно встроенные), которые прошли с нами огонь и воду.
Вот главная проблема. Ну нет библиотек на все случаи жизни. Вот, например, тут спрашивают вполне релистичную задачку. Весь "алгоритм" тут, как и в большинстве задачек на интервью - это умение в нужное место впендюрить хешмап. Писать его не надо, надо только уметь пользоваться стандартной библиотекой - знать эти самые "структуры данных". Тут вы ничего ненагуглите и решение готовое не найдете.
Другой пример, даже если задача вполне унифицируема и выделяема в билиотеку, без ее знания вы ее почти точно не нагуглите. Вот тот же sliding window max. Это и задачка на литкоде такая есть и мне она на практике попадалась - я ее даже в прод коммитил. Но без знания ключевых слов вы ее решение не нагуглите.
И третья проблема: без знаний алгоритмов и опыта решения задач, вы даже не заметите, что надо остановиться и погуглить библиотеку. Даже на литкоде большинство задач сформулированны "сделайте вот это вот" и можно условие буквально перевести в медленный код. А когда вам еще и условие не дано, а вам надо фичу для бизнеса запилить, то вы у себя в голове это "вот это вот" формулируете и даже не задумываетесь, что это, оказывается, задача. У вас в голове это уже решение для того, чтобы реализовать вашу фичу.
Поэтому алгоритмы - это совсем не бесполезные знания. Если вы нанимаете разработчика, а не формоклепателя - то они вам встретятся и понадобятся.
Другое дело, что это не единственный нужный навык, да и интервью такие имеют высокий уровень ложно-отрицательных исходов из-за стресса, невезения и вообще жестких рамок по времени.
Но, по совокупности критериев, это самый лучший вариант для интервью, если у вас большая компания и неиссекаемый поток кандидатов. Я этот момент подробно аргументировал в статье.
Из опыта я понял, что на практике есть 2 структуры данных которые покрывают почти все потребности, это массив и хэш таблица, если добавить ещё и мапу то я затрудняюсь вспомнить, что из реальных задач не решалось.
Так вот, достаточно с пристрастием позадавать вопросы по этим 2 структурам данных по их интерфейсам, по сложности их методов и принципиальной разности реализации между ними в чем плюсы и минусы. Что можно делать с одним и нельзя тоже самое с другими и почему. Какие размеры контейнеров будут работать и с тем и с другим, а когда без правильной структуры не обойтись.
Как эффективно работать с контейнерами в функциональном стиле/итераторы, какие алгоритмы и хэлперы есть в вашей стандартной библиотеке в помошь. Тут конечно лучше показать код и попросить перевести на человеческий, что он делает.
Алгочасть полностью покрывается беседой о реальном опыте использования этих 2 структур, если человек ещё и про разницу между мапой и хэш таблицей может рассказать то это уже продвинутый чел.
А если знает как на основе этих базовых структур сделать более сложные производные структуры типа циклический буфер, стэк, очередь, индекс - то дальше про алгоритмы/структуры говорить нет смысла - человек в них прекрасно разбирается.
Из опыта я понял, что на практике есть 2 структуры данных которые покрывают почти все потребности, это массив и хэш таблица, если добавить ещё и мапу то я затрудняюсь вспомнить, что из реальных задач не решалось.
В моей практике - массив и связанный список. Крайне редко - дерево. И разного рода от них производные. Но в базе всегда или то или другое лежит.
Ну так большинство задачек и решаются сортировкой массива, втыканием мапы/хеш-мапы куда-нибудь. Просто справшивать про сложности методов и интерфейсы - это, во-первых, всего-лишь несколько фиксированных вопросов, которые, в отличии от задачек, можно зазубрить. Во-вторых, все будут дико плеваться от этих вопросов, мол: "ну что за бред, есть же документация, зачем мне наизусть знать все методы stl контейнеров!?".
В том то и суть, что вот эти структуры нужно понимать, а не смотреть доки, они основа. Да в доках можно что то уточнить, но суть операции человек должен рассказать сам на основе своей ментальной модели устройства этих структур. Там всего то по 4 основных и 2 спец операции + знание что происходит с итераторами, ну и факультативный резерв.
Необходимо, что бы человек понимал без доступа к документации, что происходит при произвольных вставках и удалениях, как осуществляется доступ по индексу/ключу. В какой последовательности происходит итерация, как безопасно итерироваить и использовать мутирующие операции на контейнере.
Ваше знание алгоритмов на абстрактных литкодовских задачах бесценно (в смысле ничего не стоит) если на реальных задачах (которые много проще) вам каждый раз требуется доступ к документации по базовым методам базовых контейнеров.
Есть прямая корреляция между тем как хорошо человек понимает базовые структуры и его способностью решать реальные задачи. Решив тысячи простых реальных задач, пофиксив сотни крашей связанных с непониманием стуктур, проведя десятки алго оптимизаций и написав единицы уникальных алгоритмов у меня сложилось вот такое мнение.
Необходимо, что бы человек понимал без доступа к документации, что происходит при произвольных вставках и удалениях, как осуществляется доступ по индексу/ключу.
Ну вот: 4 структуры (массив, хешмап, дерево, список), 4 операции (вставка, удаление, поиск, итерация) - итого 16 вопросов, которые можно выучить. И никак вы не поймете - это зазубренная "китайская комната", или человек действительно понимает.
Я полностью с вами согласен, что понимание базовых структур данных - это основа. И этой основы достаточно для прохождения большинства алгоритмических интервью. Но я считаю, что беседой вы эту основу никак не проверите. Поэтому и надо давать задачки, чтобы кандидат должен был сам вспомнить, какие есть стурктуры и понять, какая тут лучше всего подойдет.
А про документацию - это был аргумент о том, что даже если бы "беседа" работала, такие интеврью ненавидели бы, наверно, еще больше чем алгоритмические задачки.
За всю 20+ летнюю програмерскую жизнь список в продакшене так ни разу мне и не понадобился (всмысле задачи где он лучше других подходит), а с учётом того что он не дружит с кэшами и постоянно хип теребенькает да ещё и оверхед по памяти на каждый элемент, то я как вижу лист в комитах сразу записываю имя автора, я уверен у меня к нему будет ещё не один вопрос/предьява.
Вы попробуйте вместо алго задач поговорить про базовые структуры, а уж потом будете судить, что лучше работает и так ли уж получается у людей тупо зазубрить эти знания. Шок, срывы покровов и много лулзов вам обеспечены. Ну а с достойным кандидатом просто приятно пообщаетесь.
Так то я помню те времена когда я сортировку на листочке писал на собесе и как меня потом похвалили, что я один за 3 года собесов правильно =,< расставил, а потом занимался тем, что работал мясным транслятором из Ява на с++ в постпродакшене мобильных игр.
И вопросы про люки и количество заправок в городе я тоже помню, а ещё до этого вы не поверите меня отшили на бесплатную практику/стажировку (ещё студентом) потому, что я не особо различал философию Канта и ещё какого то перца и хоби у меня не было. Да даже ещё 10 лет назад на собесе у меня спрашивали кем я себя вижу через 5 лет в этой конторе.
Это я к чему? Да к тому, что дичи на собесах раньше было значительно больше чем сейчас и алго задачи тоже окажутся там же где и вопросы про люки - со временем.
Ну вот: 4 структуры (массив, хешмап, дерево, список), 4 операции (вставка, удаление, поиск, итерация) - итого 16 вопросов, которые можно выучить
Аплодирую! ^_^
Все зависит от вакансии. на какую-то нужно знать алгоритмы, на какую-то не нужно. Но умение составить свой собственный алгоритм нужно в любом бизнес приложении - на лит код ты его натренируешь за неделю или написав 2000 миграций на работе за 10 лет, это в принципе не важно. Сколько раз я брал людей, которые не смогли решить "задачку", оправдывая это нервами, но отлично справляясь с остальными заданиями, столько раз я жалел об этом и потом тратил свои нервы, увольняя их.
К сожалению, в реальных проблемах не любой алгоритм можно найти в библиотеках. И на собесе надо прежде всего проверять не память на алгоритмы, а умение составлять собственные алгоритмы. Когда мне на собесе говорят, что мол забыл, как решать задачу, внутри меня немножко закипает. Бизнес не скажет тебе: а ну нет так нет, давай займемся плавлеными сырками, раз с IT не получилось. У бизнеса есть задача, которую надо решать и это будет делать либо вновь нанятый сотрудник, либо ты сам. И на собесе надо определить способен ли он решать задачи в первую очередь, а не количество заученных паттернов, алгоритмов и тп.
Меня, кстати, раздражают бубнящие соискатели, которые комментируют каждую строку, не знаю откуда пошло это поверье, что если рассказывать вслух свои мысли это поможет на собесе - я 20 лет "у власти" и научился интерпретировать код написанный за 10 минут.
В целом статья интересная, хоть далеко не во всем согласен, но главная мысль ценна.
Нужны или не нужны алгоритмы можно размышлять долго. Но вот простая ситуация - хочу работу и много денег. А на собеседованиях просят алгоритмы. Что делать? Правильно - решать. И ничего с этим не поделаешь. Такова жизнь.
Подозрение вызывает другое. В вакансии обычно требуют минимум 10 технологий. На каждую технологию есть трёхтомник. Даже на JUnit просто тесты - документация 150стр. На алгоритмы - совсем немного требуется, пару глав из Кормена,но..... "Нам не надо, это можно гуглить, это не для практики и т.д."
Скорость изучения фреймворков равна скорости чтения документации или просмотра Ютуба. А вот с алгоритмами у 99% вайтишников возникают непреодолимые проблемы, ведь это надо уметь не читать, а... думать! Но это на практике им не пригождается же 😀
С другой стороны, а потом мы удивляемся, что приложения всё прожорливее в плане ресурсов, а делают примерно то же, что и раньше. А может дело как раз в том, что очень многие программисты решили, что алгоритмы не важны?
Давайте пойдем дальше. Алгоритмы это еще не все чтобы код летал. Нужно ввести дополнительный уровень на собеседованиях после алгоритмов. На нем спрашивать про архитектуры процессоров. Дальше нужно будет определить почему сгенерировался неоптимальный ассемблер для конкретной архитектуры и как это исправить: live-coding секция в godbolt.org. Задачи на понимание двух типов кэша, задача на векторизацию и что-нибудь еще по вкусу. Вдруг возникнет такая задача за несколько лет работы, а вы не знаете. Бедному работодателю придется второй датацентр покупать из-за вашей некомпетентности. А так сэкономите тучу денег и возможно даже вас по плечу похлопают!
Основа тестов IQ строится на принципе "если человек решает 40 абстрактных задач определенного уровня сложности, то он решит и 5000 такой же сложности задач с таким же успехом"
Если распространить принцип, то если человек решает задачи с литкода высокого уровня, то со сложными задачами на другом уровне он будет справляться примерно также хорошо, будь то сложная предметная область или архитектурная
Если человек решает 40 задач определенного уровня сложности по математике, значит ли что он решит с тем же успехом 5000 задач по физике?
Речь о том, что задачи с литкода могут вообще никак не соотноситься с реальными рабочими задачами. Это просто задачи с литкода. А используют их потому что "так делают в ФААНГе, а мы хоть и ООО "Сукин и Сын", но тоже немножечко ФААНГ".
Любопытства ради, потому что попадаются статьи про литкод - на какую позицию требуются вообще такие знания алгоритмов и почему на такие задачи отводится 30 минут? В жизни ж никто не требует выдавать ответы как в игре кальмара - ответь сейчас или умри. А если соискатель справится с задачей за час? Я понимаю что из всех по времени решения можно найти головастого, но это когда у вас у самих на поиск программиста время большое. А когда сроки горят вы все равно возьмёте того, кто меньше вас беспокоит.
Я сам недопрограимист, занимаюсь СУБД oracle и начинал карьеру в 2004. Тогда никто особо про алгоритмы не спрашивал. Могли про люк спросить. Сам на собеседования уже не пойду, потому что меня уже программирование задолбало, даже такое как в оракле. Но чисто для понимания хотелось бы понять вообще куда нужны такие навыки? Так как большая часть бизнес задач (ну по крайней мере у меня) это довольно отвлеченные вопросы от задачи поиска площади в матрице m на n.
"Клиентов, приходящих с запросом отсортировать пузырьком лучше, чем у конкурентов, немного." О. мудрый человек, автор сей статьи. Глупость программистов ничуть не меньше, чем глупость политиков при примерно том же уровне самомнения и амбиций. И большинство из собеседующих сами не особо 'секут', а спрашивать что-то ведь надо. Так что решать дурацкие задачки по типу leetCode на собесах придется еще очень долго, пока не изменится сама индустрия и подход к построению it-команд...
А мне кажется, ничего страшного, что их спрашивают. Не знаю как у нас, но на западе они это придумали, чтобы меньше ошибаться в выборе кандидата. Им хочется наверняка отсеять плохого кандидата, так как плохой скорее всего точно не пройдет лайв кодинг. А то что , отсеиваются хорошие разрабы, но кто не задротил литкод, они готовы с этим мириться. И вообще к лайв кодингу можно подготовиться: берёшь топ 100 самых популярных медиум задач скажем фейсбука, и решаешь их по кругу пока до автомата не доведешь. Причем сразу решение смотреть на первых порах. Потом паттерны впитаются, и будут легко комбинироваться на незнакомых задачах. Ну и язык попроще выбрать для этого, типа питон js. И мне кажется всё равно эти задачи что-то дают в навыках кодерства
Основная проблема с алгоритмами в том, что они вылетают из головы сразу же как ты перестаешь ими серьезно заниматься. В универе ходил на олимпиады, а вот спустя 7 лет работы сходу и под давлением уже ничего не напишу кроме каких то базовых вещей. Стоит ли опять к ним возвращаться? Ну не знаю, я это время могу полезнее провести.
Я думаю, тут многое зависит от целей, которые преследует компания при найме. Я понимаю крупнейшие IT компании, которым нужны люди страстно желающие у них работать. В таком случае алгоритмы покажут, что человек потратил несколько лет жизни на то, чтобы подготовиться к собеседованию в эту компанию. Есть смысл взять именно этого целеустремленного кандидата, чем умного сеньора, которому работа тут не особо нужна, если не получится - спокойно пойдет работать в менее крупную компанию.
ИМХО алгоритмы и литкод это способ отсеять кандидатов когда их слишком много. Потому что невозможно "провести содержательную инженерную беседу" с 1000 кандидатов. Когда там реально подойдёт почти любой фильтр лишь бы уменьшить входящий поток.
Особенно мне нравятся секция алгоритмов при собесах на позицию фронта.
Да да, мне обязательно на фронте пригодится уменее написать свою сортировку, которая будет работать быстрее всроенного Array.sort(). И разумеется, мне крайне необходимо уметь на лету оценивать сложность каждого написанного метода по Big O.
На фронте вообще не должно быть потребности в больших вычислениях, все расчеты ведуться на бэке и отдаются на фронт порционно. Мы же хотим, что бы наши прилажки работали у всех клиентов, включая бедняг с Intel Atom и 2Gb DDR или смартом с 1Gb памяти на борту.
Какой бы классный я ни написал алгоритм, он всеравно упрется в вычислительные мощности клиента на каком-то объеме данных.
Лучше бы на собесах отдавали больше времени на знание / умение пользоваться определенным набором фрэймворков / библиотек.
Лучше бы на собесах отдавали больше времени на знание / умение пользоваться определенным набором фрэймворков / библиотек.
Не лучше, а намного хуже!
Вопросы про фреймоврки и библиотеки звучат как вот это:
Интервьюер: Что насчёт Ореха?
Плотник: А что с ним?Интервьюер: Много ли вы работали с ореховым деревом?
Плотник: Конечно. Ореховое дерево, сосна, дуб, красное дерево — всё, что угодно.Интервьюер: Но сколько лет вы работали с Орехом?
Плотник: Да не знаю я, чёрт возьми. Я что, должен считать каждую доску?Интервьюер: Но сколько лет вы работали с Орехом?
Плотник: Да не знаю я, чёрт возьми. Я что, должен считать каждую доску?Интервьюер: Ну хотя бы примерно?
Плотник: Хорошо, тогда я бы сказал, что у меня есть полтора года опыта работы с ореховым деревом.Интервьюер: Но вы не ореховый гуру?
Плотник: Ну, я же плотник — я работаю с любыми типами дерева, которые, конечно, имеют некоторые отличия, но я считаю, что если ты хороший плотник…Интервьюер: Да, да, но мы используем ореховое дерево. Это нормально?
Плотник: Ореховое дерево — это прекрасно! Всё, чего пожелаете — я же плотник.Интервьюер: Что насчёт чёрного Ореха?
Плотник: А с ним что?Интервьюер: У нас было несколько ореховых плотников, но потом случайно выяснилось, что они не были плотниками по чёрному Ореху. Имеется ли у вас опыт с ним?
...
Не соглашусь.
Мне нравятся задания в стиле "Отрефакторите представленный код".
В нем ты показываешь что надо поменять, а главное - обосновываешь почему так надо сделать. При этом, зачастую именно в объяснении "почему", мы приходим к основам JS и пониманию языка на низком уровне.
Так же видны знания и понимание необходимого для работы стека технологий, что на мой взгляд важнее "задрачивания" задачек с литкода.
все перечисленные задачки решаются красиво через рекурсию (1),
либо некрасиво через жопу(2).
пол дня думаем и пишем код за 10 минут, вторые полдня пытаемся отладить.
пишем за полчаса. и следующие два года зарабатываем на икру оптимизируя код.
даже если первый вариант чудом заработает на техсобеседовании - собеседователи восхитятся каэш, но понять почему и как оно работает - скорее всего не смогут. как и создатель.
второй вариант обычно не приемлют, потомушта далеки от понимания капиталистического устройства общества.
стрелять и попадать - не одно и то же.
У меня больше пригорает не от решения самих задачек, а от дичь компаний которые это вводят.
Я 20 лет пишу код и последние 10 лет начала появляется эта мода на задачки.
И теперь ты каждые полтора, два года как меняешь работу, снова начинаешь с одного и того же.
Решаешь сраные задачки, сейчас это LeetCode и CodeWars.
Уже до тошноты. Это самое унылое что вообще можно представить в программировании.
Ты решаешь залачки перед собесом и через три месяца ты все забыл.
Одно дело когда ты идешь в BigTech с оплатой в 300-500$ тыс в год.
Тут мне плевать я хоть на асфальте мелом красно черное дерево сбалансирую.
Другое когда помоечная компания Вася Пупкин и компания с оплатой в 5к+ дает тебе LeetCode задачу уровня medium или hard на 30 минут. А после ты по пояс в говнокоде, с покрытием тестами в 10%. И людьми которые линтер настроить не могут.
Последний раз просто свалил с такого собеса, просто сказал не решу за тридцать минут идите лесом. Хотя решил уже несколько тысяч подобных задачек. Просто матерное ****
Алгоритмы и структуры данных знать нужно.
Только то что сейчас это уже абсурд.
Абсолютно согласен с автором. Надоел этот маразм с алгоритмическими задачами. Это атавизм тянущийся с древних времен,не имеющий ничего общего с современными реалиями разработки. Особенно сейчас, когда chatgpt способен реализовать любой алгоритм.
Работал с нами чувак фронтендщик. Код писал ужасный, просто каша из условий в одном файле на 100500 строк, верстал ужасно, чтобы вы понимали, использовал отрицательные маргины для позиционирования. Никак не мог его отучить от этого. Зато пол годика, в любое свободное время, решал задачи в литкоде. В итоге прошел собес в Яндекс. Как же я был рад, что он наконец ушел, до сих пор разгребаю его писанину, все приходится переписывать.
Особенно сейчас, когда chatgpt способен реализовать любой алгоритм.
Никогда не задавайте chatgpt вопрсов по теме в которой вы не специалист. Он вам нагалюционирует очень правдоподобный неправельный код, а вы даже не поймете, что это совсем не то.
Там все гораздо хуже. По картинкам-то сразу понятно, что тут бред. Ибо все тут имеют обширный опыт разглядывания людей. С текстовым бредом иногда еще понятно, как с расплавленными яйцами. А в более сложных случаях - нет. А с кодовым бредом разобраться еще сложнее. Иногда человеческий осмысленный код-то дебажить сложно. А уж если там какие-то алгоритмы, то вот такой "ненавижу алго собеседования"-программист никогда там ошибку не найдет.
Особенно сейчас, когда chatgpt способен реализовать любой алгоритм.
...в таком виде:
В быстро меняющемся мире ваши текущие скилы не сильно интересны. Важны ваши способности к обучению, общий кругозор и интеллектуальные способности. Литкод в этом смысле неплох.
Все верно, алгособес это не про заучивание. Как правило таких людей, кто выучил, но не понимает сразу видно, получит красный флаг "не понимает/не может обьяснить что написал". Те кто справляется с full loop(а это не только алгособес) обычно в состоянии справиться с большинством рабочих задач. Компании просто минимизируют false positive.
Меня наоборот напрягают собесы, где начинают спрашивать детали конкретной технологии.
Для людей кто один раз научился json перекладывать и теперь хочет получать за это деньги до конца своей жизни у меня плохие новости, LLM с двумя коннекторами это уже кое-как умеет делать.
Все верно. Как и какой-нибудь тест на IQ показывает лишь как индивид натаскан именно на этот тест. Логично же ведь :)
Ну и хороший инженер не должен быть энциклопедией, а должен знать ответы на три вопроса. Что, где и как. Что применить, где применить и как применить. Все.
Боюсь с LeetCode сейчас как с ЕГЭ. Последствия ЕГЭ сейчас уже видны. Но его отменить не могут. И тут сейчас такая же петрушка.
То, что человек умеет решать задачи с LeetCode ничего не говорит о его умении кодить в реальных проектам.
В LeetCode не нужно уметь проектировать, не нужно умение писать код в команде, не нужно умение по логам с прода найти проблему.
И вот эти плоды мы сейчас пожинаем. Приходят разрабы умеющие только писать простой код. А всё остальное они не умеют.
Где-то Leetcode собеседования, может, и не имеют смысла. Но в FAANG, где их придумали, это сделано осознанно и с конкретными целями.
Привет! Давно понятно, что алгоритмы не отражают реальный уровень кандидата. Но на начальных этапах (стажеры, джуны) я не вижу иного способа проверить уровень человека. Алгоритмам должны учить в ВУЗе и если он освоил эти знания, то с высокой долей вероятности, он сможет решить и бизнесовые кейсы на работе (есть опыт решения нестандартных задач, хоть и не связанными напрямую с бизнес кейсами). А чем более опытным становится кандидат, тем меньше спрашивают такие вещи на собесах.
Т.е. мне на 2м курсе универа рассказали про алгоритм, и мы даже лабу сделали. И я его должен вспомнить через 3-5 лет ? Учитывая что в практике он нигде не встречался
На фига помнить и на фига вспоминать? O_O
Цель задания выяснить способны ли вы самостоятельно придумать алгоритм, и для этой цели то, что вы забыли - прекрасно.
Гениально, придумай алгоритм того, чего ты не знаешь
Так и представляю, как кандидат придумывает алгоритм Дейкстры на собеседовании ))
Сам Дейкстра рассказывал что придумал алгоритм на ходу - взял обход в ширину и заменил обычную очередь на очередь с приоритетами. Больше времени заняло доказательство, что ищется действительно кратчайший путь. Пример не удачный. :)
Сам Дейкстра рассказывал что придумал алгоритм на ходу - взял обход в
ширину и заменил обычную очередь на очередь с приоритетами. Больше
времени заняло доказательство, что ищется действительно кратчайший путь.
Пример не удачный. :)
Тут многие писали, что на собесе и 10 строк не могут написать, а вы тут про алгоритмы. А то мы сейчас еще Менделеева начнем в пример приводить, а почему и нет, ему вообще во сне приснилось
Обычно на интервью не дают задачку, решение которой - какой-то именнованный крутой алгоритм. Чаще всего, вам надо лишь с нужной стороны воткнуть данные в стандартный map. Или отсоритировать данные стандартной же сортировкой а потом пройтись по ним двумя индексами на встречу. Или применить бин-поиск (встроенный lower_bound катит вполне). Самое алгоритмичное - это написать обход в глубину.
С алгоритмами в духе LeetCode на собеседованиях пора кончать