Эта тема многократно поднимается в сообществах разработчиков, есть те кто поддерживает данный вид собеседований и те кто против. Вот и я, рискуя быть раскритикован сообществом, решил высказаться :)
Признаюсь, сам длительное время не был сторонником данного вида собеседований, мне казалось, что классический подход лучше, когда тебя, ну или ты собеседуешь кандидата проходя от азов до углубленных знаний.
Объективно, где мы используем в работе алгоритмы?
Возможно у кого-то в проекте есть ручное написание сортировок или обходы графов, но как правило разработчики используют стандартные или дополнительные библиотеки, которые закрывают подобные потребности.
Однако, все изменилось в один день) мне потребовалось подобрать пару-тройку разработчиков в команду, и проводя пятое или шестое собеседование мне попался кандидат, который идеально отвечал на все теоретические вопросы (базовые и не очень), однако переходя от темы к теме меня все больше настораживал легкий звук, прибавив громкость наушников я услышал аккуратный шелест листочков....
Получив простейшую задачку с LeetCode на работу с массивом кандидат мгновенно "сдулся", при этом я не просил решения, я попросил просто вслух рассуждать как обойти массив, какую структуру данных выбрать для промежуточного хранения.
Аналогичная ситуация повторилась и дальше, только кандидат кликал мышкой.
Наверняка Вы скажите, что нужно задавать нестандартные вопросы или просить примеры из практики по проекту - это верно в случае, если подбираем middle и выше, а если нужен junior+ или middle-?
На мой взгляд польза от простых алгоритмических задач - кандидат может показать свое мышление и простейшее отличие и необходимость использования в работе HashMap и ArrayList.
Конечно, чтобы решать алгоритмические задачи нужна отдельная, специальная подготовка, которая зачастую не особо потребуется в работе, однако, знание простых алгоритмов позволит раскрыть истинное знание кандидата.
Для себя я выделил плюсы и минусы умения решать алгоритмические задачи:
Плюсы:
Оценка навыков решения проблем: Алгоритмические собеседования позволяют оценить навыки кандидата в области решения различных задач и проблем. Это может помочь определить, насколько кандидат хорошо разбирается в структурах данных.
Объективная оценка: В отличие от некоторых других видов собеседований, где оценка кандидата может быть субъективной, алгоритмические собеседования обычно предоставляют более объективные критерии оценки. Результаты основаны на том, насколько хорошо кандидат решает задачи, а не на личных предпочтениях интервьюера.
Проверка навыков быстрого мышления: Алгоритмические собеседования проверяют способность кандидата быстро мыслить и придумывать эффективные решения для сложных задач. Это важный аспект работы в области разработки программного обеспечения.
Минусы:
Не всегда отражает реальную работу: В реальной жизни разработчики редко сталкиваются с задачами, аналогичными тем, что предлагаются на алгоритмических собеседованиях. Поэтому успешное прохождение таких собеседований не всегда гарантирует хорошую производительность на рабочем месте.
Могут быть стрессовыми: Для некоторых кандидатов алгоритмические собеседования могут быть очень стрессовыми, особенно если они не имеют достаточного опыта или не уверены в своих навыках решения алгоритмических задач.
Ограничивает разнообразие кандидатов: Некоторые талантливые кандидаты, которые могли бы быть отличными разработчиками, могут отсеяться из-за недостаточного опыта в решении алгоритмических задач или низкой скорости мышления.
Подводя итог: Алгоритмы нужны и теперь я использую их в своих собеседованиях, но нужны без фанатизма, на примере задач чтобы порассуждать с кандидатом и понять его уровень владения базовыми знаниями.
Комментарии (115)
konst90
08.04.2024 06:53+27Дав простейшую задачку с LeetCode на работу с массивом кандидат мгновенно "сдулся"
Проезжая мимо станции, у меня слетела шляпа
Timyrlan
08.04.2024 06:53Спасибо за статью, попробую покритиковать)
Ваше решение - это ответ на конкретный кейс, когда соискатель накидал шпаргалок. Т. Е. вы предлагаете целое собеседование дополнительное ради решения только одной конкретной проблемы. В разработке это называется костыль)
Я пришёл к мысли от необходимости алгоритмического собеседования, когда раз за разом в команде сталкивался с тем, что люди не думают об алгоритмической сложности своего кода. Например, человек (очень неглупый) берёт массив пользователей из (10к) и для каждой записи делает отдельный запрос к БД. И таких проходов по массиву пользователей - N в секунду. БД ложилась под нагрузкой, хотя тяжёлых запросов не было. И таких кейсов много.
-
Если бы я проводил алгоритмические собеседования, не нанял бы человека (см выше). А этот человек реально тащит.
Сделал для себя вывод: алгоритмические собеседования это хорошо, если можешь себе это позволить. Я вот не могу
friend001002
08.04.2024 06:53+8"Если бы я проводил алгоритмические собеседования, не нанял бы человека (см выше). А этот человек реально тащит."
Это как? Если он делает без надобности столько запросов к БД, то как он может тащить? А если он тащит, то как он может без надобности делать столько запросов к БД? Если имелось ввиду, что он тащит в каких-то других аспектах, тогда ладно.
michael_v89
08.04.2024 06:53+5Например, человек берёт массив пользователей из (10к) и для каждой записи делает отдельный запрос к БД.
К тому, что называют знанием алгоритмов, это не имеет никакого отношения.
mayorovp
08.04.2024 06:53+1Но сильно коррелирует. Если, конечно же, программист алгоритмы умеет составлять, а не просто вызубрил.
michael_v89
08.04.2024 06:53Ну судя по тому, что обычно говорят, как раз наоборот, алгоритмы он выучил, а о таких вещах не задумывается. Сложность цикла O(N) в обоих случаях. А не делать ресурсоемкие операции в цикле нас учили еще в университете без всякой связи с алгоритмами.
mayorovp
08.04.2024 06:53Сложность сложностью, но писать алгоритм и не задумываться о стоимости каждой операции очень странно.
Sulerad
08.04.2024 06:53Ну там O(N) по операциям с памятью как ни крути и сверху либо O(1), либо O(N) по запросам к БД. Тут сразу ясно что лучше =)
Как-то в университете была лаба, где как раз сравнивались алгоритмы сортировки на предмет количества сравнений/свопов/памяти и приходили к интересным выводам (если надо посортить книги человеку руками, то внезапно каждый своп оказывается очень дорогим)
wl2776
08.04.2024 06:53+1Один и тот же человек из раза в раз повторяет одну и ту же ошибку? Или это разные люди? Если один и тот же, то откуда характеристика "очень неглупый"?
А пробовали над проблемой работать? Например, лекцию прочесть, порешать олимпиадные задачки?Timyrlan
08.04.2024 06:53Нет, не один и тот же) Каждому человеку достаточно один раз дать линейкой по рукам. Но на проекте у меня 8 бекеров, и если каждый сделает каждую ошибку... привет декартово произведение
Про лекции думал, но алгоритмическое мышление лекциями не достигается, думаю. Пока пришли к перекрестному кодревью перед моим кодревью, помогает большую часть вопросов снимать
wl2776
08.04.2024 06:53Людям свойственно ошибаться, а команду надо развивать (привет, Кэп!). Это Ваша обязанность как тимлида - развивать своих людей и исправлять их ошибки.
В моей прошлой конторе периодически устраивали по субботам сеансы решения олимпиадных задач. Раз в пару недель, одна задача на 4 часа. Решивший получал гордое звание "Профессиональный программист", небольшую премию и компенсацию сверхурочной работы по закону ($$ или время отпуска). Нерешивший - только компенсацию сверхурочных, без звания и премии :). В целом, я на себе ощутил эффект, кое-какие навыки улучшились :)
serjeant
08.04.2024 06:53+14А почему вы не смотрите в сторону задач по разбору и поиску ошибок в коде? Это же ближе к практике и тому чем человеку придется на работе за ниматься.
Mrchoozy
08.04.2024 06:53Нормальный современный подход к собесу, это взять баг из джиры, вырвать его из контекста и предложить кардидату порассуждать как это решить.
П.с. узнал тебя по аватарке.
maxzh83
08.04.2024 06:53+2как правило разработчики используют стандартные или дополнительные библиотеки, которые закрывают подобные потребности
И правильно делают. За редким исключением, это лучший вариант.
я услышал аккуратный шелест листочков
Вместо задачек с LeetCode можно просто спросить в контексте того, чем человек занимался до этого и порассуждать о чем-то. Типа писал запросы к БД, можно спросить как можно было ускорить и т.д. Человеку в стрессовой ситуации (а собеседование это почти всегда стресс) на знакомую тему рассуждать заметно проще.
AndreySitaev
08.04.2024 06:53+3В среде соискателей под овечей шкурой простоватых мидлов прячется стая волков-вкатывальщиков. Их конек - выдуманные / подслушанные и зазубренные процессы и кейсы из их "опыта работы". В тч по методологии STAR (Situation - ошибка 504, ..., Resolution - оптимизировал запрос).
maxzh83
08.04.2024 06:53Таким ребятам ничего не стоит запомнить пару десятков задач с leetCode.
Их конек - выдуманные / подслушанные и зазубренные процессы и кейсы
В целом, нет никакой проблемы в том, что кейсы выдуманные. Вы все равно спросите то, что интересно вам, просто в контексте истории. Дальше попросите поразмышлять в нужную для вашего проекта сторону.
AndreySitaev
08.04.2024 06:53+2Таким ребятам ничего не стоит запомнить пару десятков задач с leetCode.
Ничего, что на сайте 3108 задач?
Несмотря на то, что многие (далеко не все) задачи основаны на ограниченном подмножестве алгоритмов (типа "два указателя"), нужен ВЫДАЮЩИЙСЯ талант к абстракции и алгоритмизации, чтобы "запомнить пару десятков задач" с leetCode, и потом решить одну / две задачи "Medium" из пула в 2000+ задач.
doctorw
08.04.2024 06:53Я думаю, те кто даёт задачи с leetcode, выбирают их не случайным образом, а ориентируется на какие-то критерии, вроде топ-N задач на тему X. Вызубрить первые M <= N решений задач по сильно ограниченному набору тем, существенно проще, чем вызубрить всё.
AndreySitaev
08.04.2024 06:53+1Я с вами категорически не согласен.
на сайте есть фильтры + кнопочка Pick One - это для супер-ленивых собеседующих. Как ни крути, выборка будет из нескольких сотен задач, минимум
что если собеседует не вкрай обленившийся сотрудник?
Вы можете "вызубрить" хотя бы 200 задач? Вы - уникум! Напомню, основная масса задач - не детский сад вида "определить, является ли строка палиндромом".
Abbadosha
08.04.2024 06:53Адепт алгоритмических собеседований детектед. В целом какой-нибудь вайтишник может посидеть пару месяцев потыкав в тот же leet по вечерам и уже существенно повысить вероятность прохождения собеса.
Сделает ли его это нормальным разрабом? Не знаю.
iboltaev
08.04.2024 06:53+1Ни разу еще такого вайтишника не видел. Но если вайтишник прорешает хотя бы сотку задач, в т.ч. пару десятков медиум, то он уже не такой уж и вайтишник.
У меня из опыта работы есть куча кейсов, когда казалось бы мидлы, а то и синьоры разрабы не знали про хэшмапу
Pardych
08.04.2024 06:53+7Алгосы - такая же зубрежка как все остальное.
AndreySitaev
08.04.2024 06:53+2Нет
Pardych
08.04.2024 06:53+8Неуча ответ. Вы видимо мало учили алгосов и структур, например не учили их в институте. Они точно так же там сдавались ПО БИЛЕТАМ на которые мы писали ШПАРГАЛКИ. Ей-богу, детский сад.
AndreySitaev
08.04.2024 06:53+4Речь идет об алгособесы, а не конкретно те алгоритмы, что вам давали в ВУЗе. Фиг вы что зазубрите так, чтобы решить случайно взятую задачу с приличной вероятностью.
Задачи не сводятся к воспроизведению "типового" алгоритма. В некоторых случаях "типового" алгоритма в чистом виде не существует - пример - DP. А задач этих - тысячи.
Pardych
08.04.2024 06:53+3И какой мистический навык, скажите-ка мне, нужно соискателю развить чтобы сходу на собесе решить задачу из неизвестного ему раздела? Скажем он знаком с бинарными поисковыми деревьями и не знаком с задачами на циклических графах. Или все-таки ему придется пойти и изучить типовые обходы, проблематику и область применения, чтобы хотя бы знать в какую сторону копать? Что это как не зубрежка? ДП как раз пример типового подхода который надо именно что знать.
AndreySitaev
08.04.2024 06:53+4И какой мистический навык, скажите-ка мне, нужно соискателю развить чтобы сходу на собесе решить задачу из неизвестного ему раздела?
Это решает для себя автор поста, я не комментирую ценность алго-собеса.
типовые обходы, проблематику и область применения, чтобы хотя бы знать в какую сторону копать? Что это как не зубрежка
Это не "зубрежка". Зубрежка - это запомнить пять параграфов текста из учебника истории, например. Банально, просмотром и "заучиванием" - хотя бы и 1000 - решений задач подобного рода необходимый навык не получить. Решать, в конечном итоге, придется самостоятельно.
А вот, скажем, решить 10 задач из учебника математики - это не "зубрежка". Это именно что творческий поиск решения, основанный на знании ряда подходов, продемонстрированных на примерах.
То, как кандидат решает подобные задачи, может продемонстрировать его способности к абстракции, приоритезации, определению граничных условий, отладки на них и т.п. Если эти навыки появились в результате "зазубривания" (я сомневаюсь, что такое возможно) - уже неплохо.
Pardych
08.04.2024 06:53+2Я тоже не комментирую ценность. Её комментировать бесполезно в виду различия предметных областей у прикладного ПО. Кому-то необходимо считать установившееся напряжение в электросети, кому-то крудошлепать.
У вас походу чисто терминологическая претензия к "зубрежке". Она по-вашему не сопровождается разбором теории и практическими занятиями. Но это далеко не так. Вы изучаете раздел с алгоритмами на тех же графах или, я не знаю там, вычислительные методы решения системы дифференциальных уравнений. Читаете теорию, решаете задачи. Со временем из памяти без применения оно выветривается и вы идете и повторяете все это в более сжатом виде (потому что досканально повторять все - долго), попутно вспоминая что и зачем. И вот тут механизм аналогичен зазубриванию, не конкретных, естественно, задач, а теории раздела.
Без этой систематики просто открыть учебник и решить десять рандомных задач - просто глупость. Во-первых при достаточной сложности задач это у вас не получится без теории или подглядывания в решение, а во-вторых у этого процесса как у самурая - нет цели, только путь.
То как кандидат решает подобные задачи показывает его знание самого раздела алгоритмов и структур: теории, основных подходов и проблематики.
Опять же, это не оценочная, а целеполагательная поправка. Вы утверждаете что можно проверить абстрактный навык абстрагировать, приоретизировать, оценивать краевых и т.п на алгоритмах. Я утверждаю что алгоритмической задачей можно проэкзаменовать на знание раздела теории алгоритмов и на практические навыки применения этого раздела теории в первую очередь.
Часть навыков (оценка краевых) будет действительно наработанным общим для всех разделов. Тут кстати смешной момент. Сталкивался с тем что с ней на собесе и у собеседующего не всегда хорошо. Скажем любящие спрашивать на собесе даже такую бесхитростную вещь как RLE не всегда готовы к алгоритму не нуждающемуся в явной проверке краевых условий. Даже если им объяснили почему так. Хотя казалось бы задача максимально простая, пишется за 5 минут и благоволит тому чтобы по-быстрому все аспекты выяснить.
AndreySitaev
08.04.2024 06:53алгоритмической задачей можно проэкзаменовать на знание раздела теории алгоритмов и на практические навыки применения этого раздела теории в первую очередь.
Я бы дополнил - и наличие способностей решать задачи, требующие умения оперировать абстракциями. Сейчас в IT пытаются вкатиться в тч те, кого иные пренебрежительно называют "гуманитариями" - вот такие кадры, вероятней всего, при всем желании собеседование по алгоритмам a-la leetCode не пройдут.
Еще раз - на всякий случай - подчеркну, что я не считаю решение задач с leetCode обязательным этапом собеседования разработчика. Я бы предложил иной формат.
sdramare
08.04.2024 06:53+1Никакой не нужно развивать. Алгособесы это буквально тестирование вашего умение решать незнакомые задачи, что зависит от ваших природных качеств. Примерно в той же плоскости что тест IQ.
Pardych
08.04.2024 06:53Интересное мнение. Но нет, ни IQ ни алгосы - не черепомерка, а задачи на приобретаемые навыки. От природы вы ни читать, ни писать, ни говорить не умели.
sdramare
08.04.2024 06:53+1Причем тут писать и читать? Какая еще "черепомерка"? Почитайте что такое G-Factor, что такое fluid intelligence и чем он отличается от crystallized intelligence и заодно что такое шкала бине и как из нее был разработан тест IQ. Почитайте хоть что-нибудь по данной теме и тогда вы сами поймете что показывает умение решать незнакомые алгоритмические задачи и почему данный вид тестов активно используется в процесса отбора в крупных ΙΤ компаниях.
Pardych
08.04.2024 06:53> что показывает умение решать незнакомые алгоритмические задачи
то что они вам незнакомы
в крупные компании таки ищутся те кому они знакомы
а IQ-тест и вся вышеперечисленная лабуда себя скомпрометировали задолго до конца прошлого века
sdramare
08.04.2024 06:53а IQ-тест и вся вышеперечисленная лабуда себя скомпрометировали задолго до конца прошлого векаШариков.jpeg
Pardych
08.04.2024 06:53"Щас неизвестную алгоритмическую задачу без подготовки решу, в гугол возьмут, и миллион денег дадут" - вот Шариков.жпг
sdramare
08.04.2024 06:53на хабре буквально был пост от сотрудника гугла, который объясняет зачем они дают алгоритмы на собеседовании, почитайте - https://habr.com/ru/articles/779512/
Pardych
08.04.2024 06:53Слушайте, я довольно долго общаюсь с сотрудниками некоторых из этих компаний. Про найм наслышан не вот с этих вот восторженных статеек на хабре, а тсзть из первых рук. Во-первых идеология найма транслируемая в медиа абсолютно не то же что реальное положение вещей с ним. Во-вторых все эти ребята натасканы на собесы как питбули и каждый имеет за плечами приличный вуз, годы подготовки, опыт работы в весьма успешных продуктах компаний поменьше и личный бренд за счет выступлений на международных конференциях (что кстати тоже требует большой аналитической работы). У них спорт такой - собесы проходить. Они и там тренируются. В-третьих - никакой самородок не проскочит даже первого фильтра за счет каких-то невнятных флюид интеллидженс, теорию знать надо и как она на практике применяется - тоже, настолько хорошо что смежные области тоже не проблема. И по дизайну и по алгосам и по структурам. Оно работает накопительно - чем больше вам знакомо, тем проще вам будет разобраться с незнакомым.
А вы развели какой-то псевдонаучный карго-культ с провальными теориями прошлого века и "столярное дело по-испански" с оценкой неоценимого природного дара, которого не бывает.
JekaMas
08.04.2024 06:53Почему бы тогда не дать задачу на органический синтез?
sdramare
08.04.2024 06:53+2Потому что задача на органический синтез проверяет ваш crystallized intelligence, насколько хорошо вы можете запомнить и повторить информацию. А алгоритмическая задача проверяет ваш fluid intelligence, насколько вы хорошо можете найти решение незнакомой для вас задачи, используя логику, умение находить паттерны и скорость мышления. Заучивание алгоритмов от вас не требуется, более того, если собеседующий видит что вы данную задачу уже знаете как решать("это я помню, тут надо в стек все сложить"), то он сменит задание или добавит условия, чтобы задача была для вас не знакомой.
Tony-Sol
08.04.2024 06:53+1Кмк вы оба правы, просто немного о разном говорите: кажется fluid и crystallized не существуют в отрыве друг от друга. Так, например чтобы успешно решать алгозадачи на собесах, нужен и fluid, чтобы понять на что задача похожа из того, что уже знаешь и собственно сам багаж знаний и умений - crystallized, который как раз зазубривается.
Т.е. решаем (задрачиваем) условные 100500 зачад на списки/массивы/работу с указателями с литкода - тем самым и зазубриваем варианты решения = формируем crystallized intelligence, и научаемся сходу определять «а о чем конкретно эта задача» = формируем fluid intelligence.
michael_v89
08.04.2024 06:53Mergesort появилась в 1945 году, Quicksort в 1960, а Timsort в 2002. До Timsort за 42 года никто не догадался, почему вдруг обычный человек, который не знаком с этой сортировкой, должен сделать это за время собеседования?
sdramare
08.04.2024 06:53+2Он и не должен, собеседование это не экзамен в школе - оценивается как вы будете искать решение, насколько сложно вам будет делать логические переходы, сколько времени у вас это займет.
michael_v89
08.04.2024 06:53Ну вы сказали "умение решать", то есть не решил значит не умеет. В задачах на алгоритмы искать обычно нечего, либо догадался, либо нет. Даже если разбить Timsort на 10 шагов, то на 1 шаг можно ожидать примерно 4.2 года, это сильно больше времени на собеседование.
Любое программирование это умение решать незнакомые задачи, алгоритмы тут ничем не отличаются.
sdramare
08.04.2024 06:53+1не знаю как у вас это происходит, но обычно у человека решение задачи не происходит как "пустота-пустота-о, догадался и решил". Человек рассуждает, анализирует, пробует один подход, другой, исправляет свою ошибку - именно это и хочется увидеть, это те навыки, которые используются про программировании. Конечно это не нужно во всех компаниях, есть проекты, где надо просто клепать crud, а любой вопрос решает копированием ответа со стек оверфлоу - в этом случае да, процесс поиска надо строить по-другому.
michael_v89
08.04.2024 06:53Да, только при обычной работе это происходит в спокойной обстановке и занимает часы и десятки минут. А вы ожидаете того же результата за время в 10 раз меньше и с отвлечением внимания. Сделать это можно только если что-то знать заранее, а значит и разговора нет про умение решать незнакомые задачи.
sdramare
08.04.2024 06:53+1Так в этом и есть часть измерения. Вот смотрите - одному человеку чтобы научиться базовой игре на гитаре 3 аккордами нужен день, а другом неделя. И не смотря на одинаковый конечный результат, мы можем сделать вывод что у первому изначально лучше музыкальные способности. Так и тут - да, у одно человека нахождение решения займет 40 минут, а у другого несколько часов, люди не одинаковые, именно это тест и показывает.
ptr128
08.04.2024 06:53одному человеку чтобы научиться базовой игре на гитаре 3 аккордами нужен день, а другом неделя. И не смотря на одинаковый конечный результат, мы можем сделать вывод что у первому изначально лучше музыкальные способности.
Не можем. У меня сын на первых занятиях на гитаре преподавателя достал, так как показываемые аккорды воспринимал, как на занятиях по сольфеджио, полностью их разбирая. Только через неделю преподаватель осознал, что учить игре на гитаре парня с музыкальным образованием по фоно надо совсем иначе, чем начинающего.
Именно поэтому на собеседовании мне ход мыслей кандидата намного интересней, чем решит или не решит он поставленную задачу за ограниченное время.
michael_v89
08.04.2024 06:53мы можем сделать вывод что у первому изначально лучше музыкальные способности
Ну так о том и речь, что не можем. Может быть так, что хотя бы 1-2 аккорда он знал заранее, а другой человек не знал.
AndreySitaev
08.04.2024 06:53Я соглашусь с @michael_v89:
IMHO, задачи leetCode хорошо поддадутся уму чуть выше среднего, перерешавшего несколько сотен подобных задач
либо - выдающемуся интеллекту, специально подобные задачи не решавшему.
Вот пример: https://leetcode.com/problems/maximum-gap/description/
Задача уровня Medium. Таких за час надо решить две.Положим, вы не слышали про алгоритм Pigeonhole sort. Решили бы вы такую задачу?
sdramare
08.04.2024 06:53Решили бы вы такую задачу?Не знаю, скорее всего, вопрос только во времени. Как минимум как наивное решение, которое сразу в голову приходит, это радиальная сортировка и прямой поиск - алгоритм будет иметь линейное время. Но наверное есть решение и получше, раз вы про Pigeonhole sort пишите.
AndreySitaev
08.04.2024 06:53Pigeonhole sort - то же, что и блочная сортировка. Думаю, разница между этими алгоритмами - в контексте задачи - не существенна. В любом случае, если соискателю незнаком ни один из этих алгоритмов (pigeonhole / radix), маловероятно, что он решит задачу.
P.S. В моем университетском курсе ни одного из упомянутых алгоритмов не было.
sdramare
08.04.2024 06:53Я соглашусь что конкретно эта задача не самая лучшая. Так же как например поиск цикла в связанном списке https://leetcode.com/problems/linked-list-cycle/ Мне порой сложно оценивать, потому что у меня в универе все это было еще на первых курсах, но наличие нескольких не самых хороших задач не опровергают сам метод, это остается на совести собеседующего.
wataru
08.04.2024 06:53И не должен. Продвинутые алгоритмы никто и не спрашивает. И сортировки писать обычно не просят. Благо вы знаете, что вот есть сортировка, работающая за O(n log n) и что она в вашем языке, допустим std::sort называется.
Более того, и оптимизацию по константе никто не ждет. Придумали вы какой-то алгоритм за O(n log n), никто не будет ждать от вас какие-нибудь эвристики, укоряющие его на 20% в половине случаев.
michael_v89
08.04.2024 06:53Было утверждение "тестирование вашего умения решать незнакомые задачи". Это означает, что человек не знает алгоритм, но может догадаться, как его написать. Неважно, весь или какую-то часть. Если не написал, значит не решил. Это единственное, чем задачи на алгоритмы отличаются от обычного программирования, которое тоже показывает умение решать незнакомые задачи. Любая программа решает какую-то задачу, и можно найти незнакомые для конкретного человека без привлечения алгоритмической сложности.
wataru
08.04.2024 06:53Это означает, что человек не знает алгоритм, но может догадаться, как его написать.
Нет, это значает, что человек может догадаться, какой алгоритм тут применить, какую структуру данных впендюрить.
michael_v89
08.04.2024 06:53"Догадаться, какой алгоритм тут применить" означает, что человек его заранее знает, а речь была о том, что это решение незнакомой задачи и зависит от природных качеств.
wataru
08.04.2024 06:53Ну, например, человек скорее всего знает про жадные алгоритмы и видел в других задачах, что можно отсортировать данные по какому-то параметру и такой порядок будет оптимален.
И вот в новой, никогда до этого невиданной им задаче, ему приходится догадаться, как заданные параметры скомбинировать, чтобы получить характеристуку, по которой можно отсортировать и применить жадность.
Никто ни на каких интервью не ожидает, что кандидат придумает новый алгоритм. Ждут декомпозицию задачи, построение модели, выбор применимых алгоритмов и их применение.
michael_v89
08.04.2024 06:53выбор применимых алгоритмов
Это зависит не от природных качеств, а от знания их заранее. Раз было утверждение про природные качества и указание именно на алгоритмические задачи, значит подразумевалось именно придумывание алгоритма самому с помощью природных качеств. А со знанием заранее это не отличается от обычного программирования, в этом случае использовать именно задачи на алгоритмы нет никаких причин.
wataru
08.04.2024 06:53Мало знать список алгоритмов. Надо их понимать и уметь строить модель задачи. Именно вот этот навык расковыривания задачи и применения к ней имеющихся орудий - очень ценен для программистов, ибо, если вы что-то хоть чуть-чуть сложнее формошлепства делаете, вам надо постоянно "решать задачу". И это дано не всем.
Да, это можно проверять не обязательно алгоритмическими задачками, но это самый простой, формализуемый, помехоустойчивый и масштабируемый способ. И к тому же более менее релевантный, ибо иногда все-таки понадобятся в работе алгоритмы и структуры данных. Вообще, программисты все вермя пишут алгоритмы, по определению, ведь любая программа - алгоритм. Не настолько хитрые и умные большую часть вермени, но все же.
Плюс, за время решения этой задачи кандидат, таки, должен будет хоть 10 строк кода и написать. Вы же программиста код писать ищите - так что надо обязательно убедится, что кандидат может свои мысли в код перевести а не только случайным образом код менять, пока не заработает.
Тут, правда, есть относительно высокий процент ложно-отрицательных результатов, т.ч. если у вас вакансия уже пол года висит и уже вчера хоть кого-нибудь взять, то возможно вам лучше подойдет какой-то другой способ.
michael_v89
08.04.2024 06:53Мало знать список алгоритмов. Надо их понимать и уметь строить модель задачи.
Я именно об этом и говорю. Мало знать список библиотек, надо их понимать и уметь строить модель задачи. Мало знать список фреймворков, надо их понимать и уметь строить модель задачи. Никаких отличий.
А изначальное утверждение указывало на отличие алгоритмов от этих вариантов, и было явное указание на незнакомство. То, о чем вы говорите, может быть и верно, но к изначальному утверждению не относится.Вы же программиста код писать ищите - так что надо обязательно убедится, что кандидат может свои мысли в код перевести
Я именно об этом и говорю, для этого подойдет любой код, а не только алгоритмы. А указание было на принципиальное отличие алгоритмов.
И к тому же более менее релевантный, ибо иногда понадобятся
"Более менее релевантный" это когда "более менее часто", а не иногда. Если "иногда", то и способ "иногда релевантный". Что у вас более менее часто встречается, то и надо проверять.
это самый простой, формализуемый, помехоустойчивый и масштабируемый способ
Нет, самый простой и все остальное - это писать обычный код, который встречается в обычных задачах, и который не требует знания редко используемых фактов.
wataru
08.04.2024 06:53Мало знать список фреймворков, надо их понимать и уметь строить модель задачи
И где там модель задачи? Что за задача вообще?
Я именно об этом и говорю, для этого подойдет любой код, а не только алгоритмы.
Да, вот только какой? FizzBuzz? Задачу с прода не предлагайте - как только вы начнете ее абстрагировать, чтобы не объяснять кандидату весь контекст целый час, то у вас получится easy с литкода.
самый простой и все остальное - это писать обычный код, который встречается в обычных задачах,
И... вы получаете или easy задачи с литкода, или домашние задания, которые состоят из килострок бройлерплейта. Первое принципиально от алгоритмических задачек ничем не отличается, кроме выкрученного в ноль уровня сложности, а второе очень сложно сочинять, проверять и легко считерить.
michael_v89
08.04.2024 06:53И где там модель задачи? Что за задача вообще?
Там же, где и в применении алгоритмов для решения задачи.
Задача аналогична задаче на применение алгоритмов для ее решения. Только тут будет применение фреймворков и библиотек.Да, вот только какой?
У меня был не один десяток тестовых заданий с таким кодом. Если вы не можете придумать, то это вопрос к вашей квалификации.
Первое принципиально от алгоритмических задачек ничем не отличается
Отличается тем, что инструменты для решения задачи кандидату знакомы, и ему не надо изобретать новый инструмент за 10 минут. Я несколько раз уже про это написал.
второе очень сложно сочинять, проверять и легко считерить
Да прекрасно все сочиняется. Например, берем 3 эндпойнта, один на получение данных с фильтром, два на изменение, копируем всю логику в контроллер без разделения на методы, называем несколько переменных непонятно, вносим ошибку в логику, просим кандидата переписать нормально. Можно дать код для знакомства заранее, а задачу на собеседовании.
AndreySitaev
08.04.2024 06:53Продвинутые алгоритмы никто и не спрашивает. И сортировки писать обычно не просят
А вы - ну или какой-нибудь мозговитый кандидат - не потративший год на дриллинг подобных задач - решили бы эту задачу:
https://leetcode.com/problems/kth-largest-element-in-an-array/description/
не зная алгоритма Fast Select?
friend001002
08.04.2024 06:53А зачем её решать? Если я вижу, что кандидат думает в правильном направлении и может со временем написать нечто правильное и не слишком вычислительно затратное, то я и не буду требовать полного решения задачи.
wataru
08.04.2024 06:53Не за линию, конечно, а за O(n log k) кучей запросто. Когда-то давно, пока эта задача не стала баянистой, я ее даже пару раз в гугле спрашивал. И любое решение быстрее "отсортировать, взять k-ый" принималось.
wataru
08.04.2024 06:53+3Тоже несогласен. Зубрежка, это если вы кокретные задачи выучили, с кодами решения и ключевыми словами в объяснении. Если вы выучили 5-6 подходов, то это не зубрежка. Это понимание темы. Ибо вы абстрагируете подходы от задач. Вы научиваитесь комбинировать эти подходы, применять их части там где они нужны. Без этих навыков, простой зубрежкой вы не сможете лишь с очень маленькой вероятность решить задчу почти точно идентичную одной из нескольких выученных.
Pardych
08.04.2024 06:53+1А когда у вас 56 разделов и на каждый 5-6 подходов то это уже опять зубрежка. Вот как-то так. Потому что вы не сможете это держать в голове вечно, вам потребуется для этого какой-то конспект, который вы будете время от времени механически повторять.
wataru
08.04.2024 06:53+1Но их не 56. Нигде не справшивают всякие заумные вещи вроде максимальных потоков, паросочетаний или мостов в графе.
Примечание
А если и спрашивают, то не хотят от кандидата заумных алгоритмов. А додуматься, что мосты в графе можно поискать по определению, удаляя ребра по одному и считая компоненты связности баянистым поиском в глубину - это применение уже известных подходов.
5-6 алгоритмов и столько же структур данных надо понять и вот вы покрыли 95% всех задач с собеседований.
Pardych
08.04.2024 06:53+1Ну окей. Сдаюсь. Термин выбран неудачно, а с 56 я пытаюсь реабилитирвоаться за неудачно выбранный термин. Сам всегда говорил что сижу зубрю, но это было именно попыткой разобраться. Повторять, разбираясь заново в том что когда-то знал, но забыл, для меня такая же унылая и бессмысленная затея как зубрежка. Но это субъективное моё, так что возражения по поводу зубрежки принимаю.
Вопрос про полезность экзамена на эти "часто попадающиеся на собесах задачи" оставим за скобками. Таки я алгосы учил и математику учил и хоть и не люблю проходить алгоритмические секции и сам никогда их не даю на собесах, но некоторых коллег (не мною нанятых) я бы туда воткнул носом и держал бы пока они не перестали писать тот ужас что они пишут. Так что тут одного мнения даже среди одного меня нет.
starik-2005
08.04.2024 06:53+1В работе больше нужны навыки того самого листания/кликания, чтобы найти нужный ответ. Умеешь находить ответ - уже джун, ну, конечно, если ответом способен воспользоваться. Когда ты находишь достаточное количество ответов, то через какое-то время начинаешь отвечать сам. Вот тогда становишься мидлом, ну и учишься отличать плохой ответ от хорошего. А еще через какое-то время начинаешь отличать мидлов от джунов по первым пяти минутам болтовни за житие. Вот тогда ты уже синьор-помидор. А если ты синьор уже давно, то становишься тимлидом, если ты, конечно, хоть немного способенвыйти из своих интровертных границ.
А алгоритмы - да, это когда мидл набирает джунов. Что он вообще может им предложить-то, чтобы себя проявить?
AndreySitaev
08.04.2024 06:53Свести навыки и квалификации разработчика к типовым ответам на типовые вопросы - это несерьезно.
Что он вообще может им предложить-то, чтобы себя проявить?
тест на умение реализовать принципы ООП на практике (лайвкодинг)
аналогичный тест на знание и умение применить архитектурные паттерны
опрос на знание технологий, содержащий наводящие вопросы
упомянутый выше поиск ошибок и неоптимальностей в коде
Само собой, с поправкой на уровень собеседование - п2, например, можно и пропустить для джуна.
Vladimirsencov
08.04.2024 06:53+2Можно банальным лайвкодингом заменить. Чтобы задача была близкая к тому чем человек обычно занимается.
akakoychenko
08.04.2024 06:53+4Не удивлён, что пост в минусе, - не любят тут такое. Хотя, лично я, прособеседовав >100 инженеров (причём, большинство из них - синиоров), заметил очень чёткую корреляцию - все инженеры, кто круто себя проявил на алгоритмической части, показывали очень высокую эффективность на реальных задачах в последствии (да, с некоторыми звездами были вопросы с софт скиллами, когда человек мог, но не хотел, но это уже выходит за рамки треда). Причём, задачи у меня были не с литкода, и не на знание конкретных алгоритмов.
Hidden text
Топ 2 задача в списке моих любимых:
Предложите реализацию структуры, в которой будет хранить данные текстовый редактор для больших файлов. Требования: поддержка файлов на десятки ГБ при условии, что на машине хватает RAM для хранения как самого файла, так и вспомогательных структур; быстрые операции чтения, вставки, удаления строки по порядковому номеру строки от начала файла (зачёт по самой медленной из этих 3х).
Да, можете возразить, что я просто реджектил тех, кто не прошел, но нет - оффера и работу получали и люди, которые не смогли решить эти задачи, но хорошо справлялись с другими блоками собеседования. Задачи, как под спойлером, вообще не были предназначены, как фильтр, отправляющий домой, а они нужны были для того, чтобы понять, как человек думает. Бьётся ли лбом в одну точку, игнорируя замечания о противоречиях в его логике, насколько имеет широкий кругозор, и видит аналогии, может ли сводить одну задачу к другой. Если здесь все отрабатывало идеально, то, как правило, человек создавал правильные алгоритмы и на куда более высоких уровнях абстракции (где какую БД применить, как архитектуру кешей построить, где писать код, транслируя строка за строкой ТЗ, а где потратить неделю на обобщенное решение, и потом лишь превращать таски в конфигурации)
michael_v89
08.04.2024 06:53+1Предложите реализацию структуры, в которой будет хранить данные текстовый редактор для больших файлов.
Это не то, что обычно подразумевается под знанием алгоритмов. Задачи на алгоритмы другие, и спор как раз о том, нужны ли они в таком виде.
akakoychenko
08.04.2024 06:53А вот я тут с вами не то, чтобы согласен. Правильный ответ подразумевает или знание конкретной очень редкой структуры (которую, про-литкодеры знают, но "нормальные" люди не слышали о ней никогда), или переработку идеи бинарного дерева во время собеседования с созданием алгоритма с 0. Стандартные структуры именно эту задачу решать не умеют. Ну, или, если совсем туго в эту сторону, то хотя-бы инженерное, а не алгоритмическое решение с партиционированием и управлением этим хозяйством.
michael_v89
08.04.2024 06:53Ну так в том и дело, если она редкая, зачем человек должен ее постоянно знать. Если он ее не знает, то это показывает лишь то, что он ее не знает, а не его навыки программирования в целом.
Если весь файл помещается в RAM, я бы сделал список указателей на строки, со сдвигом следующих указателей при вставке в середину (не linked list). Но в файле может быть одна большая строка на десятки гигабайт, поэтому можно сделать второй уровень разбивки обычных строк на псевдо-строки например по 100 Кб. 2 уровня соответствуют 2 координатам скроллинга. Конечно в реальной задаче я бы подумал пару часов, попробовал реализовать, и возможно что-нибудь поменял. Для практических целей этого будет достаточно, поэтому с моей точки зрения это задача не на алгоритмы, ее можно сделать, не зная редких структур.
akakoychenko
08.04.2024 06:53+1Если б мы были на собеседовании, то я бы сказал примерно следующее:
Сдвиг указателей -> O(N).
O(N) это очень плохо. Если это 10 гигабайт коротеньких строк, то при добавлении строк в начало будут ощутимые тормоза, и пользоваться будет неприятно. Давайте подумаем над реализацией, при которой будет оценка лучше O(N) для всех 3 операций. Ну и да, для того, чтобы ограничить условия задачи, считаем, что все строки по длине до 2048 символов.
А вот, после этого, я бы уже посмотрел, как Вы думаете, какие перебираете идеи, как быстро отсекаете очевидно плохие
michael_v89
08.04.2024 06:53+1Это то же самое, что одна длинная строка, только по другому измерению. Добавляем еще 1 уровень для вертикального направления, разбиваем по N указателей. По крайней мере это то, с чего я бы попробовал начать реализацию.
Но дело не в этом, а в том, что без предварительного знания такие задачи за 20 минут не решаются, а с предварительным это обычная зубрежка, которая ничего не показывает. На практике потратить 2 дня на изучение для нестандартной задачи считается нормально.
akakoychenko
08.04.2024 06:53+1На практике лет собеседований сначала senior C#, затем senior Python, за минут 10 совместного обсуждения хорошие кандидаты выходили на хорошее алгоритмическое решение O(log N), либо на инженерное решение с партициями, у которого сложно задать сложность формулой, но задачу комфортного пользования оно решает тоже. Понятно, что то, что мы обсудили на пальцах, это не прод решение. Там не было корнер кейсов с намеренно ломающими алгоритм сценариями использования
michael_v89
08.04.2024 06:53+1Я согласен, для собеседования это неплохая задача, но все-таки это не то, что обычно подразумевают под знанием алгоритмов.
за минут 10 совместного обсуждения хорошие кандидаты выходили
Ну так это просто вы считаете их хорошими по этому критерию. Кому-то мог понадобиться час, и он пришел бы к тому же решению. А на практике такая разница во времени выполнения ни на что не влияет.
temabed
08.04.2024 06:53Я всего лишь начинающий бэкендер (в состоянии обучения), и понимаю необходимость в алгоритмах. Но заучивать их мне кажется странным. Для разработки, по моему скромному мнению, нужно уметь подбирать лучший инструмент в нужный момент, ну и конечно иметь базу по его использованию. А нюансы можно и подсмотреть в конкретной ситуации.
Кстати, можете подсказать, как мне определить свой уровень? Мой стэк: Python, ООП, GIT, Linux, Docker, SQL, Flask, многопроцессорное и многопоточное программирование, автотесты (unittests). Т.е. могу написать приложение на Flask, поработать с процессами и потоками, прикрутить БД, покрыть тестами, и задеплоить всё это на сервак как с докером, так и без. У меня еще куча тем на изучении, прежде чем осмелюсь на первый собес. Но всё же.
И да, на вопросах по алгоритмам и обходу деревьев я, скорее всего, тоже посыплюсь. Видимо стоит уделить этому вопросу больше внимания.
longclaps
08.04.2024 06:53Вы о каких алгоритмах лепечете? Они, знаете, бывают разной сложности, каким-то обучают пятиклассников, каким-то - профильных второкурсников, еще каким-то - студентов постарше.
Вы сами-то какого полёта птица, с реализацией АВЛ-дерева справитесь без привлечения сторонних библиотек? А с привлечением? (шучу, конечно).
Нет ответа. Только уха лопух на КДПВ.
wataru
08.04.2024 06:53Вы сами-то какого полёта птица, с реализацией АВЛ-дерева справитесь без привлечения сторонних библиотек? А с привлечением? (шучу, конечно).
Может где-то и есть идиоты, которые такое спрашивают, но обычно реализацию дерева никто ни на каком собеседовании не ждет. Досаточно, что кандидат, намриер, впендюрил std::map вместо std::vector. И смог объяснить, почему. Если же есть какая-то задача, проверяющая, что кандидат сможет удержать в голове 2 указателя на левого и правого ребенка и способен осознать рекурсию, вроде знаменитой задачи о развороте дерева, то там не надо никакого балансирования, и решение - в 3 строки весьма простого кода.
longclaps
08.04.2024 06:53Незачем искать идиотов где-то, рассмотрим ваш случай. Я сделал очень простое высказывание: статья не содержит никакой конкретики (не считать же конкретикой "простейшую задачку с LeetCode"). Я дал примеры такой конкретики, просто для масштаба, а вдруг поймёт.
Что понял он - пока не известно, вы же поняли нечто совершенно своё. Так бывает.
Во избежание дальнейших недоразумений давайте прекратим наш разговор. Как собеседник вы меня не интересуете.
souls_arch
08.04.2024 06:53Алгоритмические != логические и/или умственные. Я надеюсь, вы знаете в чем разница. На тех же олимпиадах по математике и информатике задачи в первую очередь НЕ Алгоритмические. И именно это подчеркивает остроту ума и умение выбраться даже из безвыходной ситуации. Более того, для этого нередко нужно мыслить АЛОГИЧЕСКИ! И только так их можно решить. Вы же набираете стадо баранов, которые не умеют ни в код ни мыслить нестандартно! Похвастались...
Pardych
08.04.2024 06:53+1Уважаемый. Программирование и вообще инженерия это не изобретение бесконечных эвристик. По большей части это сведение к "известной задаче", знаете анекдот про математика и чайник? Ну тот в котором он воду выливает из чайника потому что алгоритм заварки с чайником без воды ему уже известен. Вот оно. Но в несколько иной форме. Ну и знание инструментов. Чаще даже не само по себе знание, а знание об их существовании и сфере применения, благо никто не мешает порисечить что лучше подходит в каждом конкретном случае.
Олимпиадные задачи по программированию равно как и по математике именно что придуманы так что решения без эвристики для них нет. Нужно вскрыть неявную закономерность, потому что для решения в лоб там просто недостаточно данных. А дальше применять подход (вот тут базовые знания нужны) характерный для этой закономерности - уже в лоб. Я в спешал олимпикс по программирования например никогда не участвовал, но в математику - был в олимпиадном кружке. В основном вся магия нестандартности сводится к тому что ты заучиваешь множество разнообразных базовых вещей чтобы видеть их там где хотя бы кончик уха от них торчит.
AndreySitaev
08.04.2024 06:53Алгоритмические != логические и/или умственные.
Я бы поставил знак равенства. В таких задачах применятеся логика, там нужны умственные способности - в зависимости от сложности задач - как минимум, не ниже среднего.
Вы же набираете стадо баранов, которые не умеют ни в код ни мыслить нестандартно!
Очень смелое заявление. Если кандидат способен решать подобные задачи, "бараном", который не умеет мыслить "нестандартно", его не назовешь.
Вы сами, осмелюсь спросить, смотрели на leetCode? Посмотрите пару задач навскидку: вы уверены, что их можно решить с мякиной в голове, но с большим упорством, вызубрив "десяток / другой" задачек?
dididididi
08.04.2024 06:53До 9 класса. А потом также зубрить разные типы Олимпиадеых задачек, с целью чтоб увидеть что-то знакомое на Олимпиаде.
Shado_vi
08.04.2024 06:53почему обычно используются "академические" алгоритмические задачи которые по сути проверяют насколько человек подготовился к собеседованию(зачастую способность зубрёжки/запоминания)?
а не способности человека к разработке? а именно способности к логике и решения практических задач?условно, вместо того что бы искать тех кто будет реально решать ваши задачи вы(те кто так набирает) ищите тех то займёт место больше "для галочки".
petropavel
08.04.2024 06:53Да я не знаю, карго-культ какой-то. Когда нанимают бегуна — его просят пробежать дистанцию, а не перечислить пять способов шнуровки кроссовок. А если программиста — то сразу начинается вот это всё.
Didntread
08.04.2024 06:53+1если кандидату далее придется каждый день брать из базы, раскладывать по мапкам, потом отдавать dto, то почему бы умение раскладывать по мапкам не проверить при приеме на работу
Batalmv
08.04.2024 06:53+2Однако, все изменилось в один день) мне потребовалось подобрать пару-тройку разработчиков в команду, и проводя пятое или шестое собеседование мне попался кандидат, который идеально отвечал на все теоретические вопросы (базовые и не очень)
Возможно у вас банально перебор с теорией. Как по мне, мучить кандидата теорией смысла мало то двум причинам:
-
есть риск отбраковать хорошего спеца, который просто забыл/не знал, но активно использует
есть риск потратить много времени на то, что не надо в итоге
Я обычно задаю вопрос по теории для затравки, а дальше идем вгубь с практикой (опять же, не сложной). Важно понимать, что кандидат реально знает, и думал ли он об этом.
Простой пример (тоже больше архитектурный, но и разраба не грех спросить). Расскажите о преимуществах микросервисов ... получаем стандартный набор штампов, после чего просим пояснить, почему условный монолит потребляет больше CPU. Тут обычно думающий человек сам идет в детали, и можно в диалоге понять глубину погружения и опыт, либо "шпора" закончилась и станет сразу понятно, то дальше википедии народ не копал. Правильного ответа на вопрос навернео нет, но вскрывается опыт и направление мысле кандидата.
Ну или попросить порассуждать на тему синхрона и асхинхрона, а потом попросить смоделировать асинхронное на HTTP. Вполне есть риск словить ответ вроде "невозможно", после чего начинаешь думать, понимает ли человек, либо знает только теорию/живет с шорами. Хотя тут вообще поле для дейтельности огромное
Транзакционность - это всегда интересно, так как большинство разработчиков живут в мире, где код выполянется в одном экземпляре, но вы же не хотите получить "стремный" код в живом проекте. Как по мне, четким сигналом уже будет, задается ли кандидат вообще этой проблематикой или нет
Из технологий с последнего опыта забавно было в очередной раз узнать, что все пишут в резюме SQL, но написать простой запрос с вложением - уже непосилюьная задача. Зачем писать и тратить иместо, если знание ограничивается select ... from ... where? На этом примере как по мне не надо копать далеко и глубоко. Найдите себе пару задач на грани "чуть дальше базы" и дайте на лайф кодинг, так чтобы можно было даже писать код в "блокноте".
1dNDN
08.04.2024 06:53+3Зачем писать и тратить иместо, если знание ограничивается select ... from ... where?
Чтобы фильтр по ключевым словам от HR пройти
-
Zara6502
08.04.2024 06:53+6Напишу вам алгоритм, который я спрашиваю от соискателя, который мне за 25 лет сказал всего один человек, которого я нанял хотя у него даже образования не было.
Сделать самому
Не получилось - искать в интернете
Не получилось - спросить у коллег
Не получилось - спросить у меня
Через месяц он перестал спрашивать у меня и все вопросы решал сам.
longclaps
08.04.2024 06:53И что же, так 25 лет и живёте душа в душу? Прикольно.
Ну что он у коллег перестал спрашивать как-то проконтролировать можно. А вот насчет искать в интернете - как вы ему по рукам дали?
michael_v89
08.04.2024 06:53мне казалось, что классический подход лучше
кандидат, который идеально отвечал на все теоретические вопросы (базовые и не очень),
я услышал аккуратный шелест листочков....Классический подход вообще-то подразумевает проверку практических навыков.
это верно в случае, если подбираем middle и выше, а если нужен junior+ или middle-?
А вы его подбираете, чтобы он вам теорию рассказывал, или практический код писал?
Для кандидатов с маленьким опытом наоборот должно быть больше практических задач. Тестовое задание до собеседования и несколько небольших задач на собеседовании.однако, знание простых алгоритмов позволит раскрыть истинное знание кандидата.
Знание простых алгоритмов позволит раскрыть только истинное знание кандидатом простых алгоритмов.
gun_dose
08.04.2024 06:53+2Ни алгоритмы, ни теоретические вопросы на собесах не нужны. Если хорошо владеешь своим стеком, всегда можно придумать несколько вопросов, где человеку надо просто порассуждать, и сразу будет видно, что он из себя представляет. А если не можешь придумать такой вопрос, значит сам ещё не дорос, чтобы проводить собеседования.
bascomo
08.04.2024 06:53Какое отношение всё это имеет к реальным задачам, которые должен будет выполнять сотрудник? Вы осознаёте, что "выплеснул дитя вместе с водой" - это про Вас?
SergejSh
08.04.2024 06:53Тот кого он отшил. Был возможно очень не плохим кандидатом. Ну просто перестраховался чуть. А задачу не смог решить потому что растерялся.
SergejSh
08.04.2024 06:53+1Не смогу решить даже на собеседовании ту задачу которую решил бы в другой обстановке.
ptr128
08.04.2024 06:53+1А не эффективней ли дать код и послушать рекомендации по его оптимизации? Уж не оптимального кода в PR по разным причинам всегда хватает. Зато и решать кандидат будет именно такой тип задач, с которым он у Вас столкнется.
Hivemaster
08.04.2024 06:53То есть у вас были одни шаблонные вопросы, на которые можно написать шпаргалки, и вы их заменили на другие шаблонные вопросы, для которых шпаргалок нужно писать больше и листочками шуршать дольше? Замечательная идея, Уолтер, надёжная, как швейцарские часы!
Chelyuk
08.04.2024 06:53Собеседование - нужно проводить под позицию. Конечно интервьюверу. проще написать список стандартных вопросов и идти по ним.
Но толку от таких собеседований мало.
Я стараюсь учитывать все аспекты. Что реально нужно будет делать, состав команды, какие области нужно будет закрыть, бизнес домен и т.д.
Можно получить факап по любой из этих причин. Например, сильный алгортмист, но на проекте это не нужно, от слова совсем. И девопсов выделенных нет, а он ни в кубернетс не умеет, ни с облаками не работал и терраформ не знает. Да и банально не может поставить пайплайн с юнит-тестами, сборкой и развёртыванием.
Ну и наоборот бывает, человек всё умеет, а ему никто прав не даст, все построено и девопсов целая команда, а от него нужно только код хороший писать с глубоким погружением в архитектуру.
Или всё классно, но человек только приложения делал, а тут embedded а он даже даташит со схемой прочитать не может.
Или моё любимое, медицинский домен. Можно иметь кучу знаний и всё уметь, но запороть проект недооценив важность процессов. И закомитив, что-то до подписания всех необходимых бумаг.
coodi
08.04.2024 06:53Решение алгоритмических задач с литкода на собеседовании может лишь показать, насколько хорошо кандидат прорешал литкод. Всё на этом.
iqp
08.04.2024 06:53Решение алгоритмических задач с литкода на собеседовании может лишь показать, насколько хорошо кандидат прорешал литкод. Всё на этом.
Из тех, кто прорешал литкод, автор ищет тех, кому это прорешание в кайф, который потом будет прорешивать на автопилоте без пинков для ускорения. Такой кадр может быть полезен команде, потому что режим такого блуждающего прорешивания дает возможность видеть глобальные максимумы. Тот, кто уперся рогом и копает конкретно, видит только локальные максимумы. Статейка небанальная к тому же концентрированная, короткая. Не закинув плюс как в статью так и в карму, пройти мимо не получается.
coodi
08.04.2024 06:53Вообще не факт, мне нравится литкод, но в качестве развлечения. Практической нагрузки большинство задач не имеют, только спортивный результат - быстрее и экономичнее. К тому же некоторым людям, которые впервые видят задачу, не сложно ее реализовать, но сложно понять подход, сам алгоритм, который надо применить для решения. Но прорешав бы литкод, он уже знал бы решение.
pseudotech
08.04.2024 06:53Интересно, а для какой конкретно задачи вам понадобились алгоритмисты? Что требовалось реализовать?
fatalitirar
08.04.2024 06:53Самая беда с алгоримическими собесами, это то, что интервьюер в какой-то момент ждет что собеседуемый знает решение с низкой O() сложностью, под конкретную задачу.
FroseMan
08.04.2024 06:53Предпочитаю сразу спросить, будут ли алгоритмы. Если будут, то предлагаю нам не тратить время, я их не натаскиваю, вам не подойду
NihilPersonalis
08.04.2024 06:53По поводу "важного" аспекта в разработке хочу сказать, что часто приходится придумывать костыли. На проработку эффективных решений времени и ресурсов порой просто не дают.
slavaRomantsov
08.04.2024 06:53Провожу собеседования по фронтенду (хоть и не часто) помимо теории даю задачу только не алгоритмическую а просто даю сломанное приложение и прошу отдебажить найти причину и исправить. Разрешаю кстати пользоваться всем (гугл, дока...) кроме искуственного интелекта (заодно смотрю как человек гуглит как размышляет). Задача решается максимум за 10 минут (опытным фронтендером), что никого особо не напрягает.
foxez
08.04.2024 06:53Много раз встречал случаи, когда люди отлично знали аглоритмы и теорию, а на работе писали спагетти, иногда стараясь над оптимизацией сложности в отдельных бесполезных местах.
Выучил весь литкод и начинаешь оптимизировать какую-то мелкую низконагруженную фигню, которая работает за квадрат, но n не скейлится. Зато на архитектуру и поддердиваемость, о которой здраво теоретизировал на собесе забил. Потому что SOLID-принципы так хорошо зазубрил, что разбудить ночью — ответишь, однако на практике не хватает насмотренности и опыта чтобы увидеть корнеркейсы кода который написал.
petropavel
То есть плюсы алгоритмического собеседования в том, что кандидат сразу слился? Так можно начинать разговор с фразы "спасибо, вы нам не подходите" — будут сливаться ещё быстрее.