Большинство вакансий рассчитано на что-то между разработкой приложений и системным дизайном. Но при этом многие из тех, кто проводит технические собеседования, уделяют время только задачам на знание алгоритмов и системного дизайна – и ничему больше.
Такой подход основан на идее, что, если человек знаком с алгоритмами и системным дизайном, то и на разработку приложений ему хватит способностей. Это спорное утверждение. Создание приложений требует обширного набора навыков. Они не нарабатываются сотнями часов заучивания паттернов в решениях задач на алгоритмы. Да и рассматриванием сильно упрощенных версий системного дизайна Netflix, Uber или Twitter Threads делу не поможешь. Навыки разработки приложений оттачиваются путем… ну, разработки приложений. Но часто на технических собеседованиях они даже не принимаются в расчет.
Собеседования с алгоритмами
Для ясности: я говорю о задачах на алгоритмы в духе LeetCode. Большая часть подобных собеседований, на которых мне приходилось бывать, включала задачи среднего и выше уровня с этого ресурса. Обычно их объединяют под названием «структуры данных и алгоритмы».
Как правило, собеседование на знание алгоритмов разворачивается таким образом: кандидату дают задачу, которую он должен решить и для которой должен определить уровень сложности при помощи нотации Big O максимум за тридцать минут. Само собеседование чаще всего длится дольше, но какое-то время уходит на приветствия и обсуждение прочих вопросов.
Предполагается, что кандидат начнет выполнение задания с устного разбора, а затем уже приступит к написанию кода. В процессе решения требуется объяснять свой ход мысли от действия к действию.
Вот несколько примеров таких заданий:
- Максимальная площадь (средний уровень сложности на LeetCode): Дана бинарная матрица m x n, заполненная нулями и единицами. Нужно определить наибольшую по размеру область, которая содержит в себе только единицы, и рассчитать ее площадь.
- Самая длинная подстрока без повторяющихся символов (средний уровень сложности на LeetCode): дана строка s, нужно рассчитать длину самой длинной подстроки без повторяющихся символов.
- Слияние отсортированных списков в количестве k (высокий уровень сложности на LeetCode): даны связные списки в количестве k, каждый из них отсортирован в порядке возрастания. Нужно слить все связные списки в один отсортированный.
Подобные задачи довольно занимательны, когда можно поразмыслить о них без спешки. Однако в сценарии собеседования временное ограничение и давящее осознание, что от успешного решения зависит трудоустройство, может сильно бить по нервам. Чтобы не поддаться тревоге, кандидаты занимаются подготовкой – решают задачи заранее, чтобы ознакомиться с паттернами.
Книги вроде «Карьеры программиста» (которую рекомендует к прочтению Meta) в один голос говорят о том, что на такого рода подготовку необходимо потратить от нескольких недель до нескольких месяцев, в зависимости от того, какой у вас уровень и насколько хорошо вы знакомы со структурами данных и алгоритмами.
«Вводный курс для собеседований» от LeetCode включает более 93 примеров задач с решениями, более 67 курирующихся заданий для практики и 12 вопросников. На то чтобы одолеть все эти материалы, параллельно работая и пытаясь жить нормальной жизнью, как, полагаю, и обстоят дела у кандидатов, могут уйти месяцы.
И это подводит меня к следующей мысли.
Не тратьте впустую ценное время кандидатов
Типичная серия собеседований включает две сессии, посвященные алгоритмам, и одну, посвященную системному дизайну. То есть 66% времени отведено под то, что разработчик, вероятно, будет использовать на протяжении менее чем 1% от всей продолжительности своей карьеры.
Я занимаюсь разработкой ПО больше двадцати лет. Алгоритмами я занимаюсь только в двух случаях:
- для собственного удовольствия – головоломки весьма увлекательны, когда некуда торопиться и не из-за чего нервничать;
- при подготовке к собеседованиям.
Если же подобные задачи возникают в ходе реальной работы, я использую библиотеки (обычно встроенные), которые прошли с нами огонь и воду. Так как в этой области я не специализируюсь, вероятность того, что я смогу предложить что-то лучше, нулевая.
Очень немногие осваивают алгоритмы непосредственно в процессе работы. Нужно потратить многие часы, чтобы изучить их на уровне, достаточном для успешного прохождения собеседования, однако при этом они имеют мало отношения к рабочим обязанностям.
Собеседования, построенные на алгоритмах, дают ложные сигналы
Задачи на знание алгоритмов на собеседовании показывают только одно: кандидат достаточно натаскан, чтобы узнавать паттерны и подбирать решения. Но об общем уровне подготовки разработчика они ничего не говорят – они требуют не умения решать проблемы, а умения выявлять знакомое и длительной практики.
Сосредоточившись на способности кандидата решать задачи на алгоритмы в искусственных условиях, вы пренебрегаете другими факторами, необходимыми при разработке приложений. Самый существенный из них сводится к тому, умеет ли кандидат преобразовать требования в решения, которые закрывают потребности бизнеса. Клиентов, приходящих с запросом отсортировать пузырьком лучше, чем у конкурентов, немного. Кроме того, ИИ уже сейчас справляется с этим успешнее, чем люди (AlphaDev предложил алгоритм, который производит сортировку на 70% быстрее, чем существующие, для библиотеки libcc++).
В лучшем случае вы отберете людей, которые способны с хорошей производительностью заниматься разработкой. В общем случае вы отберете людей, которые достаточно корпели над алгоритмами, чтобы справиться с заданиями на собеседовании. В худшем случае, вы оттолкнете многих кандидатов (например, нейроотличных) попытками подловить их незнании особо затейливых алгоритмов.
Альтернативы для рассмотрения
Так что же делать, вместо того чтобы прибегать к алгоритмам на собеседованиях? Создавайте задачи, которые в большей степени напоминают то, чем, по вашим ожиданиям, разработчику придется регулярно заниматься на работе, и которые связаны с навыками, необходимыми для этой работы.
Например, попробуйте сосредоточиться на сигналах такого рода:
- Способность переводить потребности бизнеса, функциональные и нефункциональные требования в эффективные решения
- Умение разбивать сложные проекты на доступные задачи и шаги
- Применение дизайн-паттернов
- Использование определенных принципов при построении архитектуры, например Event Driven Design, API First или Buy vs. Build.
- Способность определить, что стоит автоматизировать (например, билды и тесты при непрерывной интеграции)
- Умение результативно проводить инспекцию кода и понимание преимуществ этой процедуры
- Понимание плюсов и минусов использования корутинов async и threading при работе с серверами
- Умение выявлять возможности для оптимизации производительности кода
- Способность находить баги и устранять проблемы в предложенном фрагменте кода
- Умение проводить рефакторинг с прицелом на большую читабельность и простоту для поддержки
- Эффективная интеграция API в ПО
Не знаете, с чего начать подобную проверку? Coding Challenges – отличный ресурс с задачами, подходящими под эти требования. Они будут хорошим подспорьем для подготовки к собеседованию, неважно ведете ли вы его или проходите.
Стоит ли мне изучать алгоритмы?
Изучение алгоритмов в целом повысит ваш уровень как разработчика. Но это не значит, что вы обязаны уметь с ними справляться с ними за полчаса, параллельно объясняя свой ход мысли. Подобные умения не имеют ничего общего с проблемами, которые в реальности возникают при разработке ПО. Они имеют какую-то ценность только в искусственной среде собеседований, которая ущербна и нуждается в изменениях.
Советую вам начинать разбираться со сложными алгоритмами, когда у вас есть свободное время и на вас не давит необходимость как можно скорее найти работу. Самое полезное, что вы можете узнать в процессе их изучения – нотация Big O и сложность. Понимание Big O поможет вам выявлять излишнюю сложность при разработке приложений и систем.
Если вы хотите отправить резюме в компанию, которая использует задачи на алгоритмы для отбора кандидатов, то у вас только два варианта:
- отказаться делать задания такого рода
- изучить алгоритмы и отработать выполнение заданий в среде, близкой к условиям собеседования
Только один из этих вариантов повышает ваши шансы получить работу. Если она вам нужна, идите по второму пути. У подобных собеседований есть серьезные недостатки. К сожалению, если вы хотите устроиться в компанию и не можете позволить себе роскошь настаивать на своем, вам придется справиться с заданиями, чтобы добиться желаемого.
Вот список ресурсов, которые помогут вам в изучении алгоритмов и Big-O.
В заключение
Мне хотелось бы увидеть перемены в нашем подходе к проведению технических собеседований. Сам я не даю таких заданий на собеседованиях, которые организую.
Если вам предстоит провести собеседование, подумайте, каким образом будете оценивать технические навыки. Если та вакансия, на которую вы ищете человека, действительно предполагает работу с алгоритмами, то, разумеется, без колебаний проверяйте эти знания. Если речь идет о разработке и приложений или чем-то более абстрактном, то завязывайте с этим.
Комментарии (245)
no404error
30.11.2023 13:11-31Весьма специфично, но главное в том, что не понятен фактор мотивации. Время выполнение кода? Расход памяти? Запросы?
Напомнило мне одно из своих "просранных" собеседований, где я показал код скомпилированный в 19098 байт на TMTPascal и расходующий 9921855 байт памяти, но победило какое-то чмо с кодом на C#, с расходом памяти в 2 гигабайта.
Alexandroppolus
30.11.2023 13:11+36Если там была вакансия по C#, то результат выглядит закономерным..
Mirn
30.11.2023 13:11+17во первых разработка это командная работа. Его сообщение не показывает дружелюбность в команде и командной работы. Я бы не хотел работать в команде с тем кто даёт такие отзывы.
во вторых а нужна ли была оптимизация? я как то в конце 2000ых разрабатывал умные часы на 16кб флеша и 4кб озу и просто написал с нуля простенькую либу визуальных компонентов и их рендеринга, оно потребляло менее 10мА от часовой батарейки-таблетки и с оптимизацией даже тогда я не парился вообще, просто надо было написать аккуратно и без излишеств и свисто-перделок. Зато отлично понимаю что оптимизация порой путь в один конец, способ сделать код нечитаемым и не поддающимся правке другими из твоей команды. А исходный код он не для CPU/MCU код в основном для команды и для тебя в будущем.
MiraclePtr
30.11.2023 13:11+148победило какое-то чмо с кодом на C#
Кажется я догадываюсь, почему вас не взяли
ef_end_y
30.11.2023 13:11+7Вы привели какие-то абстрактные цифры. Что было в требованиях, от того и надо плясать. Скорость работы? Понятность кода? Портируемость? Хотя, как заметили выше, скорее всего не прошли по личностным качествам
HSerg
30.11.2023 13:11+4А почему именно TMTPL из девяностых? Активный пользователь OS/2? На момент C#/2Gb были популярны уже совсем другие языки программирования.
Dolios
30.11.2023 13:11+22Алгоритмы не нужны, да... А потом на код ревью приходится объяснять человеку, что он понаписал квадратов на ровном месте и как из-за этого всё будет весело работать у клиента.
Не тратьте впустую ценное время кандидатов
Изучение алгоритмов, это время потраченное не впустую.
Если же подобные задачи возникают в ходе реальной работы, я использую библиотеки (обычно встроенные), которые прошли с нами огонь и воду.
Без понимания, как оно всё работает, можно выбрать, например, библиотечный, но нестабильный алгоритм сортировки, а потом получить жалобы от клиентов на то, что у них списки скачут. Ну и про эпичны бмблиотечный left-pad тоже не будем забывать.
gatoazul
30.11.2023 13:11+28Да теоретически все возможно. А на практике как часто проекты проваливались из-за неправильных алгоритмов?
igor_suhorukov
30.11.2023 13:11+22А на практике я видел легаси на Struts2 framework, Coherence кластеры связанные в спагети из его процессоров и несколько проектов реинжениринга которые умерли раньше системы которую пытались модернизировать, видел код состоящий из всех возможных паттернов, очень хорошо покрытый тестами всех возможных в компании перед банкротством, слышал в лифте разговор интервьюверов которые не понимали зачем они задают вопросы про последний стандарт C++, надувают щеки перед кандидатом и собеседуют в много этапов и с алгоритмами как в гугл, если их легаси система собирается только под 32разрядную x86.
И не разу не видел чтобы кто-то реализовывал с нуля в проекте свою сортировку или графовый алгоритм эффективнее чем он есть в доступных библиотеках.
Обычно ИТ системы можно разделить на два вида - приносит деньги и пожирает бюджет. Даже если это махровое легаси и оно кормит компанию, то набираются "жертвы" на ее поддержку и написание новых функций. Успешные Greenfield проекты на работе - это большая редкость.
sshikov
30.11.2023 13:11+7И не разу не видел чтобы кто-то реализовывал с нуля в проекте свою сортировку или графовый алгоритм эффективнее чем он есть в доступных библиотеках.
Ну, зависит от размеров графа. У нас тут в соседнем проекте напряглись и сделали поддержку графов размером с большую соцсеть масштабов VK например - в чем я уверен точно, так это в том, что библиотечного такого не существует.
trueMoRoZ
30.11.2023 13:11+8Ну вот и сколько раз в жизни у вас такая потребность возникла? И сколько у вас было время на это? А профессиональная судьба ваша зависела от этого?
sshikov
30.11.2023 13:11Ну да, эта работа единичная, ее делали может три-четыре человека. Но при этом ниоткуда не следует, что нет любой другой похожей работы, где библиотечные функции не подходят.
shadwar
30.11.2023 13:11Это лишь означает, что для решения подобной редкой задачи достаточно просто знать, что за графы такие, а дальше рнд и вперёд. Знать все возможные алгоритмы на графах заранее для решения вовсе не обязательно.
sshikov
30.11.2023 13:11+2Заранее конечно нет, но некоторая базовая подготовка как правило сильно сокращает сроки оного РНД.
igor_suhorukov
30.11.2023 13:11У нас тут в соседнем проекте напряглись
Знаком с людьми из QuestDB и из ClickHouse и изучал исходники этих проектов. Но такая работа единичная на рынке, а желающих обычно стоит очередь.
Есть что почитать про ваш графовую реализацию?
PrinceKorwin
30.11.2023 13:11+5... или графовый алгоритм эффективнее чем он есть в доступных библиотеках.
Ну я делал. Java. И это было более чем оправданно. Обычно если у вас очень высокие требования по памяти/скорости, то не нулевая вероятность не найти готовое решение именно под ваши данные.
ef_end_y
30.11.2023 13:11+3Более того, если речь идёт о каком-то сложном алгоритме, то скорее всего лучше использовать протестированную библиотеку чем изобретать велосипед
wataru
30.11.2023 13:111) Часто библиотек нет. Вот задача и такие на интервью дают часто. В задаче надо лишь в нужное место впендюрить map. Это слишком частный случай для библиотек.
2) Даже если библиотеки есть, их нельзя нагуглить, не зная ключевые слова. Например sliding window max (а эту задачку с литкода мне приходилось в прод коммитить).
3) Еще чаще вы даже не заметите, что тут нужен "сложный алгоритм". Потому что даже на литкоде большинство задач сформулированы "сделайте то-то и то-то" и можно буквально перевести условие в очень неэффективный код. А когда вам даже условие не дано, задача стоит - запилить фичу, то у вы в голове сформулируете "надо сделать то-то и то-то", и это у вас будет решение, а не задача.
4) На интервью обычно не спрашивают какие-то действительно сложные алгоритмы, которые надо годами отлаживать в библиотеках.
speshuric
30.11.2023 13:11+7На практике в трёх крупных финансовых организациях я неоднократно видел как системы под чуть возросшей нагрузкой заваливались из-за "квадратов". Причём некоторые моменты весьма похожи: несколько "квадратов" на последовательной конкатенации строк, несколько на поиске в списке/массиве/таблице, которые пополняются в цикле.
Завалился ли из-за этого какой-то крупный проект? Нет. Если один неосторожный разработчик может завалить неэффективным локальным кодом весь крупный проект, то проблема точно не в разработчике.
Были ли заметные финансовые потери? Да. И явно несопоставимые даже с несколькими месяцами работы разработчика.
SpiderEkb
30.11.2023 13:11+5Завалился ли из-за этого какой-то крупный проект
Как пример из реальной жизни. Крупный банк. Внедряется патч. Вроде как в штатном режиме все работает, все оттестировано. Но... Наступает время пиковых нагрузок (предновогодняя суета и массовый шопинг). И... Патч начинает жрать ресурсы процессора, тормозить сам и все что с ним связано. В результате миллионы клиентов по все стране не могут в магазинах расплатиться картами банка - "нет ответа от банка". У кого-то с 3-5-го раза получается, у кого-то не получается вообще. Сопровождение в мыле откатывает патч, налаживает WA. Решили часа за два все, но эти два часа были адом для всех.
Дальше - "комиссия по инцидентам", расследование, доработка... Но налицо и репутационный ущерб и прямой финансовый. Не помню уж, дошло тогда до штрафов от регулятора или нет, но в принципе такое тоже возможно.
Вот считать это "завалом крупного проекта" или нет?
speshuric
30.11.2023 13:11+7Вот считать это "завалом крупного проекта" или нет?
Нет, конечно :) Завал проекта, это когда на проектном комитете или на правлении (или на подобном сборище) скажут, что проект завален (что в рамках корпоративной культуры большинства банков практически невозможно - умение признавать ошибки в списке обычно не значится). То что вы описываете, был "серьёзный локальный инцидент, который грозил перерасти в глобальный, но, благодаря подразделению во главе с Имярек И.О., был успешно решён".
funca
30.11.2023 13:11+9Алгоритмические проблемы хорошо отлавливают регрессии и перформанс тесты уже на самых ранних стадиях. У меня не было на практике такого, чтобы прод лег именно из-за алгоритмов.
Обычно перформанс деградирует медленно, по мере увеличения кодовой базы, наростания слоев абстракций и каких-то костылей. У вас просто нет какой-то понятной точки, которую можно переписать с O(n^2) на O(n log n). Для того, чтобы с этим бороться нужно в первую очередь хорошо знать код своего проекта. При оптимизации вы оперируете не функциями, а компонентами или даже микро-сервисами.
На моей практике к фатальным инцидентам в продакшен чаще приводят ошибки в конфигурации - когда ошиблись буквально в одном символе или перепутали параметр под конкретный энв. Причем на патч для конфига в пару строчек смотели в общей сложности человек 30, начиная с аналитика в момент поставки задачи, разработки, тестирования, релиз менеджеров и заканчивая опсом, который это накатывал. Но ошибку обнаруживает лишь эксплуатация.
Иногда пролетают ошибки интеграции, когда источник данных не держит по перформансу или есть проблемы с доступностью. Но это решается на уровне архитектуры, а не алгоритмов.
plFlok
30.11.2023 13:11+14у меня был кейс: бизнес хотел аналог реалтаймовых персональных рекомендаций. Нужно было достать из базы, условно, все "items", поскорить их функцией, персональной для юзера, выдать первые 100 из списка. Потом, если юзер промотал всю ленту рекомендаций, надо выдать вторые 100 элементов из списка.
Автор кода, который реализовывал задачу, доставал, скорил, вызывал .sort(), потом .slice(0, 100). Код был читабельным, работал за O (N log N). Автор заявил "ну оно ж влезает в память" и был прав. Всё вычисление повторялось и для второй страницы, только брался следующий slice из результата.
Потом с ростом базы, числа юзеров и общего qps началась беда - "влезает в память" перестало влезать, а те машины, на которых всё-таки памяти в определённый момент хватало, не успевали ответить за отведённый на запрос таймаут.
Автор исходного кода пытался обмазаться кешами. Но не помогало: кеши не заполнялись, ибо расчёты не могли закончиться. И не понятно, как персональные кеши для каждого юзера должны были решить проблему глобально.
И тогда настал мой звёздный час как задрота литкода: я модифицировал k-th order statistic (работает за O(n)), чтоб она ещё могла порционно данные подгружать и не ломаться. Сервис заработал, код стал трудночитаемым неподготовленным человеком.
К чему всё это:
Поймает ли тут проблему регрессионный тест или перформанс тест, если код не был ухудшен, а был изначально "плохо" написан?
Считаем ли этот код "плохим", если на момент его создания он вписывался в имеющиеся требования, а новые требования сформированы были через год в связи с ростом сервиса?
Окей, мы узнали, что код не вывозит. Что делать, если у нас нет leetcode-задрота? Просить начальство удвоить память на серверах в дц? а с O(N LogN), которое не укладывается в таймауты запросов что делать?
За 7 лет работы это был один конкретный случай, где мне пригодилось знание, как самому организовать сортировку быстро. Стоит ли ожидать такое знание от всех кандидатов? до сих пор не могу ответить себе на этот вопрос.
Cheater
30.11.2023 13:11+7Окей, мы узнали, что код не вывозит. Что делать, если у нас нет leetcode-задрота?
Дать задачу на ресёрч обычному разработчику, не "leetcode-задроту". Если он профпригоден, то сможет определить класс задачи и исследовать, что в современной CS имеется для её решения.
plFlok
30.11.2023 13:11+6Ну вот я и пишу, что средний разраб у нас оказался без подозрений, что именно гуглить в области cs, и начал упарываться кешами как единственным известным ему эффективным способом оптимизаций.
Верно ли, что тогда мы считаем обязательными понимание medium-алгоритмов с литкода или хотя бы информированность о подходах к их решению?
light-уровень не рассматриваю, так как он - необходимый минимум, чтоб держать хеш-мапы правильной стороной вверх
Hivemaster
30.11.2023 13:11-2А потом пришёл унылый ПТУшник и реализовал это же одним запросом в БД или пайплайном спарка, собранным из готовых компонентов?
plFlok
30.11.2023 13:11+5то есть всё-таки просим у начальства второй датацентр под бесконечные сортировки на спарке?)
PuerteMuerte
30.11.2023 13:11+9А на практике как часто проекты проваливались из-за неправильных алгоритмов?
В моей практике за почти четверть века - ни разу не проваливались из-за алгоритмов, но чуть ли не каждый второй жрал намного больше денег у разработчиков/эксплуататоров, и нервов у пользователей, чем мог бы. Поэтому если можно взять разработчика, который умеет собственно программировать, это всяко лучше, чем брать того, который не умеет.
SpiderEkb
30.11.2023 13:11+1Легко.
У меня (и не только у меня) в работе сейчас дополна задач по исправлению "дефектов производительности промсреды". Когда-то, когда клиентов было 20-25млн, все это укладывалось в заданные временные окна. Сейчас, когда клиентов стало 50млн оно "вдруг" перестало укладываться. И само тормозит и задерживает смежные процессы
И вот смотришь код и думаешь - ну вот как там можно писать-то было? Вообще ни о чем не думал? Все просто тупо "в лоб". Даже без мысли "а нельзя ли вот это быстрее сделать?"
В результате даже чуть наморщив ум, и то в 3-4 раза получается ускориться. Это без всяких "тонких регистровых оптимизаций".
micronull
30.11.2023 13:11+1Иногда в угоду бизнеса и\или на стадии MVP вводятся фичи как можно скорее, а об оптимизации потом подумаем.
SpiderEkb
30.11.2023 13:11У нас такое не проходит, к счастью. Есть "встанет" центральный сервер банка, то никакие фичи уже не спасут.
Но, понятно, что не везде так. Во многих местах "пусть криво-косо, но раньше всех". А потом появляется новая креативная бредея, все кидаются ее пилить, и старое, кривое-косое, уходит в техдолг до тех пор, пока не превратится в дефект. По мне, так такое себе...
micronull
30.11.2023 13:11Это понятно.
Если функционал укладывается по производительности в выделенные ресурсы и согласуется в планируемым ростом, то время можно потратить на обеспечение гарантии стабильности. В т.ч. дополнительные покрытие тестами и т.п.Бизнес как правило в курсе про эту проблему и может запланировать работы по оптимизации на будущее.
Сейчас, когда клиентов стало 50млн оно "вдруг" перестало укладываться. И само тормозит и задерживает смежные процессы
Чем вы и занимаетесь. КМК это вполне грамотный подход.
Разумеется если в коде есть очевидные участки которые можно заранее ускорить, то лучше это сразу заложить.
Но некоторые преждевременные оптимизации могут наоборот усложнить код. Например асинхронность.
Хотя конечно и с асинхронностью можно совладать, если стараться следовать правило, что работа с ней происходит в рамках одного слоя и\или функции.SpiderEkb
30.11.2023 13:11Чем вы и занимаетесь. КМК это вполне грамотный подход.
Оно неизбежно. Вопрос в том, что можно написать левой ногой и потребуется этим заниматься уже через год, а можно сразу нормально и тогда вопрос встанет только через 5-10 лет.
Вот есть некий бизнес-процесс. Очень ресурсоемкий. Временное окно под него 4-5 часов. Когда-то давно так и было. Но сейчас не укладывается - занимает 12-15 часов. Переделываем. Сейчас получаем в пределах часа (обычно 20-30 минут - чего это стило отдельная тема). Т.е. имеем очень большой запас.
Разумеется если в коде есть очевидные участки которые можно заранее ускорить, то лучше это сразу заложить.
Ну я прежде всего про это говорю. Просто когда пишешь - думай сразу о том, чтобы это получалось максимально эффективно, а не первое что на ум пришло.
Но некоторые преждевременные оптимизации могут наоборот усложнить код. Например асинхронность.
Как правило, сложность кода не волнует никого. Волнует как он работает.
Да и 80% оптимизации значительно код не усложняют. Усложняют последние 20% (а то и меньше).
p07a1330
30.11.2023 13:11+3Оно неизбежно
Более 90% IT-кампаний столько не протянет
SpiderEkb
30.11.2023 13:11Ну мы не IT компания... "Дирекция информационных технологий/Управление разработки центральных банковских систем". Наша задача - поддержка работоспособности бизнес-процессов, разработка новых, оптимизация и модификация существующих. Пока банк работает, мы тут нужны.
На этой системе и платформе банк работает с 99-го (насколько знаю) года. В 03-м (по-моему) перешли на новую версию системы и выкупили у ее разработчиков все исходники. Платформа тоже обновляется регулярно (как минимум три поколения серверов сменилось и процесс продолжается)
vvbob
30.11.2023 13:11+2Да все просто. Обычно когда пишешь код, бизнес на тебя давит не в плане - делай что-бы работало как можно быстрее, а в плане делай как можно быстрее. Учитывая что процентов 80 кода обычно и не требуют никакой оптимизации по скорости, это вполне себе прокатывает. Убить неделю на то что-бы вылизать какой-то участок кода, который раз в месяц запускается шедулером и добиться того что-бы он на пару секунд быстрее выполнялся - чаще всего это вообще никому не нужно. Обычно бизнес готов скорее мириться с тем, что в эксплуатации где-то всплывут проблемы производительности, которые потом будут точечно исправлены, чем с тем что весь проект в целом будет пилиться раза в три дольше. Такова селява..
SpiderEkb
30.11.2023 13:11Ну... На нас бизнес не давит в плане скорости разработки. Потому что наша позиция - "вы хотите чтобы быстро, или чтобы рукава одинаковые?". Им нужно чтобы работало корректно и быстро. Тут вопросов нет - центральные сервера банка - это не фичи. Это мастер, mission-critical, мать ее, система.
Убить неделю на то что-бы вылизать какой-то участок кода, который раз в месяц запускается шедулером и добиться того что-бы он на пару секунд быстрее выполнялся - чаще всего это вообще никому не нужно
У нас таки чаще речь о процессах, которые дергаются сотни миллионов раз в сутки. Или, даже если раз в сутки, то работают с десятками миллионов элементов (а есть процессы сравнения 50млн элементов с 300-500тыс элементов по 5-7 разным параметрам) и при этом имеют жесткие ограничения на время выполнения и потребляемые ресурсы процессора.
И там речь не о секундах, а о часах как правило.
vvbob
30.11.2023 13:11Ну так кто спорит, все от задачи зависит. Где-то стоит упороться и выжать из кода все что только можно.
Asker1987
30.11.2023 13:11О том и речь. Автор статьи утверждает, что не надо все знать, ведь можно нагуглить, не торопясь, все антиалгоритмисты в тренде тоже твердят - можно изучить, почитать на досуге, поискать как решить оптимизационную проблему и т.д. И тут же летят оправдания "ой код кривой, потому что некогда вылизывать неделю". Так а может всё-таки надо знать хоть минимум по алгоритмике, чтобы не вылизывать неделю, а делать сразу нормально? Ведь это не отнимет время вовсе, когда знаешь.
CorwinH
30.11.2023 13:11+4Как-то пришли ко мне с такой задачей:
Есть код, который запускается раз в сутки и на основе статистики веб-сервера списывает с клиентов деньги за трафик. Проблема заключалась в том, что код (сервис) с какого-то момента не успевал отработать за сутки.
После переделки код отрабатывал за 5 минут. Предыдущий автор, видимо, не понимал, чем плохи три вложенных цикла. Предполагаю, что если бы он время от времени баловался решением алгоритмических задач, то не написал бы такой код.
Jianke
30.11.2023 13:11+1После переделки код отрабатывал за 5 минут. Предыдущий автор, видимо, не понимал, чем плохи три вложенных цикла
Видел случай, когда функция вызывала функцию вызывающую функцию с вложенностью свыше десятка раз от чего всё дико тормозило. А ведь, людей на полном серьёзе учат, что подобное является правильным подходом.
gatoazul
30.11.2023 13:11Об опасности вложенных циклов знали еще в 60-е годы, когда никаких алгоритмических задач не было.
PuerteMuerte
30.11.2023 13:11+2В 60-е годы наличие избыточных циклов можно было увидеть невооружённым глазом на большинстве задач. Потом кампутеры стали побыстрее, работать на относительно небольших наборах данных стали мгновенно, и это знание подрастерялось.
SlazZy
30.11.2023 13:11+2Я не спорю с основной идеей, но все же добавлю.
Возможно для бизнеса долгое время это было вполне нормальное время работы, а разработчик все таки решает задачи бизнеса. На этапе развития, возможно, это делалось на коленке и за пол часа работы, потому что сроки горели, возможно это даже было MVP, которое так и осталось в проде. Возможно бизнес на тот момент нанимал очень дешевого программиста и получил вполне себе работающий прототип, да, плохо работающий, но долгое время этот код приносил деньги. Когда начались проблемы, бизнес попросил более хорошего программиста оптимизировать код и получил улучшенный вариант. С точки зрения бизнеса это все не выглядит как трагедия, скорее как систематическое развитие.У меня был пример, когда сделали небольшую фичу, при входе на каждую страницу проверка идет ли в текущий момент урок, на который записан пользователь. И работала она супер быстро, отрабатывала где-то за 40-60мс. Потом пришел продакт и попросил другого программиста добавить в запрос проверки еще одно условие. Потом пришел продакт другой команды и попросил другого разработчика добавить еще условие. И каждое из этих условий глобально ничего не ухудшало критически, но скорость запроса упала где-то раза в 3-4. А потом из-за маркетинговой активности резко выросло число пользователей и все стало резко хуже.
Можно придумать множество гипотез. И оборачиваясь назад кажется: "Ну как можно было написать такой ужас?". Но в момент создания этого кода могло быть множество причин почему оно сделано так, а не иначе.
PS Я не оправдываю 3 вложенных цикла, я скорее про сам подход. Что сейчас смотря назад можно много негативного думать про код, но он писался в других условиях и контексте )
knstqq
30.11.2023 13:11+2на практике у меня однажды был в команде человек который неплохо решал задачи на leetcode. Но когда надо было оптимизировать обход данных на продакшене (достать запись из очереди -> обновить очередь обработав связанные записи) вместо оптимизации квадратичного алгоритма он добавил кучу кэшей и низкоуровневых оптимизаций, что уменьшило константу в 10 раз.
На тестовой окружении записей были тысячи, на продакшене - миллионы и помогла его оптимизация ровно на неделю.
santa324
30.11.2023 13:11Очень многие проекты которые я видел, провалилась из-за неправильных алгоритмов. Почему-то люди думают что алгоритм это какой-то изолированный кусочек, но вся система целиком это тоже алгоритм. И вот он часто спроектирован очень паршиво, причины бывают разные, далеко не всегда некомпетентность тех кто его писал. Но знание алгоритмов, как минимум, помогает увидеть эти вещи.
Keeper10
30.11.2023 13:11+6понаписал квадратов на ровном месте
Только надо иметь в виду, что асимптотика важна только на большом количестве элементов. Если у вас их 10 штук, сойдёт даже экспоненциальная сложность.
speshuric
30.11.2023 13:11+1Если у вас вход контролируемый, то может и сойдёт. А если это может сделать внешний пользователь, то можно на DoS нарваться.
knstqq
30.11.2023 13:11во времена выхода XP не предполагали что патчи на OS будут валиться один за одним, поэтому залепили туда экспоненциональную функцию выбора апдейтов. Уж не знаю как именно они умудрились, но видимо думали "откуда может быть сразу больше 5 штук обновлений в очереди"?
Fahrain
30.11.2023 13:11+5Алгоритмы не нужны, да... А потом на код ревью приходится объяснять человеку, что он понаписал квадратов на ровном месте и как из-за этого всё будет весело работать у клиента.
Алгоритмы - это, несомненно, замечательная штука. Но вот у меня в реальной жизни - поддержка сайтов интернет-магазинов, которые уже кто-то за много лет до меня пилил и поддерживал. И делал это далеко не один человек, последовательно друг за другом.
В итоге там, как правило, замечательные вещи:
запросы к базе внутри цикла, который тоже внутри цикла - на сотни элементов каждый
запросы на массовое обновление записей в базе - без транзакций
использование вызовов api (с запросами к базе) вручную там, где этого можно было избежать просто поставив правильный параметр в вызове базового компонента
использование api способом, про который прямо написано в документации крупными красными буквами на выделенном фоне, что так делать не нужно
избыточные запросы из базы данных всего-всего - из чего 99% не будет использоваться, вместо запроса только нужных данных
и еще многое-многое другое
И всё это работает, долго... Пока клиент не начнет товары тысячами добавлять - тут-то это всё колом и встает на любом железе.
Уверен, все эти люди вполне успешно проходили собеседования)
Rorg
30.11.2023 13:11+8Простите, но мне кажется, что не пихать цикл в цикл на сотни элементов каждый, да еще и с блокирующими операциями – это больше здоровая логика, а не знание алгоритмов.
PuerteMuerte
30.11.2023 13:11+1это больше здоровая логика, а не знание алгоритмов
Знание, точнее, не знание, а умение придумывать алгоритмы - это и есть всего лишь одно из прямых следствий наличия здоровой логики. Проверкой которого, в частности, можно достаточно достоверно подтвердить, что логика у собеседуемого таки имеется.
Jianke
30.11.2023 13:11+2Именно так! Нужен не тот, кто помнит на зубок алгоритмы, а тот кто может их создавать по мере надобности!
sergey-gornostaev
30.11.2023 13:11+2Лично у меня в проекте самый свежий пример N+1 нахренячил именно человек с профильной вышкой, регулярно щеголяющий своей математической подготовкой и алгоритмической базой.
Dolios
30.11.2023 13:11Плохо, что некоторые руководители не знакомы с концепцией необходимых и достаточных условий.
bogolt
30.11.2023 13:11Проблема не в логике а том что таким людям все равно как оно там будет работать. Задачу закрыл и дальше пошел. А проверять работает ли его решение в принципе, и уж тем более как хорошо оно работает не барское это дело.
SpiderEkb
30.11.2023 13:11+1Это как? Статус Resolved у задачи ставится только после внедрения на прод. А до этого она должна пройти все стадии тестирования - компоненты, бизнес, нагрузка, интеграция... И все должны согласовать внедрение.
bogolt
30.11.2023 13:11+2В разных компаниях разные процессы. Есть много тех кто не тестирует или тестирует недостаточно чтобы выловить все очевидные проблемы. А в том случае девиз был "хуяк-хуяк и в продакшн" подкрепленный девизом Великого Дома Грейджоев "Мы не тестим".
С другой стороны и в конторах где процессы более-менее выстроены все равно попадаются люди которые спешат скорее запушить хоть что-то, объявить это решением, а потом после того как их код не соберется, или не пройдет тестирование пушат еще один коммит. А потом еще и еще, либо пока тестер не сдаться либо пока каким-то чудесным образом все баги не закончатся.
ALexKud
30.11.2023 13:11Да, такое повсеместно есть. Вот например, простое grud приложение для локала, но используется в нем php, pyton и postgres, Web server. А все потому что разработчик решил на нем поизучать pyton и кроме php ничего не знает. Ни php ни pyton там вообще не нужен. Этого разработчика давно нет в конторе а приложение живёт своей жизнью и
постоянно глючит, сбоит и тп. Там же приложение для настройки приборов сделано на C# а в качестве БД используется файл xml. Представьте, что разработчикам внутреннего софта нужно ещё редактировать тысячи строк xml файла с нехилой вложенностью. Этого разработчика тоже уже нет в компании, все придожение переписано под БД и добавлен человеческий интерфейс редактирования конфигурации прибора, сетевая и локальная версия под sqlite. Отдельно был квест с автоматическим переносом существующих 50 xml файлов сложной разной стуктуры в бд. Но в общем все получилось через специальную встроенную процедуру на сервере.
Пришлось придумать свой алгоритм переноса в таблицы без потери связи, так как структура xml варьировалась от файла к файлу. И это под sql кодом. В общем даже можно статью об этом написать, может кому пригодится.
В любом случае умение создать алгоритм нужно, пусть даже неоптимальный и простой.
ALexhha
30.11.2023 13:11В любом случае умение создать алгоритм нужно, пусть даже неоптимальный и простой.
ну эти примеры явно не про алгоритмы, а скорее про архитектуру
SpiderEkb
30.11.2023 13:11+2По поводу избыточных запросов - тут палка о двух концах.
У нас каждая поставка проходит нагрузочное тестирование со сбором множества статистик. И они показывают что зачастую сложные запросы, куда заложена вся логика, содержащие агрегирование (group by и агрегатные функции) работают на больших объемах данных дольше, чем более простые, "линейные", хоть и несколько избыточные запросы где то же агрегирование вынесено на этап обработки полученной выборки.
Aniro
30.11.2023 13:11+4Для того чтобы оценить не нафигарит ли кандидат квадратов внутри квадратов не нужны задачи из леткода, достаточно спросить чтонибудь совсем простое - например найти N наибольших чисел в массиве, а потом спросить про вычислительную сложность решения. И да, я думаю это обязательная часть интервью, но это занимает пять минут.
И конечно это не касается областей где разработчику действительно нужно глубоко знать алгоритмы, но таких сейчас относительно немного.Rorg
30.11.2023 13:11+2Мне кажется, было бы интересно, если кандидату давалось задание оптимизировать там пару алгоритмов. Ну то есть, дается решенная кое как задача из леткода. Код рабочий, но он O(n^2). Кандидат должен определить "проблемы" в коде и исправить их доведя в идеале до О(1). Мне кажется – это позволит оценить мышление кандидата, а не просто насколько он зазубрил алгоритмы или типовые задачки.
Dolios
30.11.2023 13:11+6Именно это и происходит на алгособесе, только O(n^2) тоже самостоятельно написать надо.
ALexhha
30.11.2023 13:11+2достаточно спросить чтонибудь совсем простое - например найти N наибольших чисел в массиве, а потом спросить про вычислительную сложность решения. И да, я думаю это обязательная часть интервью, но это занимает пять минут.
а потом мы слышим - "Писать код на листике ?! Вы чо холопы, я сеньйор!", "Писать код на собеседовании - это большой стресс!!!". Из того что я понял, ноут с ide тоже не особо поможет
Dolios
30.11.2023 13:11+6не нужны задачи из леткода, достаточно спросить чтонибудь совсем простое - например найти N наибольших чисел в массиве, а потом спросить про вычислительную сложность решения.
Так это и есть "задача с литкода". Вот, практически такая же: https://leetcode.com/problems/kth-largest-element-in-an-array/description/
А вот еще задача на удаление дубликатов из массива: https://leetcode.com/problems/remove-duplicates-from-sorted-array/description/И всё это те самые страшные и ужасные задачи с литкода, которыми всякие подонки валят на собесах Великих Программистов. Вы, похоже, просто не понимаете, что такое "задачи с литкода" и что спрашивают на собеседованиях. Но, зачем-то, спорите. У меня складывается ощущение, что большинство спорщиков этого не понимает.
Tsimur_S
30.11.2023 13:11+1Так это и есть "задача с литкода".
А если на литкоде будет FizzBuzz и меня попросят его написать на собесе то я могу впоследствие говорить что я прошел литкод собеседование?
Вы, похоже, просто не понимаете, что такое "задачи с литкода" и что спрашивают на собеседованиях. Но, зачем-то, спорите. У меня складывается ощущение, что большинство спорщиков этого не понимает.
Ну так согласуйте контекст что такое "задачи с литкода" а то глаза устают от белизны пальто.
Могу предложить свой - основное возмущение вызывают специфические задачи на DP, редко применяемые в реальной жизни, сложные для восприятия новичку но зато столь любимые на олимпиадах.
Dolios
30.11.2023 13:11+2Вы можете говорить всё что угодно, кто же вам запретит?
Могу предложить свой - основное возмущение вызывают специфические задачи на DP, редко применяемые в реальной жизни, сложные для восприятия новичку но зато столь любимые на олимпиадах.
Много раз у вас такое на сабеседовании спрашивали? А вы часто такое спрашиваете? В подавляющем большинстве случаев речь про easy-medium, которые в спокойной обстановке программист способен решить за 5-7 минут, но с учетом стресса и доски на собесе даётся 20-30 минут.
Но нет, кто-то слышал как соседа брата жены в гугле dp hard спросили и сделал далеко идущие выводы, что алгособесы это плохо.
Rorg
30.11.2023 13:11В подавляющем большинстве случаев речь про easy-medium, которые в спокойной обстановке программист способен решить за 5-7 минут, но с учетом стресса и доски на собесе даётся 20-30 минут.
Просто стало интересно, а вы сами решаете задачу, которую даете на собеседовании?
Dolios
30.11.2023 13:11+1А как иначе-то? Я выше писал, что начинаю я с задачи; "распечатайте словарь, у которого ключи, это строки, а значения числа". Часть мидлосиньоров этот этап не проходят, потому что стресс и слишком сложно. А потом они, наверняка, пишут в интернете, что я мудак и завалил их на алгособесе.
Rorg
30.11.2023 13:11+1Спасибо. Тогда к вам вопросов нет. Просто бывали случаи, когда сам "опрашивающий" зависал с задачкой и потом заканчивал фразой "... и вообще чего это я должен задачи решать, это вы тут на работу устраиваетесь."
PS: Про автопилот для парусной лодки, это была попытка пошутить. Видимо не очень удачная)
funca
30.11.2023 13:11+3easy-medium, которые в спокойной обстановке программист способен решить за 5-7 минут, но с учетом стресса и доски на собесе даётся 20-30 минут.
Я проваливал на собеседованиях даже простые задачи. Здесь как в вузе. Если тема находится прямо сейчас в голове, то задача решается на рефлексах. Но через год уже нужно напрягать голову, что вспомнить. Через 20 лет это не немного грустный челенж. При этом вечером, когда есть возможность войти в поток и спокойно подумать, все решается действительно легко и без подсказок из гугла.
Kergan88
30.11.2023 13:11+1А если на литкоде будет FizzBuzz
В смысле "если будет"?
https://leetcode.com/problems/fizz-buzz/
собственно, в 99 случаях из 100 "литкодовские задачи с собеса" - это вот и есть что-то уровня физзбуза.
Просто есть люди для который и физбузз - рокетсаенс. И потом они вайнят из-за "алгоритмических собеседований". Хотя для любого нормального программиста это не "алгоритмическое собеседование", а просто тривиальный вопрос, с которым даже не прогуливавший уроки информатики школьник справится.
Могу предложить свой - основное возмущение вызывают специфические задачи на DP
А вам лично задачки на дп задавали на собесах? Или вы знаете людей, которым задавали? Или которые задают?
Я вот - нет.
wataru
30.11.2023 13:11Мне в гугле дали. Одна из 5 задач была на ДП. Хотя, в принципе, можно было и без ДП какой-нибудь обход в ширину на графе состояний запилить, даже не заная термина. Задачка была довольно простая.
wataru
30.11.2023 13:11+1например найти N наибольших чисел в массиве, а потом спросить про вычислительную сложность решения
Но это и есть баянистая задача на интервью во всякие ФААНГИ. Это кровь и плоть от этих презираемых тут "алгоритмических задачек". Можно, конечно, просто обсудить, как бы кандидат это решал, а можно после этого потратить еще 10-15 минут на написание кода. Заодно можно посмотреть, что кандидат может свои мысли перевести в код, а не только случайным образом менять исходник, пока не заработает.
sergey-gornostaev
30.11.2023 13:11Интересно, есть хоть один язык программирования, в стандартной библиотеке которого heap sort уже не реализован?
wataru
30.11.2023 13:11Вряд ли их очень много, но в C++ - реализован. Ну, правда, придется руками вызвать make_heap и в цикле pop_heap. Но в этой задаче и не надо heapsort делать, а надо лишь heap использовать. Который в огромном количестве языков есть (тот же priority_queue в C++).
Flux
30.11.2023 13:11+11Как и ожидалось набежали свидетели "мы тут продукт делаем".
Потом эти же свидетели ноют в соседних статьях о том что весь софт теперь на электроне написан и блокнот жрёт 2 гига оперативки а работает медленнее чем приложения из 98й винды.micronull
30.11.2023 13:11+2весь софт теперь на электроне написан
Я конечно ничего против не имею алгоритмов. Так как считаю что знать структуры данных и хотя бы поверхностно понимать в чем преимущества и минусы быстрой сортировки, но скажите пожалуйста, в чем связь написание ПО на электроне с алгоритмами?
Искренне не могу понять корреляцию. Если что мой стек сейчас Go.
Fahrain
30.11.2023 13:11+4Бесит, когда приложение на одну страничку с десятком картинок "для красивости оформления" и несколькими строчками текста порождает пяток процессов и каждый из них занимает в оперативке 100+ мб.
Т.е. проблема не в электроне, а в том, что для таких вещей он явно-избыточен и именно этим и бесит.
neyronon
30.11.2023 13:11+2Везде есть оптимальная середина. Так что это нормально, что люди критикуют крайности.
iroln
30.11.2023 13:11+6Без понимания, как оно всё работает, можно выбрать, например, библиотечный, но нестабильный алгоритм сортировки
Так а просто поговорить про стабильность сортировки и случаи, когда это нужно, а когда нет, почему нельзя? Ну поговорите на собеседовании про алгоритмы и структуры данных если это важно и критично на вашей работе. Если человек плавает и не знает чем отличается связный список от массива, то вы сразу сделаете для себя выводы. А если он знает и понимает, он возьмёт готовое и применит как надо и где надо. И не нужно ему мозг выносить и считать за дурака, потому что он не смог за 30 минут решить на бумажке какую-то хитрую задачу с литкода.
Если вы, например, занимаетесь прикладным ПО, в чём смысл задрачивать кандидата на реализацию очередной кучи и очереди с приоритетами для слияния отсортированных списков, чтобы что? Что это вам даст, что вы узнаете о способностях кандидата? Как вы поймёте, может он вам подойти или нет? Просто поговорить о таких вещах какая-то особая религия не позволяет? Собеседование - это от слова беседовать, ведь правда?
Зачем, казалось бы, умные люди превращают собеседования в идиотизм и дурдом? Давайте устроим 5 одинаковых сессий на алгоритмы как в Яндексе делают. А что такого? Такие собеседования просто не работают, не говоря уж о потраченном времени и стрессе, который от них испытывают кандидаты. Это нонсенс.
Norgorn
30.11.2023 13:11+5Что это вам даст, что вы узнаете о способностях кандидата?
Не люблю задрачивать алгоритмы, но вот тут возник вопрос. А не окажется ли, что кандидат, способный решать средние задания с литкода, в 90% случаев будет работать лучше того, кто не способен?
То есть, я прекрасно понимаю и разделяю рассуждения, что все эти задачи, да ещё в стрессе, не очень нужны. Но как оно на практике? Может быть, просто есть практический факт, а остальное неважно? (ответа я не знаю, потому что не собеседую)
iroln
30.11.2023 13:11+4А не окажется ли, что кандидат, способный решать средние задания с литкода, в 90% случаев будет работать лучше того, кто не способен?
Статистических данных и исследований на эту тему я не видел, но опыт и здравый смысл подсказывает мне, что скорее всего тут нет корреляции.
Работа разработчика в современном промышленном софтостроении состоит процентов на 90 из другой деятельности, большую часть навыков и опыта для которой не проверяют на собеседованиях, а что-то вообще невозможно проверить и понять за час времени вне реальной рабочей атмосферы и задач, даже задавая правильные вопросы, а не задалбывая кандидата специальной олимпиадой по "программированию".
Также есть мнение, что собеседования в принципе не совсем работают для найма профессионалов и опытных людей. На собеседовании можно отсеить совсем неопытных, хитрецов, жуликов и т.д. (если они, конечно, не прокачали навыки пускать пыль в глаза и проходить собеседования). Если вы ищете старших разработчиков, лучше проводить минимальные собеседования, а нанимать и увольнять быстро. Для этого и существует испытательный срок для сотрудников. Если спустя месяц-два видно, что человек не справляется, не тянет, не устраивает команду по каким-то причинам - увольняйте.PuerteMuerte
30.11.2023 13:11+3Для этого и существует испытательный срок для сотрудников.
Как бы не совсем. Испытательный срок, это аварийный стоп-кран, если найм совсем уж сработал плохо, а не просто опция для размена людей, типа не подошёл - на вылет. В нормальной работе как раз найм должен отработать корректно, чтобы не пришлось пользоваться стоп-краном, пусть даже такой найм и займёт больше времени.
markmariner
30.11.2023 13:11Почему?
dimykus
30.11.2023 13:11+2Как минимум найм может быть сопряжен с финансовыми затратами от выплат рекрутинговому агенству и до затрат на релокацию нового сотрудника
PuerteMuerte
30.11.2023 13:11+1Потому что увольнение на испытательном сроке, это всегда потери, и временнЫе, и материальные. И для компании, и для работника. И на них идут лишь потому, чтобы не понести ещё большие потери в будущем.
markmariner
30.11.2023 13:11Так пока человека не взяли потери тоже есть: работа, которую мог бы делать кто-то не делается вообще! Это тоже временные и материальные потери. Как доказать, что потери от испытательного срока в общем случае больше, чем потери от того, что работа не выполняется, а специалисты тратят время на собеседования, а не на свою работу?
PuerteMuerte
30.11.2023 13:11Как доказать, что потери от испытательного срока в общем случае больше
Потери при непройденном испытательном сроке подразумевают, что работа не выполняется должным образом и в течении испытательного срока, а специалисты тратят время на онбординг, на обучение человека, который не останется в команде, на разбор и исправление его некачественного кода. И это хорошо, если его ошибки не привели к более дорогим проблемам. Т.е. непройденный испытательный срок подразумевает, что вы сначала потратите время на поиск кандидата, потом на его, собственно, испытательный срок, а потом снова начнёте поиск кандидата по-новой.
И это же время будет потеряно и для самого кандидата. Т.е. в минусе окажутся все.
Kergan88
30.11.2023 13:11+2Статистических данных и исследований на эту тему я не видел, но опыт и здравый смысл подсказывает мне, что скорее всего тут нет корреляции.
Да нет, здравый смысл тут подсказывает что корреляция должна быть. Человек задрочивший литкод будет буквально _с любыми_ задачами справляться значимо лучше. Не только в контексте программирования.
На собеседовании можно отсеить совсем неопытных, хитрецов, жуликов и т.д. (если они, конечно, не прокачали навыки пускать пыль в глаза и проходить собеседования).
Ну вот за этим такие задачки там и задают. Не можешь развернуть бинарное дерево - жулик, иди гуляй.
большую часть навыков и опыта для которой не проверяют на собеседованиях, а что-то вообще невозможно проверить и понять за час времени вне реальной рабочей атмосферы и задач, даже задавая правильные вопросы, а не задалбывая кандидата специальной олимпиадой по "программированию".
Верно. Именно за тем человечество и придумал овсякие экзамены, тесты и т.п. - т.к. требуемый параметр измерить невозможно измеряются те, котоыре с ним скоррелированы.
Это примерно так же как не брать человека который, например, пришел к вам на собеседование бухим. Следует ли из того, что он пришел бухим то, что он плохой специалист? Нет. Но _скорее всего_ он таковым окажется.
markmariner
30.11.2023 13:11Почему бы не проверять тогда умение ставить диагнозы и лечение по анамнезу? "Задрочить" это тоже можно, появляется понимание причинно-следственной связи, алгоритм действий прорабатываете.
Тесты же и экзамены проверяют или то, что нужно на работе, или то, что человек учил, а не способность подготовиться к тесту.
Но, если даже и проверять способность подготовиться, то нужно давать список вопросов, а не как на собеседованиях "я поспрашиваю тебя об алгоритмах то, что мне захочется, но ты должен знать всё". Что именно всё?
Kergan88
30.11.2023 13:11+2Почему бы не проверять тогда умение ставить диагнозы и лечение по анамнезу?
Так у медиков проверяют. На экзаменах, буквально. Медиков вообще так по базе "дрочат", что программистам на собеседованиях и не снилось. То же самое можно сказать про огромное количество профессий, к слову.
Тесты же и экзамены проверяют или то, что нужно на работе, или то, что человек учил, а не способность подготовиться к тесту.
Нет, тесты проверяют некоторые параметры, которые _скоррелированы_ с тем, что нужно на работе. В этом смысл тестов per se, как я выше и указал.
Но, если даже и проверять способность подготовиться
А зачем? Ну т.е. да, действительно, способность подготовиться - это тоже полезный навык, но я даже не слышал такого, чтобы кто-то где-то действительно при трудоустройстве такое проверял. А вы слышали?
Что именно всё?
Так не надо знать все, надо уметь писать код на уровне школьника, который не прогуливал уроки информатики.
Если вы умеете - вы решите все эти "алгоритмические задачки" без каких-либо проблем. И готовиться не потребуется ни к чему, ну если не считать подготовкой изучение _базовых_ для данной профессии навыков. На уровне того самого школьника.
Вообще, вы не совсем понимаете, почему в принципе современные собеседования такие, какие есть.
hint: потому что профессиональная культура и, как следствие, уровень кандидатов, в какой-то момент опустились до уровня дна.
20+ лет назад, когда от джунов требовали знаний и навыков существенно более серьезных, чем сейчас есть у иных сеньоров, собеседования были совсем другие, ни кто там физбузы писать не просил. Это было бы просто смешно. Задавать такие вопросы специалисту? Нонсенс! Оскорбительно.
А теперь вот, пжалуйте - просят, и, более того, огромное количество кандидатов на это не способно (потому и просят) и потом жалуется на то, что им сложные вопросы на собеседованиях задают.
santa324
30.11.2023 13:11Крупные кампании стараются внести объективность в найм, а не отдавать это на откуп местным руководителям. Стандартизованная система найма позволяет переводить людей между командами, а не увольнять их вместе с руководителем, который набирал под себя.
Это одна из причин, как мне кажется.
iroln
30.11.2023 13:11+3Мне кажется, то, что вы описали: "стандартизованная система найма" - это "работает" только в умах тех, кто придумывает такие системы и в их отчётах и сопроводительных записках.
Люди - это не унифицированные роботы, каждый человек индивидуален, со своим багажом опыта, навыками, чертами характера, сильными и слабыми сторонами. Нельзя просто разработать "стандарт найма унифицированных людей" и нанимать на все случаи жизни с одинаковой эффективностью, прогоняя всех кандидатов по занимательным задачам в полном отрыве от реальности, предметной области и рабочих проблем.
И в то же время, люди обладают интеллектом и умением обучаться, подстраиваться и перестраиваться если нужно. Не нужно упрощать людей и обесценивать их способности, отталкиваясь только от того, смог человек решить задачу с литкода за 30 минут в условиях стресса или не смог. Так что наняв однажды хорошего инженера/разработчика не надо переживать, что он сможет
крутить только одну гайкуработать только на одном конкретном проекте только с одним руководителем, а на другом вдруг резко сломается как искусственная нейросетка.
И вот вопрос, как же выматывающие "стандартные" собеседования с элементами бессмысленного и беспощадного олимпиадного программирования помогают находить хороших инженеров с правильным мышлением, которые смогут работать на разных проектах, решать сложные задачи, прокачивать свои навыки и расширять кругозор? Что тестируют такие собеседования? Умение решать задачки с литкода (которые надо решать несколько месяцев, чтобы достичь успеха, как в книжках написано)?
Это попытка упростить то, что не упрощается. Нет никакой серебряной пули. Компании нужно готовиться к собеседованиям и проводить их разумно, а не по чьей-то глупой методичке.
germn
30.11.2023 13:11>и как из-за этого всё будет весело работать у клиента
И... как? Вы производительность решения "с квадратами на ровном месте" замеряли? Или "интуитивно" решили, что оно плохое? Само по себе это ещё не значит, что что-то будет работать недопустимо медленно с точки зрения продукта. А если для нас избавление от излишней сложности — самоцель, так можно дойти и до полного отказа от чужих библиотек и фреймворков в ущерб скорости и стоимости разработки.
Dolios
30.11.2023 13:11+1Замеряли. Для этого существует тестирование. Ну и, к сожалению, иногда квадраты или что-то похуже обнаруживались после жалоб клиентов, а не на ревью и после переписывания проблемных кусков с нормальной сложностью, всё начинало летать.
Еще до замеров человек, умеющий в алгоритмы и оценку сложности способен определить проблемные места в коде. Конечно, для тех, что "высшее образование не нужно, алгоритмы не нужны, я вон фигачу и всё нормально", это магия, я понимаю.
А если для нас избавление от излишней сложности — самоцель
germn
30.11.2023 13:11-1Еще до замеров человек, умеющий в алгоритмы и оценку сложности способен определить проблемные места в коде.
И чего, по коду всех используемых фреймворков и библиотек тоже пробегаетесь, чтоб определить "проблемные места"?
Конечно, для тех, что "высшее образование не нужно, алгоритмы не нужны, я вон фигачу и всё нормально", это магия, я понимаю
Уметь определять производительность без замеров — действительно магия. А, может, просто бездоказательный снобизм.
PrinceKorwin
30.11.2023 13:11по коду всех используемых фреймворков и библиотек тоже пробегаетесь
Вы будете удивлены, но да! И даже, бывает, в исходники компилятора заглядываем. А некоторые даже под капот CPU залезают:
https://habr.com/ru/articles/778026/
PrinceKorwin
30.11.2023 13:11Уметь определять производительность без замеров — действительно магия
Даже немного завидую вам. Живёте в мире с магией. Эх, мечта.
Я читаю код всех библиотек, что использую. И мой текущий проект держит 200к запросов в сек. При этом всё это использует всего 7Мб памяти. И не подвисает пердически из-за работы GC.
panzerfaust
30.11.2023 13:11+5А потом на код ревью приходится объяснять человеку, что он понаписал
квадратов на ровном месте и как из-за этого всё будет весело работать у
клиента.Ну объясните один раз. В чем проблема-то? На второй раз атата сделайте. На третий раз - забракуйте испытательный срок. Обычный процесс обучения. И вас так учили, даже если сейчас кажется, что уже родились сеньором-помидором.
Я в этом году джуна менторил. В первых пулл-реквестах было по 20-30 мажорных замечаний и по неоптимальностям и по стайлу, а потом вышли на 2-3 минорных максимум. Я прям сильно сомневаюсь, что у литкод-маньяка результат был бы другой.
Samedi_Da_Kapa
30.11.2023 13:11+2В смысле, испытательный срок? Вы предполагаете, что так делают только те, кто пришел в команду?
Я такие вещи видел у опытных, умудренных сеньоров, которые сидели в команде годами. Они застали еще те времена, когда клиентов было 5, а весь монолит запускался на бесплатном дино на хероку. Поэтому проблем по производительности не было. А сейчас смотришь и грустишь.panzerfaust
30.11.2023 13:11+1В смысле, испытательный срок?
Ну мы ж про собесы и найм говорим, исходя из контекста статьи.
Есть заблуждение, что мол вот мы сейчас обмажемся десятью этапами собеса с дрочкой литкода - и к нам придут только лучшие из лучших. Я б поверил в этот булшит, если б не был плотно связан с наймом уже 5 лет. На практике вы хоть колесом ходите - все равно к вам придут люди с разными скиллами и особенностями. И с этим надо уметь работать.
Dolios
30.11.2023 13:11+1Есть заблуждение, что мол вот мы сейчас обмажемся десятью этапами собеса с дрочкой литкода - и к нам придут только лучшие из лучших.
И вы эти заблуждения приписываете всем оппонентам? Есть также заблужддение, что если человек написал в резюме, что он умеет программировать, то он и правда это умеет. У меня на собеседованиях часто всё заканчивается на задаче: распечатайте в консоль словарь, в котором ключи строки, а значения числа. Часть кандидатов не могут и этого. Вы можете говорить что угодно, но никогда не убедите меня, что человек с 5+ годами опыта на самом деле отличный программист и всё это умеет, просто у него стресс.
panzerfaust
30.11.2023 13:11+1И вы эти заблуждения приписываете всем оппонентам?
...
никогда не убедите меня, что человек с 5+ годами опыта на самом деле отличный программист и всё это умеет, просто у него стресс
Ну если вам можно вешать ярлыки "не отличных программистов" на совершенно незнакомых людей, то и мне можно приписывать заблуждения кому угодно. Все честно, вроде.
Dolios
30.11.2023 13:11Я не навешиваю ярлыки, я оцениваю квалификацию. Если программист не может написать цикл без гугла, то оне не плохой программист, он вообще не программист. И проверить это очень просто - попросить написать этот самый цикл. А вы занимаетесь демагогией.
Jianke
30.11.2023 13:11+1Сейчас среди джунов встречаются умники, которые вместо гугла используют chatGPT.
Homyakin
30.11.2023 13:11+3Я не могу без гугла или без IDE. В питоне вот можно просто print(dict), в Java, уже сложнее, надо в цикле пробежаться по мапе. Сигнатуру for я знаю. Какой метод у Map? getEntries()? entries()? И вот я открыл IDE, оказалось, что метод называется entrySet(). Должен ли я это знать наизусть?
Кому станет легче жить, если я начну учить наизусть у какого класса какие методы? Люди специально придумали поисковики, подсказки в IDE, чтобы не держать эти знания в своей голове. Если мне приходит задача одного и того же типа раз в год, мне лучше знать как найти информацию о том, как её сделать, чем целый год держать бесполезные знания об этом у себя в голове.
И то что я некоторые нюансы языков или алгоритмы не знаю наизусть, не означает, что я не могу закрывать потребности бизнеса в срок.
Dolios
30.11.2023 13:11+1Должен ли я это знать наизусть?
Для меня очень странно, когда человек заявляет, что у него 5+ лет опыта коммерческой разработки на Java, но как проитерироваться по словарю, он не помнит. Вы же каждый день это делаете, речь же не о каких-то редко используемых коллекциях..
Но если вы скажете, что вы знаете что такой метод есть, но в стрессе его забыли, никакой проблемы не будет, можете выдумать сигнатуру, либо вам её скажет интервьювер.
b237
30.11.2023 13:11System.out.println() вроде принимает Object, да и у стандартных реализаций Map человечески переопределен toString(), так что тут особой разницы между
жабой игадюкойJava и Python нет
JBird
30.11.2023 13:11И то что я некоторые нюансы языков или алгоритмы не знаю наизусть, не означает, что я не могу закрывать потребности бизнеса в срок.
Когда кандидатов на одно место порядка 40, то это уже не важно - могут хоть ламбаду заставить танцевать и стишок на табуретке прочитать (привет, поиск работы на .NET в Германии в 2023 без немецкого).
iroln
30.11.2023 13:11+2И вы эти заблуждения приписываете всем оппонентам?
Извините, что вмешиваюсь, но думаю, что тут не приписывают "всем оппонентам". Но когда ты видешь в индустрии повальную эпидемию таких собеседований ("обмажемся десятью этапами собеса с дрочкой литкода"), то невольно начинаешь использовать обобщения "все", потому что чисто статистически ты скорее всего попадёшь именно на такое собеседование в компанию, где на самом деле пишут очередную пачку микросервисов с REST/gRPC, а задачи и алгоритмы с литкода не встречаются и никогда не встречались в их коде.
Никто вроде не спорит с тем, что на собеседовании можно и нужно проверять навыки программирования на работу программистом, но крайности - это почти всегда плохо. Когда в крайности впадают умные люди и целая индустрия - это вдвойне плохо, потому что получается психбольница в руках пациентов, и от этого помешательства страдают все участники.
PrinceKorwin
30.11.2023 13:11+6Они застали еще те времена, когда клиентов было 5, а весь монолит запускался на бесплатном дино на хероку.
И, вполне возможно, они правы. Преждевременная оптимизация - зло.
Возможно, что если бы они упаковывались в правильный и быстрый код, то и продукта бы не было, и клиентов, а может и самой компании. Как знать.
Samedi_Da_Kapa
30.11.2023 13:11Я скорее всего недостаточно точно выразил свою мысль. Приведя в пример ребят я не хотел сказать, что такой подход в корне неверен - не следить за оптимизациями.
Я хотел показать то, что те вещи, которые когда-то были нормальными - условный квадрат в обработке массива - сейчас могут быть не совсем хороши. Например потому что раньше массив был жестко ограничен сверху по количеству элементов, а потом изменились требования и входной массив стал неограниченным. Производительность упала. Это грустно - да. Это проблема - да. Стоит ли из-за этого кого-то выгонять из команды - нет.
Есть много причин для того, чтобы писать неоптимальный код и недостаток знаний - далеко не единственная.PrinceKorwin
30.11.2023 13:11+1а потом изменились требования и входной массив стал неограниченным. Производительность упала. Это грустно - да. Это проблема - да
Почему? Требования изменились. Код тоже нужно поменять. Это нормально. Почему вы грустите?
Если бы всегда, когда требования меняются не нужно было бы менять код - программисты стали бы не нужны. Зачем нам это? :) так что живём дальше и радуемся, пока можем :)
markmariner
30.11.2023 13:11+1Нет необходимости знать наизусть хоть один алгоритм, чтобы понимать что цикл в цикле -- это плохо. Объяснить это можно и пятикласснику, которому до теории алгоритмов и матанализа как до луны.
Если встретился нестабильный алгоритм сортировки на практике, ну ок, можно открыть справочник и поглядеть, какие ещё есть. А на самом деле просто погуглить, какой ещё в какой библиотеке есть. А сам факт того, что алгоритмов сортировки может быть несколько тоже в школе проходят.Dolios
30.11.2023 13:11+6Цикл в цикле это не всегда плохо.
Цикл в цикле даже не всегда увеличивает асимптотическую сложность.
Квадрат можно написать даже с 1 циклом без вложенного, если, например, на каждом шаге цикла добавлять что-то к началу массива вполне себе библиотечной функцией.
И вот чтобы это понимать, нужно владеть теорией.
Алгоритмы не нужно учить наизусть, это не стихи. Чтобы понимать, что сортировка может быть нестабильной и что это не ошибка также нужно понимать, как эта самая сортировка работает и чем один алгоритм отличается от другого. Иначе это всё превращается в набор магических догм, которым тупо следуют, не задумываясь. Вот прямо как у вас с циклами получилось.
markmariner
30.11.2023 13:11+3Вот именно это и происходит на собеседованиях с алгоритмами: ты говоришь что-то общими словами, а собеседующий, которому очень хочется показать, что он правее всех правых вместо уточняющих вопросов по одному предложению делает вывод о вашей подготовке, точнее о профнепригодности.
В этом и проблема таких собеседований.
Мой тезис остался таким же: да, вы правы в своих уточняющих пунктах, но чтобы всё это объяснить и перечислить опасные с со стороны производительности места, чтобы сверяться с ними в команде по мере разработки достаточно вечера. А для пятиклассника хватит первого тезиса про циклы, и будет круто, когда он разберётся и скажет: "Смотри, оказалось ты был не прав, говоря, про цикл в цикле".Dolios
30.11.2023 13:11+1а собеседующий, которому очень хочется показать
Вы сами интервью проводите? Мне ничего не хочется показать, мне хочется найти вменяемого коллегу в команду. Это какой-то детский сад считать, что препод или интервьювер вас непременно пытается завалить. Это я вам как бывший препод и нынешний интервьювер говорю. Конечно, упоротые личности с комплексами есть, но их отнюдь не большинство, не надо по ним всех судить. Знали бы вы сколько раз я видел удивленные глаза человека, который получал оффер после того, как в конце собеседования говорил: "наверное, я завалил собес, плохо отвечал"...
А если речь о фаангах, где несколько раундов интервью, такой упоротый быстро получит по шапке, если он постоянно будет давать отказ в то время как другие будут рекомендовать к найму.
markmariner
30.11.2023 13:11+1Ваш предыдущий комментарий написан в пассивно-агрессивном тоне, я именно поэтому и посчитал, что вы хотите всеми силами доказать, что правы, заодно, невзначай, унизив собеседника, мол, он там просто заучил магические догмы и всё.
В текущем комментарии вы опять занимаетесь обобщением, говоря, что я, видите ли, считаю, что все преподы и интервьюверы хотят меня завалить. Хотя я говорил только о примере вашего неконструктивного общения выше, ну и, на основе его, высказывал предположения о том, зачем другим собеседующим, алгоритмическая сессия.
Ну и, наконец, как бывший препод и нынешний интервьювер, вы можете хоть на секунду представить, что общаетесь с человеком, который и обучением занимался, и получал самые сложные задачи в потоке в университете на алгоритмическом курсе потому, что "так ты обычные за 10 минут решишь и думать даже не будешь, сиди, развивайся", и который уже 6 лет собеседует людей в свою и смежные команды?
Только вот это не доказательство ничего, это переход на личности. То, что и вы, и я проводим много интервью, ничего не говорит об их качестве. И даже если прошедшие интервью люди могут работать и их редко увольняют тоже ничего об качестве не говорит, может быть, можно было вообще не проводить никакого интервью, и результат был бы тот же.
Dolios
30.11.2023 13:11Нет необходимости знать наизусть хоть один алгоритм, чтобы понимать что цикл в цикле -- это плохо. Объяснить это можно и пятикласснику, которому до теории алгоритмов и матанализа как до луны.
Это ваш вот этот комментарий так написан. А мой написан уставшим тоном.
wataru
30.11.2023 13:11+1а собеседующий, которому очень хочется показать, что он правее всех правых вместо уточняющих вопросов по одному предложению делает вывод о вашей подготовке,
Точно таким же воспаленным самоутверждением могут страдать и другие интервьювью - от разговоров по душам о прошлых проектов, до просмотра гитхаба кандидата. Это не врожденное свойство алгоритмических интервью. Если где-то интервьювер - мудак, то это проблема человека, а не алгоритмических задачек.
Dominux
30.11.2023 13:11+3Алгоритмы не нужны, да... А потом на код ревью приходится объяснять человеку, что он понаписал квадратов на ровном месте и как из-за этого всё будет весело работать у клиента.
Данный аргумент - по сути, единственный адекватный, который приводит защитники алгоритмов. С ним, несомненно, можно согласиться. Да вот только на 146% алгоритмических секций ух слишком упарываются в тонкости, скорость исполнения куска кода и минимизацию ресурсов. И тут понятия, такие как читаемость кода, разделение кода на идиоматические части в виде функций/классов и создание поддерживаемого/масштабируемого кода пролетают - они уменьшают оптимальность его выполнения и не годятся для алгоритмов. В итоге мы имеем олимпиадников, которые нанимаются, спокойно пройдя алгосы и мб теорию, и пишут абсолютно ужасные партянки.
Ну и оптимизация приложений - это не только написание функции, это оптимизация запросов в бд, корректное масштабирование сервисов и уменьшение нагрузки на сеть, а сортировка, которая отработает на 1 наносекунду быстрее, чем другая, по факту ничего не улучшит
Dolios
30.11.2023 13:11+2И тут понятия, такие как читаемость кода, разделение кода на идиоматические части в виде функций/классов и создание поддерживаемого/масштабируемого кода пролетают
Не пролетают, для этогно есть секция ОО дизайна.
Ну и оптимизация приложений - это не только написание функции, это оптимизация запросов в бд, корректное масштабирование сервисов и уменьшение нагрузки на сеть
А об этом вы поговорите на секции системного дизайна.
Это если мы говорим про фаанги. Если речь про обычную компанию, всё это легко в равках одного собеса будет.
Да вот только на 146% алгоритмических секций ух слишком упарываются в тонкости, скорость исполнения куска кода и минимизацию ресурсов.
Алгоритмическая секция нужна прежде всего для того, чтобы понять, может ли человек решить простую задачу, знает ли он о существовании граничных условий, уточняет ли он требования или сразу бежит что-то писать, не разбираясь, имеет ли он привычку проверять то, что он написал и, в конце концов, способен ли он хотя бы простой код написать. Знание алгоритмов там вторично, на самом деле.
Dominux
30.11.2023 13:11Знание алгоритмов там вторично, на самом деле
Да вот как бы нет. К сожалению всё скатывается именно в это. А на остальное смотрят разве что фаанги и Яндекс, остальные тупо срисовывают с них эти алго секции
9982th
30.11.2023 13:11+18Coding Challenges – отличный ресурс с задачами, подходящими под эти требования.
Открываем список тем: "Write Your Own Compression Tool", "Write Your Own Sort Tool", "Write Your Own Calculator". Ближе к концу: "Write Your Own Lisp Interpreter".
То есть просить на собеседовании написать условную сортировку вставками - это плохо и с этим пора кончать, а законченную утилиту командной строки с поддержкой пайпов, внутри которой требуется реализовать несколько разных алгоритмов сортировки, - хорошо и правильно?
Oncenweek
30.11.2023 13:11+4Ну я так понимаю, что в Coding Challenges никто не запрещает использовать алгоритмы стандартной библиотеки, а не писать самому. И как следствие фокус смещается с запоминания алгоритмов на навык написания законченных мини-программ
9982th
30.11.2023 13:11Step 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.Сколько из них есть в стандартной библиотеке того же Питона?
Oncenweek
30.11.2023 13:11+1Сколько из них есть в стандартной библиотеке того же Питона?
Ну даже если и нет, я так понимаю никто не мешает добавить либу где они есть, хоть в сишечку, хоть в петухон. Даже наверное полезнее будет, научиться юзать библиотеки, чем писать все эти сортировки вручную
Hivemaster
30.11.2023 13:11+1Quicksort и heapsort в стандартной библиотеке есть. Остальное доступно в подключаемой библиотеке, если по какой-то причуде вдруг понадобиться в реальных задачах, что очень вряд ли.
lemind
30.11.2023 13:11-1Да это продажный прикол чтобы потом сказать "у нас тут работают лучшие ребята, все шарят в алгоритмах"
blind_oracle
30.11.2023 13:11+1Зависит от конторы.
У нас, например, каждый второй PhD или ещё какой криптограф, но алгоритмами на собеседованиях мучают очень осторожно и по делу: какой-нибудь граф обойти без циклов, придумать простейший алгоритм по которому можно в чате играть в загадки и так далее.
Ну и системный дизайн, куда без него, но эта тема очень широкая и там такого задрачивания как с алгоритмами, по-моему, нет.
zynaps76
30.11.2023 13:11+8Угу, HR-ам того же Яндекса последние года три постоянно обясняю, что на отдельную подготовку к их алгоритмической секции банально нет времени, поэтому, увы - на собес не пойду. Да и в реальной работе они потом [подавляюще] не встречаются. И вообще тогда непонятно зачем все это нужно.
зы Вот Just 4 Fun этот литкод погрызть под настроение - это можно, там занятные задачки попадаются. )
blind_oracle
30.11.2023 13:11+1Литкод - зло (хотя сам я его люблю иногда порешать).
Но! Прогонять соискателей по базовым вещам вроде какие когда нужно структуры данных использовать, про сложность алгоритмов базово спросить - это, как по мне, маст хэв.
А то были у меня товарищи, которые на вопрос "какую структуру данных будешь использовать для буфера?" отвечали хеш-таблица (или мап, или словарь - в зависимости от любимого языка кандидата) или ещё что похуже.
komkom
30.11.2023 13:11+1сейчас ищу работу, тоже насмотрелся не оч разумных тестов по "хард-скиллз", думаю запилить теперь тут статью в духе "идеальное собеседование", то каким его вижу я... думбаю надо запилить... спб автору, точно запилю!
vital_pavlenko
30.11.2023 13:11-4Тоже давно не спрашиваю алгоритмы на собеседованиях. В своей компании пытался доказать, что они не нужны, но пока не все готовы к таким переменам.
Единственный аргумент, который я слышал в пользу алгоритмов – это проверка интеллекта разработчика. Типа если он лутает алгосы, то и всякие реакты легко освоит. UPD: Но я с этим не согласен если что)
Keeper10
30.11.2023 13:11+15Типа если он лутает алгосы
А если ещё и русским языком владеет -- так вообще красавчик!
starik-2005
30.11.2023 13:11+1А вот алгоритмы - это что? Последовательность действий, которые нужно совершить, чтобы получить нужный результат. И да, каждую задачу часто можно решить куда более, чем одним алгоритмом. И у каждого алгоритма есть оценка времени выполнения и потребления памяти. И неплохо было бы, чтобы все программы использовали бы поменьше памяти и работали бы побыстрее, но да, если они в принципе работают хоть как-то, то это лучше, чем если они не работают никак вообще.
И да, я давно уже программист. И, черт возьми(!), я каждый божЫй день вынужден придумывать, как решить ту или иную задачу. И каждый раз я использую базовые алгоритмы обхода коллекций, деревьев, кеширую выборки в структурах с низким временем доступа, создаю индексы для одних структур или полагаюсь на быстрый поиск "искоробки" для других (ключ:значение).
Ну, например, мне нужно было собрать некие данные - свойства объектов - вместе, позволить пользователю указать, какие свойства собирать и в каком виде объединяя свойства (своство1 - свойство2 - свойство Н) или собирая из них иерархию свойств. И я плохо представляю, как это сделать, не владея базовыми алгоритмами.
И да, было как-то развлечение, когда ФМС еще предоставляла файло с сотней миллионов недействительных паспортов. И пока все мучились, засовывая это г-но в свои СУБД, я просто построил битовую матрицу, которая формировалась за время скачивания архива с интернета и имела О(1) по эффективности вставки/поиска. Да, чертовы алгоритмы позволили не тратить часы времени на перекладывание CSV в базы данных с последующими селектами. Полная матрица занимала бы 1,25 Гигабайта, что для современных приложений ниачом, но т.к. половина серий еще не выдавались, то реально все занимало 600 метров и крутилось на какой-то репке пиай...
Kergan88
30.11.2023 13:11+5Для ясности: я говорю о задачах на алгоритмы в духе LeetCode. Большая часть подобных собеседований, на которых мне приходилось бывать, включала задачи среднего и выше уровня с этого ресурса.
Даже средние не дают почти никогда. Обычно дают задачи более легкие, чем легкий уровень литкода. Их смысл - отсеять людей, которые заведомо не подходят, т.к. не умеют программировать.
Например, попробуйте сосредоточиться на сигналах такого рода:
На проверку подобных навыков требуются _месяцы_. У кого-то есть возможность тратить несколько месяцев фуллтайм работы на одно интервью? И какой кандидат вообще согласится на такое?
mafia8
30.11.2023 13:11+9(AlphaDev предложил алгоритм, который производит сортировку на 70% быстрее, чем существующие, для библиотеки libcc++)
Но есть нюанс: 70% - для последовательностей из пяти элементов. А в целом, новые алгоритмы сортировки AlphaDev на C++ на 1.7% эффективнее предыдущих методов при сортировке длинных последовательностей чисел.
edogs
30.11.2023 13:11+1Как и в случае с дипломом - тут дело не только и не столько в алгоритмах.
Компания должна оценить кандидата, за интервью этого не особо сделаешь.
Компании нужен кандидат, который достаточно усидчив, а не так что месяц над задачей посидел, перегорел и подал заявление на больничный на полгода. Который умеет креативно решать на практике разнообразные задачи, это само по себе ценный скилл, умеет в одной области - проявит в другой. Который достаточно хочет работать в этой области, что бы преодолевать препятствия.
И так далее и тому подобное. Так же как и с софт-скиллами, нужен человек способный завершить этот сложный квест по подготовке к интервью и если он настолько способный что справился, то допилить его под задачи нужные компании будет не проблемой.
SquareRootOfZero
30.11.2023 13:11+2Вроде, задача с литкода на слияние списков выглядит самой простой из трёх?
Sixshaman
30.11.2023 13:11По собственному опыту, многие "средние" задачки с литкода сложнее некоторых "трудных". На некоторые из средних у меня уходило по месяцу рассуждений и попыток решить, а какие-то трудные решал за пару часов.
Rorg
30.11.2023 13:11-2Рискну быть заминусованным, но...
Если к вам прибежал менеджер с криком "Караул, все пропало, нужно срочно реализовать нашу Супер-Пупер-Новую-Функцию. У вас 30 минут, а то все уволю нафиг." Вы будете пытаться оптимизировать алгоритм до О(1) (ну в идеале) или "фиг с ним, пока и О(n^2) (ну да, другая крайность) сойдет, потом в спокойной обстановке исправлю". Просто хотелось бы услышать мнения.
PuerteMuerte
30.11.2023 13:11+2Если ко мне прибежал менеджер с криком "Караул, все пропало, нужно срочно реализовать нашу Супер-Пупер-Новую-Функцию. У вас 30 минут, а то все уволю нафиг", я пожму плечами и предложу ему написать её самому, а потом спрошу у директора, зачам наняли этого психа. В общем, эта задача лежит не в технической плоскости, а в социальной :)
Alexsey
30.11.2023 13:11+1Если перефразировать вопрос, то суть от этого не сильно поменяется. Замените "уволю нафиг" на "нам всем влетит потому что компания понесет убытки больше чем годовая зарплата всего нашего отдела" и вот вы уже получили ситуацию, которая реальна уже в гораздо большем количестве компаний. У меня лично такие пару раз были в карьере, там реально было не до оптимизаций, время до полной ж- исчислялось парой часов за которые надо понять что не так и как это быстро закостылять.
Правда однажды, благодаря не совсем компетентному начальству, сделанный костыль с грохотом рухнул через месяц не смотря на то что постоянно подсвечивалось что нужно уделить время тому чтобы его заменить на что-то нормальное. Вот тут уж реально вопрос из социальной плоскости.
PuerteMuerte
30.11.2023 13:11Если перефразировать вопрос, то суть от этого не сильно поменяется.
В реальности такие вещи бывают, конечно, но это не про супер-новые-функции, а про хотфиксы. Да, если выкатили что-то, из-за чего у клиентов что-то важное упало, или там данные покоцались на продакшене, то вполне естественно сесть и быстро исправлять свои же косяки. Ну, наверное если там мог быть где-то какой-то алгоритм со сложностью О чего-то там, но написать О чего-тот там + 1 будет быстрее, то я бы выбрал второй. Но для всего этого слишком уж редкое совпадение звёзд должно быть, хотфиксы всё-таки в основном состоят из поиска "что сделали не так", а не из добавления новой заковыристой логики.
iig
30.11.2023 13:11+2У вас 30 минут, а то все уволю нафиг
А потом через пару недель: "ну чо там как по той задаче?"
В общем, эта задача лежит не в технической плоскости, а в социальной :)
Тоже в технической, только со стороны менеджмента. Менеджмент не умеет в планирование - программисты с алгоритмами тут не помогут.
gun_dose
30.11.2023 13:1110 лет занимаюсь веб-разработкой, ни разу не спрашивали алгоритмы на собеседовании.
alexander_kuznetsov
30.11.2023 13:11+3Сильно зависит от того, кого и куда собеседуют.
Для джуна/вчерашнего студента задачка с литкода - вполне норм, так как странно ожидать от него умения, например, правильно проводить инспекцию кода. Нет, уникумы попадаются, бывает, но это именно редчайшие исключения.
Для более опытных коллег - многое зависит от планируемого круга задач. У нас в проекте и квантизаторы изображений есть и графовые алгоритмы и много чего ещё. При этом в предыдущем проекте было обычное формошлёпство с пониманием небольшой нагрузки. А ещё раньше куча кешей и весьма нетривиальные хранимые процедуры на стороне базы. Проекты - они разные. И брать на первый людей без знания алгоритмики - ну, такое себе. А вот на предыдущий сильный алгоритмический скилл - явный перебор, равно как и на третий - там навыки профилирования и оптимизации именно SQL кода были важнее сортировки списков.
Но есть ещё один нюанс. От сеньора/лида ожидается, что при возникновении проблем с производительностью именно они пойдут и устранят проблему а, в идеале, не допустят её возникновения на этапе ревью. То есть опять получаем сценарий, когда на проекте алгоритмика может быть не нужна в 99% случаев, но именно лиду/сеньору придётся разгребать оставшийся 1% и, зачастую, разгребать в относительно сжатые сроки.
В общем, я бы не стал делать задачку на алгоритмику основополагающей, но, как один из важных факторов при принятии решений, она, как мне кажется, должна быть.
IvanSTV
30.11.2023 13:11-2буквально вчера мне поставщик софтины, в которой я обнаружил баг, впаривал, что мне надо добавить к каждой единице номенклатуре еще один дополнительный справочник настройками и заполнить его для 30000 единиц номенклатуры РУКАМИ (ибо табличного заполнения нет(!)), чтобы обойти ошибку, когда при включении функции проверки планового и фактического количества 10*1,56 устойчиво не равно 15,6.
Что-то мне подсказывает, что будь разработчики этой шняги хороши в алгоритмах, то вряд ли вообще такую странную архитектуру, когда просто проверяющая настройка и информативная блокирует функционал, допустили. И вообще в софтине таких избыточных настроек огромное количество. Люди вместо того, чтобы нормально отладить логику программы, добавляли новые сущности.
Потому скорей я не против того, чтобы гоняли по алгоритмам. В целом улучшает качество продукта для пользователя, а именно это и есть собственно общественная польза от работы ITшника любой масти.neyronon
30.11.2023 13:11Как бы не так. Предположим вам надо считать количество товаров по складам, которые разбросаны по всей стране. Можно просто проходить по массиву и суммировать элементы, а можно сделать дерево отрезков, которое может выдать ответ гораздо быстрее (якобы). Но тут легко забыть почему быстрее. Ничто не дается даром. Скорость обработки таких запросов мы увеличиваем за счет роста потребляемой алгоритмом памяти. Это раз. А два это то - что на алгоритмических секциях требуют достичь хорошую асимптотику. А она в большинстве случаев дает ухудшение производительности при малом количестве данных. Ведь необязательно у вас будет 1 миллион складов, когда два алгоритма можно сравнивать именно асимптотически.
Да и вы тут совсем не об алгоритмах пишите. Ваша проблема не связана напрямую с тем, знает ли программист алгоритмы или нет. Тут гораздо больше другого.
ALexhha
30.11.2023 13:11А причем тут знание алгоритмов ? Тут скорее проблемы с архитектурой приложения
ElKornacio
30.11.2023 13:11+20Хз, я и по сей день даю 1-2 задачки на алгоритмы во время собеса - причем задачки довольно простые. Я провёл около 400 собеседований за последние 8 лет, и корреляция очень сильная - кандидаты, которые их решают, почти всегда сильнее и лучше в прикладных задачах, чем те, кто их решить не может.
Я не могу дать человеку бизнес-задачу или попросить сделать небольшое веб-приложение - это не поместится ни в полчаса, ни в час, а тестовые вообще мало кто любит (да и смысла я в них особого не вижу).
Но удивительная закономерность такова - если человек на собесе смог смерджить два отсортированных массива в третий отсортированный - то обычно, когда после этого я прошу написать простенький React-компонент для асинхронной загрузки картинки - он справляется отлично.
А если чел два массива соединить не смог, и начал мне рассказывать "зачем эти алгоритмы, мы же веб-приложения делаем", то когда я говорю "окей, без проблем, давай напишем input, у которого при фокусе placeholder поднимается вверх над полем ввода", то я вижу какую-нибудь дичь с точки зрения качества кода - неадекватное управление state'ом, непонимание замыканий, и прочее.
Мой личный вывод - если чел потратил время на понимание того, как работает память и выполнение кода, то вероятно, он такое же время потратил на понимание как внутри устроен тот или иной фреймворк/библиотека/движок, и умеет качественно её использовать.
Если же чел топит за "зачем мне эта теория, мы тут формы шлепаем" - ну, скорее всего он и формы шлёпать будет довольно криво.
P.S. Я говорю про довольно простые алгоритмические задачи - никаких оптимизаций графов или каких-нибудь черно-красных деревьев, и прочего.
P.P.S. Да, даже простые алгоритмические задачки не решают 80% кандидатов. При том, что собеседую я в основном синьоров с 5+ годами опыта. До сих пор не укладывается в голове, как это возможно.
YegorP
30.11.2023 13:11+10Ну вот у меня 10+ лет опыта. И я недавно зарегался на leetcode. Выяснилось, что я:
Могу затупить на Easy. Сильно затупить. Долго.
Могу порвать 100% за чашкой кофе на Medium.
Могу решить Hard не зная типового алгоритма и прочитать о нём уже потом (топологическая сортировка).
Могу не справиться с Medium просидев с ним весь день.
И чо?) Это же ненадёжно для собеседования на такие роли, где программирование больше "законотворческое" (выстроить отношения между сущностями), нежели числодробильное.
Ок, наверняка между знающими алгоритмы и способными кодить есть корреляция. Но тогда пропадают люди, способные кодить и не знающие алгоритмов.
Rorg
30.11.2023 13:11+1
SpiderEkb
30.11.2023 13:11+5У меня 30+ лет опыта и на литкодовских задачах могу зависнуть просто потому что это абстрактная задача.
При этом реальные рабочие задачи, значительно большие по объему, вполне нормально решаю (ну как коллеги говорят и показывают результаты нагрузочного тестирования :-)
Mirn
30.11.2023 13:11может ElKornacio проверяет чтоб просто тестовые примеры проходило? и смотрит как он справляется с кодингом и отладкой а не проходит или нет?
по крайнее мерее я не вижу надобности на собесе доводить таск литкода до прохождения всех тестов. Зато литкодом можно проверить на навыки коммуникации и командной работы или попросить изменить сделанный алгоритм (бывает что у кандидата таск уже решён - а давать рандомный я не хочу т.к. там свыше 60% тотальный булшит аля шахматный конь скачет по num клавиатуре 4х3 без крайних двух что побокам нуля, подсчитайте какую унылую комбинаторику или непрактичную DP по модулю 100000007 - поэтому я всегда даю хорошие годные таски из своего списка, которые я знаю и решал и знаю что решить крайне легко например выровнять блок текста по ширине или на имплементацию простого стека например)
SpiderEkb
30.11.2023 13:11Я предпочту обозначить задачу из реальной практики и спросить как ее планируется решать. Не в коде, а план решения, основные моменты.
Но у нас своя специфика - очень специфичная платформа и очень специфичный стек.
Людей, которые просто смогут ответить на вопрос "о чем это вообще и что оно делает"
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На всю страну несколько сотен наберется.
Так что больше интересует "как у человека голова работает вообще". Применительно к тем задачам, которые тут придется решать.
gatoazul
30.11.2023 13:11Сразу JCL запахло - языком, на котором матерно ругаются программисты.
Очевидно, копирует файл, потом создает что-то (ссылку какую-то?) и вызывает некую стандартную процедуру.
SpiderEkb
30.11.2023 13:11Это язык системных команд (CL) на IBM i Используется как "средство общения" с системой в терминале, так и для написания небольших программ (он типизированный, компилируемый) для манипуляции с системными объектами.
Команда CPYF - копирует "PF-SRC - физический файл исходных текстов" (содержащий все исходники поставки) CPOSRC100 (в нашей нотации это поставка линейки CPO версия 100) из библиотеки ASRCPGM (опять в нашей нотации - библиотека где хранятся исходники поставок на юните PGM) в библиотеку ASRCD09.
Команда CRTBNDCL - компилирует программу-инсталлятор @CRTCPO(на том же CL - она генерируется автоматически на основе гредловых скриптов с описанием поставки) исходник которой лежит в том же CPOSRC100
Ну а третий просто запускает скомпилированный инсталлятор - устанавливает поставку в юнит D09.
PuerteMuerte
30.11.2023 13:11+1На всю страну несколько сотен наберется.
Та побольше, он же не только на мейнфреймах юзается, но и на куда более распространённых iSeries. Тем более что его в ряде контор используют не только разработчики, но и продвинутые пользователи.
SpiderEkb
30.11.2023 13:11Так мы и работаем на iSeries - IBM i. Это не мейнфреймы, middleware. Но не слышал чтобы у нас в стране их много было.
CL мало используется в разработке. Ну разве как вспомогательный, для коротеньких программ, работающих с системными объектами. Больше сопровождение использует.
Но каждый пользователь его так или иначе знает - это же средство общения с системой. Даже если не пишешь на нем программки, то все равно его команды используешь при работе в терминале.
PuerteMuerte
30.11.2023 13:11Но не слышал чтобы у нас в стране их много было.
Да в принципе много, на них до последних лет работали и Пенсионный фонд, и Федеральная служба занятости, и не один десяток банков.
SpiderEkb
30.11.2023 13:11Про ПФР слышал, но были слухи что ушли с нее (или их ушли). Про службу занятости не слышал. Кто-то говорил, что в РЖД что-то было, но старое, давно не обновлялось.
Из банков точно знаю что мы (альфа), росбанк и райф. Кто еще не в курсе.
Но CL - это в основном команды для работы с системой в терминале. Ну мы еще на нем пишем программы-инсталляторы для поставок (точнее, раньше писали руками, сейчас оно автоматом генерируется по гредловым скриптам). Сопровождение какие-то свои скрипты пишет на нем.
А так более 80% кода под эту систему на RPG пишется. Вся работа с БД и бизнес-логика. Ну и немного на С/С++ (все низкоуровневое)
sva89
30.11.2023 13:11Там сложность немного рандомная и завязана количество шагов/алгоритмов для решения; еще medium - это иногда easy с дополнительными условиями. На собеседованиях обычно адекватные задачи задают, пару раз было что решается довольно легко и просто, а на литкоде помечена как hard.
mikegordan
30.11.2023 13:11+3Алгоритмы это очень хорошо чтобы прям отсеять пару сотен или даже тысяч человек которые о компьютерах и программировании знают "я после курсов".
agoncharov
30.11.2023 13:11+2Когда обсуждают «алгоритмы на собеседованиях» часто ставят знак равенства между пониманием принципов работы стандартных алгоритмов и структур данных (с оценкам сложностей) и вот такими вот «олимпиадными» задачками на сообразительность. Но это фундаментальные разные вещи. Можно отлично разбираться в стандартных алгоритмах и быть в курсе таких продвинутых техник как динамическое программирование, но когда в конкретной (как правило очень искусственной) задаче тебе в ограниченное время предлагается догадаться до «трюка» с которым ты не сталкивался — тут в принципе мало какие знания помогут
Keeper10
30.11.2023 13:11Отбор кандидатов по характеристике "Удача". Вместо исполнения трюков на время можно бросать DnD-шные кубики. Будет примерно то же самое, только быстрее.
tfkfan
30.11.2023 13:11+2Может быть 1-2 простых алгоритмических задачи на собеседовании и уместны, но когда весь собес превращается в полуторачасовое разжевывание кишков языка, которые не имеют ничего общего с реальной работой, это бред. Яндекс например этим маразмом занимается. А отсеивать кандидатов можно и в автоматическом режиме, для этого есть различные опросники, тесты, с автоматической проверкой, рекомендательные и сопроводительные письма. Собеседующий человек в первую очередь должен смотреть на опыт, проекты и увлеченность потенциального работника, а не это вот все.
Mirn
30.11.2023 13:11+1как то в одной японской компании меня попросили перед собесом в течении недели сделать несколько easy medium задач ЛЮБЫХ, не меньше пяти штук, и на собесах мы обсуждали как их улучшить или почему то или иное было сделано именно так или как доработать до другого типа входных данных, прошло интересно но не наняли - я перенервничал на следующем поведенческом.
и это был единственный случай когда литкод вообще упоминали в собесах когда собеседовали меня.
CorwinH
30.11.2023 13:11+4Если вам на собеседовании дают алгоритмическую задачу, то помните, что:
Если собеседующий адекватный, то от вас не требуется обязательно решить задачу (написать работающий код). Достаточно продемонстрировать умение разбивать задачу на подзадачи, выбирать правильные структуры данных и оценивать сложность алгоритма. Можно, не решить задачу и получить за неё плюс, а можно выдать правильное (зазубренное) решение и получить за неё минус, не так ответив на дополнительные вопросы.
Если собеседующий неадекватный и вам отказали, не смотря на правильные рассуждения в процессе решения, то это только к лучшему. Зачем вам неадекватный начальник?
CorwinH
30.11.2023 13:11Для примера возьмём задачи и статьи. Я не знаю правильного решения (даже не уверен, что правильно понял условие, так как по ссылкам не ходил и примеры входа/выхода не видел), но попробую рассуждать логически.
Максимальная площадь.
Берём единицу, добавляем в очередь. Для первой единицы из очереди добавляем в очередь все соседние единицы. При этом считаем количество единиц (площадь) и заменяем единицы на двойки (помечаем обработанные).
Решение: проходим по массиву и для каждой единицы запускаем описанную выше рекурсивную функцию (считающую площадь связанной области). В отдельной переменной храним максимальный на текущий момент результат работы функции.Самая длинная подстрока.
Текущая подстрока - это "окно" (левый и правый конец). Пока строка содержит только уникальные символы, двигаем правый конец. Пока строка содержит дубли, двигаем левый конец.
Для подсчёта дублей используем словарь с количествами символов в подстроке (меняем при каждом сдвиге границы). В отдельной переменной храним количество дубликатов (меняем при изменении значения в словаре с 1 на 2 и с 2 на 1 в словаре).
В начале левый и правый конец указывают на первый элемент. Останавливаемся, когда правый конец дойдёт до конца строки.Слияние списков (считаю, что дан массив связанных списков)
Кладём все первые элементы в коллекцию. Достаточно хранить индексы списков в массиве, так как значение можем узнать за О(1), а можно хранить пары индекс-значение.
На каждом шаге выбираем минимальный первый элемент, удаляем его из соответствующего списка и добавляем в результирующий список.
Исходя из задачи, в качестве коллекции выбираем очередь с приоритетом. Библиотечной в моём языке я не знаю, но легко написать двоичную кучу (binary heap), в которой корнем будет индекс (в массиве списков) с минимальным значением (первым элементом). Для этого нужно два метода - "всплытие" и "погружение".
p.s. Я не решаю задачи на LeetCode и не уверен, что смог бы довести эти задачи до рабочего кода за 30 минут на собеседовании.
SpiderEkb
30.11.2023 13:11Самая длинная подстрока
Что пришло в голову сразу.
Берем таблицу символов. Изначально заполнена нулями.
Берем счетчик. Изначально 0.
Берем максимальное значение счетчика. Изначально 0.
Берем индекс начала максимальной подстроки. Изначально - начало строки
Берем индекс начала текущей подстроки
Идем по строке от первого символа к последнему. Берем очередной символ, смотри м таблице (символ - индекс). Если там 0, ставим туда 1, увеличиваем значение счетчика.
Если не 0 - обнуляем таблицу, если значение счетчика больше максимального, присваиваем максимальному значения значение счетчика и индексу максимальной подстроки индекс текущей подстроки.
Обнуляем счетчик, индекс начала текущей строки ставим на текущий символ.
Ну как-то так на пальцах.
Alexandroppolus
30.11.2023 13:11+2Там можно просто запоминать последнюю позицию для каждого символа. И если последняя сохраненная позиция очередного
str[i]оказалась правее начала текущего отрезка, сдвигаем оное начало на ту сохраненную позицию + 1.CorwinH
30.11.2023 13:11Отличная идея! Мне такая в голову не пришла. Правда, я потратил 15 минут на 3 задачи (5 на решение и 10 на формулирование/набор текста).
SpiderEkb
30.11.2023 13:11А вот мне кажется, что +1 не надо. Надо на позицию того символа, который оказался первым дублем. Но да - в целом так лучше - не надо каждый раз таблицу чистить.
Наверное, сам бы додумался, но уже "на второй итерации" - посмотреть на код и подумать "а нельзя ли тут на чем-то скроить еще"? Сходу в голову не пришло, конечно.
Alexandroppolus
30.11.2023 13:11+1А вот мне кажется, что +1 не надо. Надо на позицию того символа, который оказался первым дублем.
Почему? Вот был у нас текущий отрезок "abcd", и встретилась буква b. Теперь текущим отрезком должен стать "cdb", т.е. левый край поставился на (предыдущую позицию b) + 1
Rsa97
30.11.2023 13:11заменяем единицы на двойки
Матрица бинарная, только 0 и 1. Понадобится вторая матрица, чтобы отмечать просчитанные области.
speshuric
30.11.2023 13:11+1Максимальная площадь.
Там в оригинале квадрат, а не площадь. Maximal Square. Ну и собственно, задача в том, чтобы решить её за O(m*n). Большее time complexity не пройдёт тесты.
Авторам в личку кидал информацию об ошибке, они не исправили.
zergon321
30.11.2023 13:11+4А я не понимаю, а чего бы тогда просто не требовать ссылку на тот же самый LeetCode? Пускай в требованиях к вакансии пишут: "200 решённых задач сложности medium на LeetCode. Ссылка на профиль в резюме/сопроводительном письме"
PuerteMuerte
30.11.2023 13:11+4А я не понимаю, а чего бы тогда просто не требовать ссылку на тот же самый LeetCode?
Потому что в общем случае на собеседовании интересуют не ваши результаты на литкоде, а просто умение решить задачку, где надо включить мозги. Литкод тут просто инструмент, где всё готово для решения задачек.
CorwinH
30.11.2023 13:11Потому что не интересен сам факт решения. Интересен процесс решения (ваши рассуждения).
Кроме того, если будет спрос, то тут же появятся предложения типа "200 задач на литкоде за Х рублей".
wataru
30.11.2023 13:11Будут фирмы "делаем профиль на литкод под ключ". Каждый второй прошедший - будет вайтишник с крусов "с 0 до мидла за месяц".
Daddy_Cool
30.11.2023 13:11+4ИМХО мода на знание алгоритмов тянется из 50-60- - когда профессия математик-численник и программист было одним целым. Сейчас же... кажется программисту важно знать, что алгоритмы существуют, знать библиотеки где они реализованы или быть способным (редко) закодировать алгоритм описанный где-то.
Пример. Мне нужен был алгоритм сдвига узлов сетки - я нашел математическую статью где их было описано несколько штук, взял самый простой и запрограммировал. Всё. Зачем этот алгоритм знать программисту?
Мне нужно было решить уравнение Пуассона на CUDA, я дал статью с описанием алгоритмапрограммистуаспиранту, он закодировал даже не особо вникая. Задача решена.
(Я не программист, я научный работник если что).Jianke
30.11.2023 13:11+2С тех пор как исчезли чистые кодеры писавшие код по полученному алгоритму в виде блок-схемы, от программиста ожидается, что в случае необходимости он сможет создать алгоритм самостоятельно.
Daddy_Cool
30.11.2023 13:11+5Это странно. Простые алгоритмы и нужные алгоритмы - описаны и закодированы 100500 раз, сложные и нужные - это задача не программиста, а математика с соответствующим профильным матобразованием. А вот знание какую память как для чего использовать, как организовывать многопоточность, избегать всяких гонок и дедлоков, организовывать структуры данных, знать как работать с драйверами с железом, и т.п... кажется именно вот это и есть работа программиста. Но видимо я просто отстал от программисткой жизни.
Jianke
30.11.2023 13:11+1Я в IT с 90х, и за все эти годы ни разу не видел живьём математика, который рисует блок-схемы с алгоритмами для кодеров являющихся тупыми исполнителями его воли. Все виденные мной в IT математики - сами работали программистами и лично писали код, а не рисовали блок-схемы с алгоритмами для кодеров.
gatoazul
30.11.2023 13:11+3Видел я код, написанный математиками. Лучше бы не видел.
MiraclePtr
30.11.2023 13:11+1Кстати да. Самый адовый говнокод, который я когда-либо видел, был написан именно математиками.
kimisa
30.11.2023 13:11-1Вы путаете математиков и программистов. Математик по сути должен нарисовать алгоритм. А архитектура программы это другое.
shoorickus
30.11.2023 13:11+1На мой взгляд, такой подход вполне оправдан для топовых компаний, где количество откликов на вакансию значительно превышает количество вакантных мест (Google, Microsoft, другие).
Допустим, есть вакансия и откликов на неё было 1000 (реально, учитывая весь мир), отсеем неподходящие резюме/опыт/английский/soft skills, всё равно останется очень много кандидатов, кто точно сможет успешно справляться с рабочими задачами, будет лояльным и т. д. Я порядка цифр не знаю, но пусть, очень грубо, это будет каждый 20-й.
Каким образом из 50 кандидатов выбрать 5 для найма? Должен быть какой-то фильтр, на который можно будет сослаться, формируя отказ, не жребий бросать. Можно, конечно, устроить среди кандидатов соревнование по пятиборью, но это не очень связано с рабочими обязанностями, поэтому выбрали leetcode: задачи универсальны (не зависят от стека технологий) и долгое время остаются актуальными, как и computer science.
stan_volodarsky
30.11.2023 13:11Важно для разработчика правильно поставить задачу? Несомненно, да. В статье приводится пример: "Нужно определить наибольшую по размеру область, которая содержит в себе только единицы, и рассчитать ее площадь.". Ссылка на Литкоде ведёт к задаче "найти максимальный квадрат". Есть три подобные задачи: максимальный квадрат, максимальный прямоугольник, максимальная связная область. Все решаются различными способами.
Мы настолько собираемся кончать с задачами на Литкоде, что и постановки задач чёткие уже не нужны?
Asker1987
30.11.2023 13:11+5В последние годы стараюсь не упоминать на собеседованиях, что есть хороший бэкграунд по алгоритмам - олимпиады и все такое. Так как ненависть к олимпиадникам растет стремительно. В любой команде олимпиадники вызывали ехидство и отторжение у коллег. За последнюю неделю это примерно третья статья только на Хабре, где утверждается прямо в заголовке, что алгоритмы не нужны. Поколение войтишников требует новые стандарты. Скоро будут заставлять извиняться за знание алгоритма Дейкстры.
Всегда умилялся чисто фреймворковским программистам: прочитать килотонны материала по фреймворкам - легко, а пару глав из Кормена - нереально. А в чем дело?! Ведь автор утверждает, что алгоритмике - это шаблоны, зазубренные знания. Почему это вызывает сложность у всех хейтеров, ведь объем очень маленький? А потому что для изучения алгоритма, нужно построить в голове новые нейронные связи, сформировать логические цепочки, а очередной фреймворк как раз-таки можно за пол дня зазубрить и даже на лету применять, хотя документации по ним обычно больше, чем по алгоритмам.
В пользу автора скажу: на собеседованиях знание алгоритмов вам не поможет. Хоть задачи и примитивные дают на собеседованиях, но на них нужно отвечать ровно так, чтобы ты был чуть хуже интервьюера.
Автор говорит: любые задачи на оптимизацию можно решать, просто нужно время, а не сжатые сроки здесь и сейчас. Алгохейтеры в комментах оправдывают медленный код не незнанием алгоритмов, а сделать сделать, которые ставит заказчику и PM. Так может, потому что никто не хочет знать алгоритмы изначально, как автор? Хотите погрузиться в эти дебри потом, а когда наступает потом - некогда погружаться, хай будут вложенные циклы.
Печально, господа. Очень печально. Можно минусовать.
Alexsey
30.11.2023 13:11+2Так как ненависть к олимпиадникам растет стремительно.
Вполне справедливо и началось не вчера и даже не лет 5 назад. Очень часто олимпиадники и краснодипломники демонстрируют что у них проблемы с тем чтобы написать простой и поддерживаемый код. Или просто написать что-то что не является решением олимпиадной задачи. Далеко за примером того как не надо делать ходить не надо.
RichardMerlock
30.11.2023 13:11Учитывая, что это скорее всего выпускники, то с культурой кода могу быть не знакомы. На сколько сложно обучить олимпиадника облачать мысли в код согласно утверждённым требованиям? По идее, это же интеллектуальные, обучаем люди.
SpiderEkb
30.11.2023 13:11+1Там еще часто бывает проблема в том, чтобы полностью и в срок выполнить поставленную задачу. Не какие-то ее интересные кусочки, а всю целиком - и скучную часть и нескучную. И при этом еще правильно расставить приоритеты - где написать просто чтобы работало (потому что он работает 0.0001% общего времени и нет смысла тратить время на предельную оптимизацию), а где подумать над оптимальным решением потому что вот этот кусок критичный.
Если провести аналогию, олимпиадники - спринтеры - все силы в один рывок. А тут нужны марафонцы - нужно уметь правильно силы по дистанции распределить
inv2004
30.11.2023 13:11+2Не могу похвастаться уж слишком обширным опытом найма, но могу поделиться опытом работы в средне-больших командах, где были разные люди. Одни любили leetкод-задачи, другие не очень.
В целом, это слабо коррелировало с тем кто пишет хорошо, а кто плохо. Тут, скорее, какой-то навык аккуратности, и, не думаю что он хоть как-то к leet-задачам относится. Но, в минус leetcode тусовке я могу записать следующее - часто они кидались решать задачу каким-то "ручным" способом, игнорируя что некие абстракции и библиотеки для этого давно есть, отлажены и стабильны. С большей вероятностью, когда-то что-то падало из-за промаха индекса - это оказывался именно подобный подход - тип ручного прохода с индексом по каким-то данным. Добавлю, что все эти решение всегда оказывались хуже чем готовые библиотеки, что не удивительно - их отлаживали и оптимизировали годами
wataru
30.11.2023 13:11+1Если же подобные задачи возникают в ходе реальной работы, я использую библиотеки (обычно встроенные), которые прошли с нами огонь и воду.
Вот главная проблема. Ну нет библиотек на все случаи жизни. Вот, например, тут спрашивают вполне релистичную задачку. Весь "алгоритм" тут, как и в большинстве задачек на интервью - это умение в нужное место впендюрить хешмап. Писать его не надо, надо только уметь пользоваться стандартной библиотекой - знать эти самые "структуры данных". Тут вы ничего ненагуглите и решение готовое не найдете.
Другой пример, даже если задача вполне унифицируема и выделяема в билиотеку, без ее знания вы ее почти точно не нагуглите. Вот тот же sliding window max. Это и задачка на литкоде такая есть и мне она на практике попадалась - я ее даже в прод коммитил. Но без знания ключевых слов вы ее решение не нагуглите.
И третья проблема: без знаний алгоритмов и опыта решения задач, вы даже не заметите, что надо остановиться и погуглить библиотеку. Даже на литкоде большинство задач сформулированны "сделайте вот это вот" и можно условие буквально перевести в медленный код. А когда вам еще и условие не дано, а вам надо фичу для бизнеса запилить, то вы у себя в голове это "вот это вот" формулируете и даже не задумываетесь, что это, оказывается, задача. У вас в голове это уже решение для того, чтобы реализовать вашу фичу.
Поэтому алгоритмы - это совсем не бесполезные знания. Если вы нанимаете разработчика, а не формоклепателя - то они вам встретятся и понадобятся.
Другое дело, что это не единственный нужный навык, да и интервью такие имеют высокий уровень ложно-отрицательных исходов из-за стресса, невезения и вообще жестких рамок по времени.
Но, по совокупности критериев, это самый лучший вариант для интервью, если у вас большая компания и неиссекаемый поток кандидатов. Я этот момент подробно аргументировал в статье.
MiraclePtr
30.11.2023 13:11Вот тот же sliding window max. Это и задачка на литкоде такая есть и мне она на практике попадалась - я ее даже в прод коммитил.
Вы каждый раз так активно напоминаете про эту задачку, что такое ощущение, что кроме нее ничего подходящего больше не было. Типа "Смотрите все, смотрите, я наконец-то нашел таску, где мне пригодились алгоритмы!!!". Как будто самого себя пытаетесь убедить :)
Если вы нанимаете разработчика, а не формоклепателя - то они вам встретятся и понадобятся.
Ну так о том и речь, что большинству компаний как раз на самом деле хватит формоклепателей, но при этом они страдают от карго-культа "делать как в фаангах". Никогда не работал формоклепателем, но в принципе вполне могу их понять - работа не пыльная, платят все рано очень хорошо, вакансий много.
wataru
30.11.2023 13:11кроме нее ничего подходящего больше не было.
Это самый говорящий и простой пример. Кроме нее было и динамическое програмимрование, и дихотомия по ответу, и линейные регрессии, и хитросплетенные списки, и теория чисел. Но остальные задачи на литкоде 1-в-1 не встречаются.
boldape
30.11.2023 13:11Из опыта я понял, что на практике есть 2 структуры данных которые покрывают почти все потребности, это массив и хэш таблица, если добавить ещё и мапу то я затрудняюсь вспомнить, что из реальных задач не решалось.
Так вот, достаточно с пристрастием позадавать вопросы по этим 2 структурам данных по их интерфейсам, по сложности их методов и принципиальной разности реализации между ними в чем плюсы и минусы. Что можно делать с одним и нельзя тоже самое с другими и почему. Какие размеры контейнеров будут работать и с тем и с другим, а когда без правильной структуры не обойтись.
Как эффективно работать с контейнерами в функциональном стиле/итераторы, какие алгоритмы и хэлперы есть в вашей стандартной библиотеке в помошь. Тут конечно лучше показать код и попросить перевести на человеческий, что он делает.
Алгочасть полностью покрывается беседой о реальном опыте использования этих 2 структур, если человек ещё и про разницу между мапой и хэш таблицей может рассказать то это уже продвинутый чел.
А если знает как на основе этих базовых структур сделать более сложные производные структуры типа циклический буфер, стэк, очередь, индекс - то дальше про алгоритмы/структуры говорить нет смысла - человек в них прекрасно разбирается.
SpiderEkb
30.11.2023 13:11-1Из опыта я понял, что на практике есть 2 структуры данных которые покрывают почти все потребности, это массив и хэш таблица, если добавить ещё и мапу то я затрудняюсь вспомнить, что из реальных задач не решалось.
В моей практике - массив и связанный список. Крайне редко - дерево. И разного рода от них производные. Но в базе всегда или то или другое лежит.
Farongy
30.11.2023 13:11В любой практике есть две структуры данных - массив и связный список. А всё остальное строится на их основе)
wataru
30.11.2023 13:11+1Ну так большинство задачек и решаются сортировкой массива, втыканием мапы/хеш-мапы куда-нибудь. Просто справшивать про сложности методов и интерфейсы - это, во-первых, всего-лишь несколько фиксированных вопросов, которые, в отличии от задачек, можно зазубрить. Во-вторых, все будут дико плеваться от этих вопросов, мол: "ну что за бред, есть же документация, зачем мне наизусть знать все методы stl контейнеров!?".
boldape
30.11.2023 13:11+1В том то и суть, что вот эти структуры нужно понимать, а не смотреть доки, они основа. Да в доках можно что то уточнить, но суть операции человек должен рассказать сам на основе своей ментальной модели устройства этих структур. Там всего то по 4 основных и 2 спец операции + знание что происходит с итераторами, ну и факультативный резерв.
Необходимо, что бы человек понимал без доступа к документации, что происходит при произвольных вставках и удалениях, как осуществляется доступ по индексу/ключу. В какой последовательности происходит итерация, как безопасно итерироваить и использовать мутирующие операции на контейнере.
Ваше знание алгоритмов на абстрактных литкодовских задачах бесценно (в смысле ничего не стоит) если на реальных задачах (которые много проще) вам каждый раз требуется доступ к документации по базовым методам базовых контейнеров.
Есть прямая корреляция между тем как хорошо человек понимает базовые структуры и его способностью решать реальные задачи. Решив тысячи простых реальных задач, пофиксив сотни крашей связанных с непониманием стуктур, проведя десятки алго оптимизаций и написав единицы уникальных алгоритмов у меня сложилось вот такое мнение.
wataru
30.11.2023 13:11+1Необходимо, что бы человек понимал без доступа к документации, что происходит при произвольных вставках и удалениях, как осуществляется доступ по индексу/ключу.
Ну вот: 4 структуры (массив, хешмап, дерево, список), 4 операции (вставка, удаление, поиск, итерация) - итого 16 вопросов, которые можно выучить. И никак вы не поймете - это зазубренная "китайская комната", или человек действительно понимает.
Я полностью с вами согласен, что понимание базовых структур данных - это основа. И этой основы достаточно для прохождения большинства алгоритмических интервью. Но я считаю, что беседой вы эту основу никак не проверите. Поэтому и надо давать задачки, чтобы кандидат должен был сам вспомнить, какие есть стурктуры и понять, какая тут лучше всего подойдет.А про документацию - это был аргумент о том, что даже если бы "беседа" работала, такие интеврью ненавидели бы, наверно, еще больше чем алгоритмические задачки.
boldape
30.11.2023 13:11За всю 20+ летнюю програмерскую жизнь список в продакшене так ни разу мне и не понадобился (всмысле задачи где он лучше других подходит), а с учётом того что он не дружит с кэшами и постоянно хип теребенькает да ещё и оверхед по памяти на каждый элемент, то я как вижу лист в комитах сразу записываю имя автора, я уверен у меня к нему будет ещё не один вопрос/предьява.
Вы попробуйте вместо алго задач поговорить про базовые структуры, а уж потом будете судить, что лучше работает и так ли уж получается у людей тупо зазубрить эти знания. Шок, срывы покровов и много лулзов вам обеспечены. Ну а с достойным кандидатом просто приятно пообщаетесь.
Так то я помню те времена когда я сортировку на листочке писал на собесе и как меня потом похвалили, что я один за 3 года собесов правильно =,< расставил, а потом занимался тем, что работал мясным транслятором из Ява на с++ в постпродакшене мобильных игр.
И вопросы про люки и количество заправок в городе я тоже помню, а ещё до этого вы не поверите меня отшили на бесплатную практику/стажировку (ещё студентом) потому, что я не особо различал философию Канта и ещё какого то перца и хоби у меня не было. Да даже ещё 10 лет назад на собесе у меня спрашивали кем я себя вижу через 5 лет в этой конторе.
Это я к чему? Да к тому, что дичи на собесах раньше было значительно больше чем сейчас и алго задачи тоже окажутся там же где и вопросы про люки - со временем.
sssrgei
30.11.2023 13:11Все зависит от вакансии. на какую-то нужно знать алгоритмы, на какую-то не нужно. Но умение составить свой собственный алгоритм нужно в любом бизнес приложении - на лит код ты его натренируешь за неделю или написав 2000 миграций на работе за 10 лет, это в принципе не важно. Сколько раз я брал людей, которые не смогли решить "задачку", оправдывая это нервами, но отлично справляясь с остальными заданиями, столько раз я жалел об этом и потом тратил свои нервы, увольняя их.
К сожалению, в реальных проблемах не любой алгоритм можно найти в библиотеках. И на собесе надо прежде всего проверять не память на алгоритмы, а умение составлять собственные алгоритмы. Когда мне на собесе говорят, что мол забыл, как решать задачу, внутри меня немножко закипает. Бизнес не скажет тебе: а ну нет так нет, давай займемся плавлеными сырками, раз с IT не получилось. У бизнеса есть задача, которую надо решать и это будет делать либо вновь нанятый сотрудник, либо ты сам. И на собесе надо определить способен ли он решать задачи в первую очередь, а не количество заученных паттернов, алгоритмов и тп.
Меня, кстати, раздражают бубнящие соискатели, которые комментируют каждую строку, не знаю откуда пошло это поверье, что если рассказывать вслух свои мысли это поможет на собесе - я 20 лет "у власти" и научился интерпретировать код написанный за 10 минут.
В целом статья интересная, хоть далеко не во всем согласен, но главная мысль ценна.
inferusvv
30.11.2023 13:11Нужны или не нужны алгоритмы можно размышлять долго. Но вот простая ситуация - хочу работу и много денег. А на собеседованиях просят алгоритмы. Что делать? Правильно - решать. И ничего с этим не поделаешь. Такова жизнь.
Asker1987
30.11.2023 13:11+1Подозрение вызывает другое. В вакансии обычно требуют минимум 10 технологий. На каждую технологию есть трёхтомник. Даже на JUnit просто тесты - документация 150стр. На алгоритмы - совсем немного требуется, пару глав из Кормена,но..... "Нам не надо, это можно гуглить, это не для практики и т.д."
Скорость изучения фреймворков равна скорости чтения документации или просмотра Ютуба. А вот с алгоритмами у 99% вайтишников возникают непреодолимые проблемы, ведь это надо уметь не читать, а... думать! Но это на практике им не пригождается же ????
askharitonov
30.11.2023 13:11-1С другой стороны, а потом мы удивляемся, что приложения всё прожорливее в плане ресурсов, а делают примерно то же, что и раньше. А может дело как раз в том, что очень многие программисты решили, что алгоритмы не важны?
MiraclePtr
30.11.2023 13:11+3Неа, не в этом. Дело в запросах рынка и менеджмента.
Даже профессионал, способный использовать и разрабатывать алгоритмы, может решить задачу двумя способами: тупо и быстро по времени, но не оптимально (например, взять фреймворк, библиотечную функцию, скопипастить готовый код, и т.д., пусть даже все оно не самое оптимально и не идеально подходит для конкретной задачи) за N времени, либо же основательно подумать над задачей, выбрать и реализовать максимально эффективный для нее алгоритм и сделать все правильно, но за 3N времени, а то и за 5N времени.
И основная проблема в том, что на вопрос "Вам так или так?", то 90% заказчиков/работодателей (если только вы не пишете код для бэкенда каких-нибудь FAANG'ов или серьезных банков и не разрабатываете игры и мультимедиа-приложения) скажет "нам главное чтобы фича была запилена по-скорее, в идеале еще вчера, проблемы с производительностью будем решать когда они возникнут и если вообще возникнут, пусть юзеры просто побольше памяти себя купят". Вот получаем то что получаем.
sergey-gornostaev
30.11.2023 13:11+4А ещё бывает, что можешь решить быстро и оптимально, но руководство говорит, что код слишком сложный, тяжело и дорого нанимать людей, способных с таким работать, что лучше они закидают ресурсами примитивное решение.
Venje
30.11.2023 13:11Давайте пойдем дальше. Алгоритмы это еще не все чтобы код летал. Нужно ввести дополнительный уровень на собеседованиях после алгоритмов. На нем спрашивать про архитектуры процессоров. Дальше нужно будет определить почему сгенерировался неоптимальный ассемблер для конкретной архитектуры и как это исправить: live-coding секция в godbolt.org. Задачи на понимание двух типов кэша, задача на векторизацию и что-нибудь еще по вкусу. Вдруг возникнет такая задача за несколько лет работы, а вы не знаете. Бедному работодателю придется второй датацентр покупать из-за вашей некомпетентности. А так сэкономите тучу денег и возможно даже вас по плечу похлопают!
Nansch
Вот эти все прогоны по алгоритмом с литкода и прочим задачам, не относящимся к потребностям позиции возникают потому, что закрыть позицию у бизнеса не горит, а ответственный за найм не терпит убытки. А вот когда начнёт пригорать, то основными критериями становятся: приходить каждый день, не косячить, соблюдать регламенты, разбираться в проекте, работать в команде.
dsh2dsh
Согласен. В процессе поиска работы вижу, что все вакансии существуют по принципу: не очень то и нужно.
micronull
КМК идёт бесконечное просеивание кандидатов, чтоб из крупиц высеять золото по их критериям.
Цель забрать лучших к себе в команду.
rezedent12
Это не поиск лучших. Это агрессивная фильтрация худших.
khajiit
Причем по критерию nor-and из списка, слабо пересекающегося с актуальной предметной областью: несколько минорных несовпадений со списком отбора, вместо целевого списка — и приплыли, даже если с целевым списком корреляция 146%.
Fell-x27
Тогда и писали бы "нужен специалист по Литкоду"...
Mirn
да да, потом такие спецы по литкоду наяривают на килобайты и миллисекунды и удивляются почему их не хотят брать как например тут забывая что пишут код они пишут для команды и в команде тоже надо уметь работать. А литкод для одиночек но его можно использовать проверки работы в команде (обсуждать решение, просить изменить условия и тд, как sandbox он всё же не плохой и не все задачи там плохие, есть 10-20% прям хороших а это много сотен - огромный выбор)
Fell-x27
Ды так-то килобайты и миллисекунды это тоже хорошо, но хорошего понемножку. Как говорится, ты сначала сделай, запустись, набери аудиторию и выйди на уровень, когда килобайты и миллисекунды начинают решать :)
iosuslov
Абсолютно согласен. Это становится особенно очевидно, когда смотришь на список компаний, которые этот этап практикуют: Озон, Яндекс, ВК и т.д. - т.е. это компании, у которых входная воронка кандидатов такого размера, что они не только по алгоритмам могут гонять, но и по физическим параметрам отсеивать - и все равно закрывать свои вакансии.
Я для себя так решил: спрашиваю у рекрутера - будут задачи на алгоритмы на собесе? Прям задачи, а не просто про биг о поболтать? Если да - то я пас, у меня вообще нет никакого желания упарываться в литкод, чтобы пройти собес.
Nansch
В корпорациях следят за тем, чтобы небыло незаменимых сотрудников. Строят матрицы компетентности, двигают сотрудников, следят за единообразностью подходов. Даже если разбежится пол проектной команды, то это не станет катастрофой. Так что да, в таких компаниям обычно нет требования срочно закрыть позицию.
PuerteMuerte
Это в корпорациях есть, но работает точно так же, как и любые другие распорядки в любом другом обществе. Т.е. как повезёт, в зависимости от желания руководства подразделений реально тратить на это своё время, или просто создавать видимость. От потерь компетенций пре уходе половины проектной команды в крупных корпорациях куда чаще спасает её серьёзная раздутость и избыточность, чем матрицы этих самых компетенций.
mclander
Иногда это просто тупая дедовщина: я прошёл этот барьер, я крутой. А ты, червяк, не прошёл - и нечего занимать место в нашей крутой компашке
Меня всегда умиляют вопросы про специализированные вещи, про которые ты никогда не слышал, но если бы поинтересовался, то разобрался бы в полчаса. А на собесе, надо достать их из кармана и, с придыханием, продемонстрировать
Ни разу я не сталкивался с более чем логичным продолжением: ну раз не знаете, давайте мы созвонимся через час и решим какие-нибудь задачки на эту тему. Это 100% тест на то, как кандидат будет выплывать в реальной ситуации собственными силами, а не на внезапно стоящей в кустах яхте
sim31r
Многие так и делают. Когда ведут собеседование тимлиды и руководители отдела как-то так и есть. Даже интересно пообсуждать какие-то задачи. Особо увлеченные сами объяснять начинают как решить задачу, а ты просто наблюдаешь и дополнить не успеваешь ))
На галеры идут задачи по опроснику, типа способы вывода в Excel и виды указателей. Обычно этого не помнишь, даже если пользуешься, проще глянуть в ранее написанный код или погуглить. И заваливаешь такие тесты. Но там обычно и компании особо не нужны новые сотрудники, ведут наем потоком на всякий случай, и собеседуемым тоже особо не надо. После успешного собеседования может оказаться что зарплату ниже ожидаемой предлагают.
Если мне наоборот поставят задачу провести собеседование, я вот даже не знаю как бы проводил. Наверное по шаблону типовому как все.
nlykl
Это чтобы сбить у кандидата уверенность, тем самым умерив аппетиты по зарплате.
acsent1
Но как можно проверить вот эти вот навыки у кандидата?