Comments 96
А вот пример, почему алгоритмы полезны. Есть у тебя вакансия. На нее нужен один человек и на нее скажем 800 претендентов. Хрюши отсеяли тех, кто вообще ни в какие ворота и теперь претендентов 300. Кто-то из команды или нанимающий менеджер почитал резюмешки, и теперь их 100. Надо чтобы осталось хотя бы человек 15, с которыми можно будет по-человечески поговорить часа два. Как это сделать?
Ну вот есть статистика, что если взять сотню чуваков со знанием алгоритмов, 70 из них не вылетят после первого полугода. А если случайную сотню - то 20. Почему так? Да хрен его знает, наверное, как-то связано. Если бы вместо алгоритмов там было жонглирование или решение задачек на стулья с пиками пинг-понговые шарики - задавали бы задачки на пинг-понговые шарики.
То бишь, это исключительно статистическая история для больших чисел. Другой вопрос, если у тебя вакансия и на нее пять претендентов, а не восемьсот. Да ты можешь с каждым из них целый день провести в парном программировании или беседах за жизнь - лучше это и предпочесть. В этом случае литкод-собес не оправдан.
Ну вот есть статистика, что если взять сотню чуваков со знанием алгоритмов, 70 из них не вылетят после первого полугода. А если случайную сотню - то 20. Почему так? Да хрен его знает, наверное, как-то связано.
У меня сейчас скорее не 70 и 20, а 90 и 80. Да и в целом довольно смешной выглядела ситуация в том же Яндексе в году 17-м, когда джуны умели решать алгоритмические задачи, а начальники и авторы многих вполне успешно работавших сервисов честно признавали, что нет. То есть умение решать алгоритмические задачи на собеседовании не очень коррелирует даже с умением решать алгоритмические задачи на работе. Потому что в одном случае нужно уметь быстро вспомнить одно из типовых решений, а в другом - медленно и вдумчиво выбрать из нагугленных решений. Да, кругозор полезен, чтобы как минимум знание что гуглить. И пока люди специально не готовились к алгособесам от них был толк. Они позволяли понять этот самый кругозор. Проблема началась, как только к собеседованиям стали массово готовится. Теперь они показывают только усидчивость.
Другой вопрос, если у тебя вакансия и на нее пять претендентов, а не восемьсот. Да ты можешь с каждым из них целый день провести в парном программировании или беседах за жизнь - лучше это и предпочесть.
Не можешь, кандидаты пошлют такое лесом.
не решается никакая проблема 800 претендентов. Эти претенденты в 1 секунду вывалилисиь на рынок труда, эти претенденты могут уйти в другие компании пока ты устраиваешь 8 раунд алгоритмического собеса, претенденты это не собаки безвольные и так уж вышло пока имеют выбор где работать.
Найм нового работника всегда будет риском для обеих сторон, а искусственное затягивание процесса найма, как раз таки и может позволить себе Только гигант, коих примерно 5, да, потому что фактически успех\не успех найма ничего не изменит в бизнесе.
Исходя из этого смешно говорить что яндекс=фанг, потому что яндекс таки пылесосит рынок как не в себя.
эти претенденты могут уйти в другие компании пока ты устраиваешь 8 раунд алгоритмического собеса
Фаангу эта проблема не грозит. Люди знают, на что идут, но люди хотят получать заметно выше средней зарплаты и всякие бонусы. И практически все компании в этом сегменте делают по несколько раундов интервью, так что люди отваливаются по пути относительно редко.
Яндекс - ФААНГ, потому что это большая компания, у которой много данных и много прибыли, поэтому алгоритмы им релевантны, а зарплаты там выше рынка, а следовательно, у них толпы за забором.
у яндекса выше рынка? выше рынка чего, овощей, одежды?
300 тысяч в месяц мидлу в москве - это не выше рынка?
Да не особо. Недавно собеседовал андроид разработчиков - те кого я мог бы назвать мидлами - все поголовно 250 и выше просили.
Как в том анекдоте*: так и вы говорите просите. Сторговались-то в итоге на сколько? Вон на хабре, написано, что 200 тычяч в москве медианная в прошлом году была. Сеньеров сильно меньше чем джуниоров, так что это должно быть выше медианной среди мидлов.
*анекдот
Приходит дед к врачу:
-- Ой доктор, проблема у меня с причиндалом. Бабку мою могу всего-то раз за ночь, и то не каждую.
-- Да какие у вас проблемы, в 80 лет-то - вообще идеально все.
-- А сосед мой говорит, что в свои 85 по 3 раза за ночь может!
-- Ну так и вы говорите.
Где то на столько и сторговались. В общем в мобилках у мидлов по моим ощущениям как раз сейчас 250-300 плюс минус вилка рыночная в мск/на удаленке.
Хотя тут есть где то возможно искажения по определению уровней. Что в одной компании синьер, в другой может быть мидл-. По рынку хватает людей с около 5 годами опыта, которые формально вроде мидлы, но вообще не вытягивают этот уровень от слова совсем.
Я бы сказал, что это ниже рынка
Спасибо за коммент!
Если стоит задача из 100 отобрать 15 то, как пример, можно ввести ещё одну линию отсева, например 15-ти минутный скрининг с hr, где есть варианты ответа на вопрос, либо чуть более углубленный первичный технический скрининг, опять же, по вопросам домена вакансии. На нем мы, например, оставляем только тех кто ответил отлично, но не копаем сильно в глубину. По кандидату записываем результаты, чтобы на основном интервью не возвращаться к вопросам и говорить на другие темы (либо вообще в другом формате - парное программирование или сис диз например) в любом случае это даст скосить столько же людей, но не по знаниям алгоритмов, а по доменной сфере работы
Воспользовавшись советом HR, я пошел на Leetcode — самую популярную площадку для тренировки алгоритмов и решал все задачи подряд.
Ну а насчет литкода - ну может быть, просто не дано. Кто-то действительно за десять дней умудряется подготовиться, а вот мне надо не меньше полугода по паре-тройке часов в день.
На мой взгляд, алгоритмическая секция это рудимент того подхода, который разрабатывали FAANG компаниях под свои нужды, почти все компании перенимают его из-за его простоты и популярности.
Да, копировать интервью у ФААНГа, если вы не ФААНГ - глупость и карго-культ. То, что отлично работает там, не обязательно лучший вариант в других местах.
Если бы ваша статья прямо содержала "в маленьких компаниях", я бы целиком и полностью согласился с вашей статьей. А так выглядит, что вы считаете, что и ФААНГам стоит от них отказаться. И с этим я категорически не согласен. У меня даже целая статья есть на тему того, что алгоритмические собеседования для ФААНГов и других больших компаний нужны: https://habr.com/ru/articles/774862/
Сами по себе они не так уж и плохи. Алгоритмы действительно пригождаются, особенно в ФААНГах, так что проверяется весьма релевантный навык. Плюс, программиста заставляют писать код - эта часть обязательно должна быть в любом интервью.
Разве что false negative у алгоритмических интервью побольше каких-нибудь других типов. Но зато они с лихвой это компенсируют масштабируемостью и низким false positive, что ФААНГам важно в в первую очередь.
вы с вашим потенциальным коллегой решаете рабочую проблему, тут не важен язык программирования и даже не всегда важен рабочий код.
Всегда стараюсь делать именно так. Но, к сожалению, редко когда можно взять рабочую проблему, абстрагировать и ужать ее, чтобы можно было дать это на интервью. Поскольку задачи постоянно утекают и их приходится ротировать, далеко не всегда можно так сделать. Поэтому появляются чуть более абстрактные и, возможно, искусственные задачи.
По моему опыту, основная причина провальности лайвкодинга - привычный способ мыслить. Обычно если программист видит алгоритмическую задачу, он думает о ней, визуализирует проблему, получает ощущение охвата проблемы, ее осознания, потом его мысли блуждают вокруг и в какой-то момент из ничего выскакивает видение решения. Сделать это под стрессом невозможно - мозг пугается, все время сбрасывается и не входит в нужное состояние.
Для того чтобы решить задачу на собесе нужно уметь мыслить как чат GPT - сразу с ходу генерить и озвучивать идеи и постепенно приходя к решению.
Чтобы подготовитсья, я делал так. Брал не сложную задачу с литкода и вместо того чтобы думать о ней начинал сразу в слух ее обсуждать, пытаясь найти решение (второй этап - обсуждать еще и на английском). Таким образом удается перестроить мышление с образного на вербальное. Дальше, на собесе когда предлагают ливкодинг, сразу начинаешь обсуждать задачу, это нравится интервьюеру, он участвует и ждет, через какое-то время надо выйти на решение. До решения задач на собес гугла я не дошел, но после этой тренировки вербального мышления, задачи типа обхода бинарного дерева или ревью кода на собесе перестали быть катастрофой.
Сделать это под стрессом невозможно
Тогда собеседованя не работали бы совсем. И соревнования по программированию не существовали бы.
На соревновании никто не сидит напротив, глядя тебе в рот и оценивая насколько ты хорош.
Есть варианты. Можно научиться не испытывать стресс чтобы нужный глубокий креатив работал на собесе, можно научиться решать задачи настолько хорошо чтобы креатив на собесе был уже не нужен. Научиться говорить и думать параллельно это самое прямое решение проблемы собеседования. И может пригодиться в работе в качестве софтскила.
Наконец-то хоть кто-то про это написал, спасибо вам! Считаю, что лучшее собеседование (да, сам проходил успешно именно такие) — это тестовое задание для отсева, причём желательно похожее на то, что человек будет делать на работе, а потом интервью с просьбой написать кусок кода, спроектировать БД или что-то такое же, максимально приближенное к области работы. Понимаю аргументы автора комментариев выше, что для реально большой компании с 800 человек на место это не работает (наверное). Но я не знаю ничего более стрессового, чем алгоритмические задачи на собеседовании. Хуже этого — только алгоритмические задачи на бумажке.
Наконец-то хоть кто-то про это написал
В смысле "наконец-то"? За последний год штук 5 таких статей было.
Тестовое задание считается ещё более спорным и ненавистным (для многих) пунктом.
А насчет бумажки вы зря, там зато не надо дебажить под ключ, бумажка простит всякие мерзкие ошибки на единицу и прочие корнер-кейсы.
Тестовое задание хорошо, если вы выбираете из 2х компаний. Ну и если оно рассчитано не больше, чем на 2 часа. Но и тут есть но - для вас эта задача может занять 2 часа, т.к. вы часто кодите в этом направлении. А для другого в 3 раза больше, т.к. он кодил в другом направлении.
А готов делать 50 тестовых заданий в день? потому что примерно столько откликов в день нужно делать когда находишься в поиске, а скинуть тебе тестовое можно даже если резюме не нравится с них не убудет.
P.S. Уважаемый автор, если я вас случайно минуснул, извините, ради всех богов, — accessibility Хабра оставляет желать много лучшего, и разработчики обе кнопки пометили как «Голосование» (спасибо, очень полезно).
Я видел, так делают: @Boomburum
Действительно странно: у button свойство title правильное расставленно — «Нравится» и «Не нравится». Но вот внутри кнопки лежит svg, внутри которого тэг title со значением «Голосование»
Здравствуйте. Так и не понял почему это самый провальный этап собеседований, если, например, использовать его как инструмент уменьшения количества кандидатов на вакансию, то очень даже прекрасный. В действительности есть корреляция между хорошим инженером и умением решить алгоритмическую задачу, следовательно и предпочтению желательно отдать кандидату умеющему решать такие задачи.
Как инструмент отсева он примерно так же хорош, как и просто случайно выбрать 15 резюме из 100. Где гарантии, что люди, прошедшие отсев алгоритмами, умеют только в алгоритмы, потому что месяцами учили только их, а в работе они "не очень"?
Если человек способен выучить алгоритмы и структуры данных так, чтобы решить незнакомую до этого задачу, то: он умеет думать, способен выучить большую и сложную тему, способен написать более менее понятный и корректный код.
В этом случае работу работать он точно может. Выучить один фреймворк по сравнению с дюжинами алгоритмических тем - элементарно. Перекладывать джсоны по сравнению с динамическим программированием - не составит никакого труда. Спроектировать маленький модуль проще, чем разбить задачу на подзадачи и связать воедино несколько шагов алгоритма.
Плюс, если алгоритмическая задача, таки, попадется (а в ФААНГах они попадаются, я на личном опыте знаю), то такой человек ее решит, а не напишиет наивное плохое решение даже не задумываясь, что тут какой-то этот ваш алгоритм вообще нужен.
Да ладно)
Архитектурные навыки набиваются исключительно на практике. И именно эти навыки решают как много бизнес будет тратить денег на поддержку и развитие продукта.
Алгоритмы тут вообще ни каким боком.
Да, но ведь архитектурные навыки должны быть только у более сеньерских позиций. И на них всякие гуглы проводят отдельное system design интервью. Но эти интервью гораздо дороже алгоритмических, ведь их могут проводить только очень опытные и высокопоставленные сотрудники, а задачи сложнее придумывать. Поэтому у сеньеров спрашивают одно system design и несколько алгоритмических интервью, а не наоборот.
В том-то и дело что нет. Вы проверите, что он умеет только решать плюс-минус стандартные задачи на алгоритмы, не более того.
Что у него с работой в команде, с чистотой кода, ответственностью, умением разбираться в предметной области - нет. Если вам нужна код-мартышка, может это имеет смысл, да. Но опять же нет гарантий, что он не "задрочил" алгоритмы и не сядет в лужу на первой же бизнесовой задаче.
Что у него с работой в команде, с чистотой кода, ответственностью, умением разбираться в предметной области - нет.
Работу в команде вы кроме как испытательным сроком не проверите. Фаанг вообще проводит behavioral собеседования для этого, но я их презираю. Их завалить может только полный социопат. Ну и людям с не очень подвешенным языком надо будет сильно напрячься.
Чистота кода - конечно, проверяется. Если кандидат способен выдаивть из себя 10 чистых строк кода на интервью, то уж и в работе сможет это сделать, если захочет. А он захочет, ибо в ФААНГах код ревью всего кода.
Ответственность - это как вообще проверить? Поболтать по душам? Вы так только полных аутистов отсеите, остальные вам будут просто врать.
Предметная область - у ФААНГа она своя внутренняя. Ее снаружи никто не знает в основном, зачем ее проверять. Если же там какая-то специальная позиция, например machine learning, то для этого проводят дополнительное интервью. Но, опять же, они сильно дороже и сложнее для компании, чем алгоритмические, поэтому они - последний этап после отсева несколкими алгоритмическими.
когда твоих эйчаров перманентно брутфорсят индусы с китайцами случайная выборка будет фильтровать заметно хуже чем литкодом
Я был единственным андройд разработчиком
Я бы понял написание "андройд" от кого угодно, но не от андроид разраба... И встречаю все чаще и чаще такое написание. Что вообще происходит?
Читая такие попытки рефлексирования, я вот хочу понять. Вот мы, или они, ищем программиста. Вот как его проверить?
Всем хочется, чтобы и код полезный писал, и работящий был, и "спикал" на всякий случай. Но проблема в том, что это надо проверять.
А программист - это ж не грузчик. Качество написания кода зависит от того, как он думает, что знает, какой имеет опыт, как он реагирует на ранее допущенные ошибки
---------------
Иногда мне кажется, что люди, и даже сами програмисты смотрят на себя, как на грузчиков. Вот я не применяют в работе напрямую - значит мне не надо. А то, что это сформировало твое мышление и ты уже полузуешься чем-то не особзнавая этого - это не важно.
Вот автор статьи решал алгоритмы - это же наверняка его развивало, прокачивало "думалку". Может и нет, я не знаю, может он заучивал решения. Но он для себя пользы не видит. Ну ОК, в итоге каждый приходит сам к тому, кто он есть
Вот мы, или они, ищем программиста. Вот как его проверить?
Если вот вам - т.е. непосредственно вам - нужен программист, вы разве не знаете как вам его проверить?! Проблема - которую затрагивает автор - она вообще не про это, имхо.
Вот я не применяют в работе напрямую - значит мне не надо. А то, что это сформировало твое мышление и ты уже полузуешься чем-то не особзнавая этого - это не важно.
Кто бы спорил за "мышление" и его "развитие"... вот только мой личный опыт мне "шепчет", что освоение - например - теории сложности вычислений - вполне может, если и не "сформировать твое мышление", то уж точно на это "мышление" повлиять. А вот знание (причем весьма условное "знание", в подавляющем большинстве случаев) конкретных решений конкретных задач - очень сильно вряд ли.
В этом смысле, "алгоритмы" - сугубое имхо - это такой аналог насмотренности у каких-нибудь, условных, "дизайнеров". Весьма условный, надо понимать, аналог... но, с ровно такой же "ценностью для".
А вот знание (причем весьма условное "знание", в подавляющем большинстве случаев) конкретных решений конкретных задач - очень сильно вряд ли.
Если програмист "запоминает" решения, чтобы их выдать на собеседовании - это не имеет смысла. Если он учится их решать - это развивает его "думалку", что полезно. Вопрос в том, кто что делает. Понятно если кто-то делает "первое" - то вывод о вредности справделив. Но только для него
В этом смысле, "алгоритмы" - сугубое имхо - это такой аналог насмотренности у каких-нибудь, условных, "дизайнеров". Весьма условный, надо понимать, аналог... но, с ровно такой же "ценностью для".
Насмотренность тоже полезна, так как "изобретение колеса" требуется не так часто. Но тут действительно не нужны "алгоритмы". Я обычно прошу рассказать о каких-то примерах из реального опыта решения бизнес задач, а дальше куда "кривая" выведет
Кстати я лично не задаю задачи на алгоритмы, так как часто на собеседование выделяется час, а на это нет времени. разве что спросить что-то вроде "как передать максимум инофрмации между космическим кораблем и землей, если окно связи равно 20 минутам, а сигнал идет 5 минут" или подобные вопросы для понимания кругозора кандидата
Если он учится их решать - это развивает его "думалку" ...
Что значит "учится их решать"?! Как? На основе чего?
Есть разница между "протыкать" задачи сортировки (пусть даже - сложные) на каком-нибудь, условном, leetcode, и усвоить третий том Кнута? Нет?
Насмотренность тоже полезна ...
Разве кто-то с этим спорит?! Речь о её ценности. Если хотите, о её пригодности в использовании в качестве меры. Т.е. - даже если для "реципиента" есть какая-то польза (условное, "развитие думалки") - то пригодность такого рода "насмотренности" в качестве меры - имхо - около нулевая.
Что значит "учится их решать"?! Как? На основе чего?
На основе практики и теории :) Ну блин, я даже не знаю как вам пояснить.
Школьник как учится решать задачи? А студент? Ну или ... а как в шахматы учатся играть
Или это был риторический вопрос? Тогда прошу прощения, не понял
Разве кто-то с этим спорит?! Речь о её ценности.
Ну почему же? У вас есть два кандидата, оба показали все одинаковое, но в алгоритмической секции результаты разные ... :)
Плюс надо понимать, что задачки показывают:
как человек думает
как борется с трудностями
как может пояснить свое решение
Т.е. легко оценить способность к:
коммуникации и передаче знаний
реакции на изменение вводных
готовность вообще чего-то делать
Вы же надеюсь понимаете, что на любом вопросе кандидат раскрывается не только как "чистый" програмист, но и как человек
На основе практики и теории :)
Ну вот выше были "задачи сортировки" c - условного - leetcode. С "практикой" - более менее понятно. Что за "теория"?
Или это был риторический вопрос? Тогда прошу прощения, не понял
Нет. Это не риторический вопрос.
Вот "научился" я - например - десяти разным способам сортировок. Даже - предположим - я знаю и понимаю области применений этих - конкретно этих - "решений". Т.е. я без проблем смогу их воспроизвести, рассказать "что-по-чём" в рамках каждого конкретного "решения" и т.п. Я - типа - "мастер вот этих вот десяти способов сортировки".
Упустим, что это дает лично мне. Важно, что это дает "нанимателю"? Т.е. вот кроме того, что он теперь знает, что я могу и "так", и "сяк" и ещё восемь разных "-як".
Ну почему же? У вас есть два кандидата, оба показали все одинаковое, но в алгоритмической секции результаты разные ... :)
Ну ок. Вот есть я - "такой красивый". Но, не могущий "обобщить" свои "знания" до - допустим - задач поиска. А рядом - не менее красивый - "мастер вот этих вот пятнадцати способов поиска", который не умеет в сортировку.
Дальше что?
Плюс надо понимать, что задачки показывают ...
"Задачки"-то, может и показывают. "Алгоримы"-то - сиречь, конкретные решения - тут причем?
При всей "ремесленности" нашей области деятельности, т.н. "алгоритмические задачи" ведь даже не являются в ней типовыми.
Т.е. легко оценить способность к ...
Ну т.е. важно не само "решение". Так?
"Задачки"-то, может и показывают. "Алгоримы"-то - сиречь, конкретные решения - тут причем?
Важно не "знание" конкретных алгоритмов, а умение их строить. Я напомню, что "алгоритм" по сути равен решению задачи. Ну и вообще теоретически это две половинки одного целого :)
Вообще мне сложно ответить на ваш вопрос, так как на собесебовании проверяется:
знания / опыт
умения
софт-скилы
Так вот, самое легко прниобретаемое - это знания. Понятно, человек должен иметь базу, но в реальности это самая малоценная для меня категория
Умение же решать задачи мжет оказаться таким, что человек никогда не дорастет до требуемого уровня
Так вот, задачи могут показать все это, если вы
просите решить задачу -> алгоритм
уточняете как это работает под капотом (к примеру коллекции в Java) -> знания
смотрите на реакцию -> софт скиллы
----------------
Я наверное отвечу вам так. Когда вы что-то хотите узнать, не обязательно задвавать прямой вопрос. К примеру, в проекте достаточно спросить разработчика о статусе и начальная инфа моет быть уже получена по тону, или выражению лица, или паузе перед ответом.
Тоже самое на собеседовании. Косвенная информация не менее важна, вопрос в умении ее видеть.
Не надо смотреть "одноклеточно". Знает "сортировку пузырьком" - подходит. Но я допускаю, что есть компании, которые так и поступают. Ну такое, мне лично что до этого?
а если бы у работодателя была возможность увольнять "по щелчку", не стали бы эти этапы интервью лишними? Я к тому что, достаточно провести устное тех-интервью и определив что кандидат более-менее подходит брать сразу на работу. Не подошел, до свидания.
Нет. Ибо даже хорошие кандиадаты довольно долгое время въезжают в кодовую базу, и по началу все работники будут очень мало продуктивны. Потом, когда зерна от плевел отсеются уже пара месяцев и прошло. И это 2 месяца потерянного времени, а не только 2 зарплаты. Плюс у больших компаний будет оплата переезда и стартовый бонус. Это еще несколько зарплат. Но потерянное время, конечно, компании дороже.
Сталкивался с ситуацией, когда некоторые "эффективные" притаскивают kpi другим "эффективным" - увольнение на испытательном, увольнение в первый год... После первого лоботряса, которого сохраняют "эффективные" ради своих цифирок в ущерб команде, тех.иньервьюер решает жестить больше. Случай из практики, не более.
на дворе 2024 год, я все забыл
это нужно только для собеседований
я не стал круче, наоборот, иногда я пытаюсь “сделать алгоритм” там, где это не нужно
Ерунда, сам поменял работу в 2022, так что тоже тогда решал много задачек, недавно позвали на собеседование и я опять взялся за литкод, да, медленнее, чем раньше было в конце пути, но намного быстрее, чем было на старте, сейчас зачастую средние задачки делаю сходу быстрее, чем раньше делал легкие задачки.
Любое перекладывание джосонов, это алгоритм. Где также можно напортачить. Навык решения алгоритмических задач дает меньше шансов этого сделать. Практический пример: так уж сложилось, что попал в крупную компанию, где литкодовского этапа не было, был как-раз приземленный: бакендщику дают написать сервис под заданные параметры за полтора часа, а потом еще час обсуждений с пятью человекама того, что получилось и на околозаданные темы, включая систем дизайн и прочее. Так вот, после опыта литкода, делая код ревью я частенько заворачивал код, когда, например, в цикле запрашиваются одни и те-же тяжелые данные, которые можно было запросить один раз за пределами цикла. Или, например, когда какой-то метод в цикле вызывает метод другого класса, а тот метод опять-же в цикле берет из базы, или из стороннего сервиса данные, которые есть у вызывающего, так что можно было их просто передавать в метод. Таких вещей просто море и у сеньеров и у тех, кто даже еще выше. А если есть опыт алгоритмических задач - глаз их ловит на лету.
Это всего-лишь один из навыков, который полезен в работе.
С того провального собеседования я не написал ни строчки алгоритмов, но я бы не сказал, что потерял какой-то навык, ведь я его и не приобретал.
По моему скромному разумению, все холивары вокруг нужности или не нужности алгоритмов на собеседованиях порождаются тем, что действительно, для подавляющего большинства компаний удается не обращать особого внимания на алгоритмическую сложность задач просто потому, что либо задачи по настоящему не слишком высоконагруженные, либо для заданной нагрузки ресурсов хватает, чтобы потребности заказчика были сносно удовлетворены. Ну конечно, эти компании считают себя крупными, и это так - в отношении ворочаемых ими финансовых оборотов. Но зачастую это не обязательно связано с тем, что ворочаемые ими данные действительно очень большие. А вот когда вы наконец-то попадете в компанию, где действительно будете работать с big data, вот тут-то все самое интересное и начнется, и опыт работы с алгоритмами и их понимание ой как пригодится, честное слово. И тогда будет понятно, что FAANG не зря их включали в интервью, и точно уже не только и не столько для тестирования, как вы умеете всякие софт скиллы на них продемонстрировать, а все-таки глубоко под капотом проверяли, до какого именно уровня сложности задач вы сможете добраться на вашем текущем уровне, ИМХО.
Проходил этапы в Т-банк, на первой встрече с HR сказал, что хочу Х денег, меньше не рассматриваю, сказали что отлично, в вилке. В итоге прошел 3 секции, после каждой HR нахваливала мои результаты. Затем встреча с командой, дали добро, созваниваемся обсудить оффер и предлагают мне 0,8X. При этом уже на руках была пара офферов 1,1-1,15Х. Вот что это было? Сожгли кучу своего и моего времени (1,5+1+1+1+0,5 ч). Зато алгоритмы... Систем-дизайн... Карго-культ какой-то.
Чтобы не было таких вопросов - не называйте сумм сами, вообще..., как? - сами решайте.
Но тогда будут лезть с собесами те, которые готовы нанять за гроши. Зачем тратить время на того, кто изначально не готов платить эту сумму? И от HR на 100% никогда не услышишь вилку.
Сам назвал сумму и ясно обозначил, что меньше не рассматриваю
Жадный или ленивый HR решил, "а вдруг прокатит". Им же за найденных кандидатов не то бонусы дают, не то повышения, в общем - им выгодно, что бы на работу устроились.
Пишите жалобу кому-нибудь в компании в следующий раз, чтобы этому HR-у прилетело по голове. Если все так делать будут, эта практика исчезнет.
Хотите зарабатывать больше - не называйте сумм никогда, пусть они сами предлагают. 100%.
Можете конечно минусовать ), но полезнее - изучать математику )
Я не про алгоритмы скорее, а про трату времени. Некомпетентность HR возможна, да. Если они оценивают мой уровень меньше чем я прошу, а я категорически меньшую компенсацию не рассматриваю, то можно было бы закончить всё после второго-третьего этапа. А может они надеятся на то что я потратил на них столько времени, плюс настолько верят в силу своего бренда, что считают что я пойду на уступки... Тогда это скорее неуважение
Алгоритмы полезны так помогают сэкономить время и отсеять компании где есть такая секция.
Ещё они полезны потому что помогут гарантированно устроиться на не плохую работу, если ты сидишь без работы и восемь часов в день надр... натаскиваешь навык решения алгоритмических задач. Как в спорте качают мышцы, так и с алгоритмами - легко можно натаскаться.
Проблема в том что настоящие профи без работы не сидят и им тупо некогда надр... натаскивать навыки алгоритмов. И их хантят как правило компании попроще.
Плюс алгоритмические секции позволяют снизить ценник к дорогим спецам. Типа ты не прошел секцию, но мы готовы тебя взять за прайс ниже.
"За два месяца я решил 300+ задач, с упором на средние и сложные — других Google не спросит." - а сколько из этих 300 задач вы реально решили сами? И, позвольте спросить, а какое у вас образование? Просто решать в день по 5 задач уровня (middle/hard), это просто выглядит не реально, на мой субъективный взгляд. Конечно, может быть вы решали задачи (weak middle/ weak hard). Там, где успешных посылок +80%/100%, но даже в этом случае, это почти невыполнимая задача, ПРИ УСЛОВИИ, что у вас нет сильного технического образования, которое привило вам умение очень хорошо думать. Я уже молчу про реальное понимание всех тех техник и наблюдений (а зачастую каких-то математических фактов), которые требуют такого рода задачи. Я не нападаю, просто хочу некой ясности. Я просто часто видел статьи, где людям "всего-то" требовалось 2-3 месяца на подготовку на литкод. А это 150-200 задач. По моим наблюдениям, "среднему разработчику", даже со "средним" техническим образованием, требуется, скорее всего, 1-2 года, чтобы пришла уверенность.
У меня высшее математическое образование, но больше мне нравилась информатика и все что связано с языками (кроме алгоритмов)
Начинал я конечно с изи задач - leetcode 75/150 чтобы набраться базы. Решал я конечно не все, но все пытался понять и проработать
Когда выходишь на уровень Хард задач, то понимаешь что это все комбинации/вариации средних, редко встречается что-то уникально нерешаемое
Мне кажется, что у меня просто был хороший мотиватор в виде грядущего интервью, поэтому получилось, но срабатывает инстинкт самозванца - если я смог, то любой сможет
Спасибо за ваши уточнения.Я где-то так и полагал, что у вас, скорее всего, есть так сказать "математическое мышление", помогающее вам в решении задач.
Я думаю, что даже сильнейшая мотивация, скорее всего, НЕ поможет, человеку, если он раньше не решал "много" и не уделял достаточно времени математике или каким-то логическим задачам.
Все эти литкод паттерны упрощают сильно изучение, но только, когда у человека есть привитое умнение учиться и учиться долго. Наряду с уже схожим умением думать. А без этого, кандидат будет просто 2 месяца только "привыкать" к чтению условия задачи и пытаться понять разборы этих задач. Я уже молчу про технические затруднения в реализации этих самых идей в коде, под конкретные задачи, ну и понимание, а почему, собственно это все должно рабоотать.
Реальность, как говориться, может быть гораздо печальнее.
A по поводу нужны ли алгоритмы или нет, скажу что, когда они есть, то это не навредит, а только улучит человека.
Я склолен думать, что любой "алгоритмист", может стать разработчиком любого профиля, но не любой разработчик сможет в алгоритмы.
Еще одну более специфичную вещь выскажу, но опять же, это мое сугубо личное мнение. Я думаю если разработчик увлекается алгоритмами, то он куда более лучше может отлажививать программы. Просто потому, что читать код, держать в уме стэктрейс, графы объектов или функций вызовов - это все на фундаментальном уровне дают как раз алгоритмы и структуры данных. А отлаживание программ - это одна из самых частых задач в любом программировании.
Ребят такой сайт был, потерял и у них на видео он на секунду появляется.
Английский Сайт с топ популярными задачами которые задавали в компаниях. Там можно каждому проголосовать за 'тебя спрашивали эту задачу?', сами задачи перекидывали на leetcode. Ты мог галочки ставить какие решил и верху ещё показывался прогресс easy медиум hard в количестве для каждой сложности тира 5/100. Ещё были верху несколько фильтров.
Tl;Dr: очередной неосилятор обиженный Яндексом (haha, classic) рекламирует свой подкаст.
Потому что все хотят как в FAANG и в виду инвалидности управленцев принимается решение об оптимизации, чего есть в FAANG и чего будет в ИП Рога и Копыта. По случайному совпадению в ИП оказываются алгоритмы, непрозрачные годовое цели и вот это все, а всякие истории про оклады\мотивации\бонусы оптимизируются.
У вас есть 45 минут, чтобы оценить реальные знания интервьюируемого (а не то, про что он так красиво заливает). Алгоритмическая задача a la литкод имеет очень хорошо очерченные границы. "Реальная задача" имеет таковые только в голове интервьюера. Собеседуемый не знаком с контекстом реального проекта и передача значительной части этого контекста займет нетривиальное количество времени, а у вас 45 минут.
У меня были пройденные собеседования, где собеседующий рассказывал подходящий алгоритм и я его реализовывал после обсуждения.
Было и такое: пришел на собес, мне рассказывают, что работают и поддерживают свой форк MySQL (тут наверно уже стоило сбежать) и предлагают в качестве задачи изменить код их форка так, чтобы функция AVG возвращала удвоенное значение среднего. Я нашел, поправил, скомпилировал, проверил. Показываю. Спрашивает как я это сделал, я рассказываю, что нашел функцию, где реализован подсчет этого среднего и добавил "*2" перед возвратом. Он хлопает глазами. Я хлопаю глазами. Очевидно ожидалось что-то дополнительное, которое существовало в контексте собеседующего, но отсутствовало в моем. Собеседующий не донес, я не допытал.
Давайте, я лучше вам с литкода задачи порешаю.
Для большинства компании долины алгоритмические задачи являются простым способом отказа. (Чтобы не засудили. Всем давно известно что спокойнее не нанят хорошего кандидата чем нечаянно нанять плохого. Опять же, чтобы не засудили, придется год пипать человека чтобы просто уволить - ресурсы и деньги.
Большая часть больших компаний вам отправит задачку онлайн чтобы вы решили без участия людей, этот процесс является отсеиванием (то о чем тут пишу в коментах), очень сложно провалится если вы понимаете в программирование.
С точки зрения проверки знаний, алгоритмы были хорошей темой, когда только появились на интервью, к примеру такие простые как найти первый не повторяющиеся символ в строке. Цель была простоая пообщаться посмотреть на кандидата. Как обычно потом программисты сами себе выстрелили в ногу, появились книги типа хакнуть интервью или сервисы как литкод, что привело к невероятному росту сложности задач и их формулировок, потому что каждый второй был тут чтобы хакать интервью, а не беседовать про свой скил.
Вставлю свои пять копеек про то, как мы проводили подобные лайв-кодинги, и как мы, на мой взгляд, их улучшили
У нас это, действительно э, было больше похоже на парное программирование, кандидаты могли пользоваться всеми инструментами, поиском, stack overflow, chatgpt, мы вместе обсуждали подход к задаче и тд
И смотрели мы не на финальный результат, какая там у него сложность по памяти и времени к, а на то как подходят к проблеме и решают ее. Могло быть такое, что кандидат решавший, например 2 из 5 задач пройти на следующий этап, а кандидат решивший 4 из 5 - не пройти, просто потому что второй кандидат тупо перебирал стандартный набор вариантов (а давайте через стек, а давайте жадный подход и тд), даже не задумываясь о том почему выбирают то или иное решение
Ну и чуть позже мы вообще взяли и поменяли описание этих задач, так, что бы они были близки к нашему продукту (у нас на самом деле нередко нужно применять алгоритмы). Это сильно уменьшило «нервозность» кандидатов, когда вместо животных и геометрических форм, ты оперируешь виртуальными машинами
Есть нормальные алгоритмические задачки, которые можно использовать на собеседованиях, но к сожалению, это не особо просто продавать консалтинговым агентствам, и они требуют больше извилин и усилий от работодателя. Навскидку, класс алгоритмов по обработке данных:
Сжать картинку или текст (подсчёт повторений, отброс битов, словарь токенов/палитра). Проверяется сравнением размера. Бонус, если написал разархивацию, автоматом тоже можно проверить.
Сжатие картины с потерями (усредненная палитра, wavelet transform - знаю, что звучит страшно, но сам алгоритм тривиальный, до него можно додуматься с нуля). Автоматом тяжелее проверить, но есть соответствующие алгоритмы.
Шифрование данных (сжатие, подмена типа шифр цезаря, ротации, перевод в другую систему счисления, даже base64). Бонус за ассиметричное шифрование (нужна математика, но можно помочь, если ее описать заранее; причем даже зная математику, кандидаты испытывают трудности написать тот же RSA). Если говорить про RSA, то там нужен BigInteger, так что будет ещё лучше если кандидат такое напишет сам, а не просто воспользуется готовым или будет полагаться на ЯП (как Python с неограниченноой арифметикой).
То же самое, что выше, но потоковый вариант.
Бесполезная трата времени сидеть и решать алго задачи. Если требуют решить какую-то говно-задачу на собесе, то завершаешь диалог и прощаешься.
Очередная статья про "бесполезность" алгоритмов. Постоянно пригождается. А на последних двух вполне обычных проектах так и вовсе графовые задачи пришлось решать. И это не были даже высоконагруженные системы. Причём несколько раз помогал сотрудникам решать эффективно и нормальный алгоритм не просто давал колоссальный эффект, но был короче в разы лобового решения. В некоторых случаях знание алгоритма помогало избегать подключения библиотеки для костыля.
За свои 15 лет опыта могу сказать, что как раз таки раньше алгоритмы были синонимом программирования. Раньше спрашивали алгоритмы гораздо чаще. Сейчас же наоборот - век фреймворкового программирования и секция алгоритмов стала нишевой только для больших мегакомпаний, где осталась культура мат базы. Незнание алгоритмов порождает неспособность идентифицировать проблему как задачу дискретной математики. Отсюда и вытекает недоумение "алгоритмы же не пригождаются". А как они пригодятся если не владеешь ими и не можешь идентифицировать задачу математически в мире построенном на цифрах?
Статьи о ненужности алгоритмов вылетают как из автоматной очереди, пора бы для разнообразия отличную точку зрения публиковать, а то уже что-то утомительно читать все эти стенания.
Пользуясь случаем, хочу кинуть камень в огород Тинькофф.
Я очень хотел попасть в Тинькофф на DevOps мидл позицию, но года два назад, там был этап м алгоритмами и я всегда его проваливал, потому что не хочу их учить, ввиду того, что не понимаю, зачем алгоритмы DevOps инженеру нужно знать.
В последний раз, когда я приходил к ним на собеседование, у них появилось два этапа по алгоритмам и первый идёт в качестве скрининга. Дают 45 минут и код обязательно должен работать. Делаешь без надзирателя в любое удобное время, в течении недели.
Вот что они узнают о навыках девопса при таком подходе?
В общем я тоже обижен теперь, как говорит автор :(
По факту все алгоритмы можно заботать и если есть понимание как они работают, то пройдешь любой собес. Вот например если дать на собесе задачу написать какой-нибудь +- сложный sql запрос исходя из бизнес требований, то это может показать как реально человек может работать
У меня взгляд за английский зацепился. Извините, если не очень в тему. Почти у всех авторов статей и комментирующих по делу уже есть знание на уровне достаточном для собеседования в FAANG (С1?). Вот вы рождаетесь что ли уже с эти умением, или в школе настолько хорошо учите? А если нет - как это прокачивается, на него же тонна времени нужна. Я по полчаса каждый день уделяю уже год или еле сдвинулась с B1 в сторону В2 (далеко ещё). И я это к тому, как уместить всё в одну жизнь. И язык, и подтягивание тех.скилов для работы, и алгоритмы специально для собеседований.
Алгоритмы — самый провальный этап собеседований