Комментарии 34
А решение алгоритмических задач, которые нередко дают на собеседованиях, демонстрирует исключительно способность решать алгоритмические задачи.
именно!
Или, например, у него спрашивают об архитектурной разнице между Kafka и RabbitMQ, а потом оказывается, что на проекте нет ни того, ни другого.
тоже согласен, это маразм какой-то
Например, мы даём математическую задачу уровня третьего класса и просим воплотить её в коде
wait a minute...
А какие ваши предложения? Как компании убедиться, что кандидат не запутается в трёх логических условиях алгоритма? Давать задачу на булеву алгебру?
Тот же пример сортировки, даёт возможность увидеть как мыслит человек, даже если не знает алгоритма. Это самое ценное в вопросе про сортировку. А так да, можно вызубрить её решение и говорить, что это бесполезная задача.
Не всё рабочие задачи требуют алгоритма сортировки. Но вот понимание сложности выполнения алгоритма и что есть способы решить ту же задачу эффективнее - важны.
Хотя не всегда. Компьютеры мощнее, о производительности продукта можно не думать).
Когда нанимают водителя, не проверяют же, как он мыслит на круглых люках. И не смотрят на его уровень в Carmageddon.
Мой подход не универсальный, у нас особый случай. Open Source проект, открытый баг-фиче-трекер. Я просто даю ссылку на тикет и прошу сделать фичу. Проверка на реальной боевой задаче.
на самом деле, не "просто". это должна быть фича, которую мы точно не хотим в релиз, и я перед этим её делаю сам, мне надо при этом уложиться в 5-10 минут. обычно это строк 10-15 максимум добавить или скопировать.
Потом интервью, обсудить. Если есть гитхаб и там достаточно кода — можно тестовое пропустить.
Писал уже пару раз, напишу ещё - мы с коллегой раздумывали над способом проверки кандидатов без использования "100 золотых вопросов по java" и вот к чему пришли:
Делаем тестовый проект который будет отдаленно напоминать функционал будущего проекта, само собой в СИЛЬНО упрощенной форме - пару ендпоинтов, контроллер и сервисы к ним, десяток сущностей, базу там ну и прочее что в стеке используется просто в виде наброска, так сказать широкими мазками. Все пакуем в докер, пишем ридмишку как быстро все поднять и закидываем в гит репозиторий
Зовем нового кандидата. Перед интервью придумываем 1-2 задачи. Задачи должны быть простыми из разряда "добавить новый эндпоинт с такой-то логикой" или "переделать логику работы сервиса с учетом того-то" или "заменить поле в сущности на Enum и внести правки дто, мапперы и сервис" итд.
Дальше просто подключаемся по видеосвязи, даем кандидату ссылку на репу и просим сделать гит клон. Сначала говорим что в общих чертах делает приложение и как оно работает, а потом просим его разобраться с проектом. Тут он будет рассказывать общие вещи вроде "это слой с api работает так то и так то" "тут контроллер api он вот так связывает эндпоинты с сервисом" "это сервисный слой он тут туда сюда мапер, энтити и в базу" и так далее. В процессе как раз можно обсудить теоретические вопросы по архитектуре и прочему именно в виде обсуждения, мол а как бы ты это сделал а как бы ты то сделал.
Дальше даем задачу и разрешаем использовать гугл абсолютно не стыдясь, пусть будет как на работе. В процессе спрашиваем почему так или не так, подкидываем мысли, смотрим возникают ли вопросы по неполному ТЗ. Там же будет видно, человек IDE пользоваться умеет? Шорткаты там всякие делает? Как код читает на уровне мидла или сениора? и так далее. Если задачу нормально сделал пусть пушит её в репо, таким образом следующим людям будет дан уже изменившийся проект, другие задачи итд, а это значит бесконечная вариативность и практически исключает возможность подготовиться к вопросам заранее.
Кстати задачи на то что бы такого сделать можно просить генерить кандидатов на аналитиков, а декомпозировать их кандидатов на тех лидов и сениоров.
итого вокруг одного проекта вы получаете возможность проверить реальные навыки человека в реальной работе, пообщаться и посмотреть как он задачи принимает и как решает, даже что и как он гуглит. Нет смысла "сливать вопросы к собеседованию" по тому что они всегда разные будут и если у двух людей подряд еще хоть немного похож проект то у 1 и 10 кандидата уже все будет разное.
Надеюсь кто-то услышит и решит внедрить
Хорошая идея, если бы я был java разработчиком, я бы одобрил. Мы делали несколько иначе, но с тем же смыслом:
Брали реальный кусок сайта, отрезали его от всех зависимостей, специально засирали код, как могли. Давали этот кусок кандидату, и он уже в привычной среде пытался делать код-ревью, что-то комментировать, исправлять. Сразу становится понятно, как долго человек работал, насколько быстро и глубоко вникает в проблемы, в специфику, а там уже можно и пообщаться подробнее. При этом всё также в формате live-coding.
имхо, близкий к идеальному вариант задачи для трудоустройства
Из десятков собеседований у меня было только одно, где проверяли не память, а навык рассуждать и уметь находить решения. Хотя, перед этим ознакомились с пет-проектами.
Интервьюер не заваливал вопросами, не пытался давить. Он просто рассказал про команду, задачи и описал общий процесс работы. После чего мы ненавязчиво перешли к собеседованию в стиле - а давай представим, что нам с тобой нужно реализовать приложение для учета горюче-смазочнвх материалов на АЗС (далее шло условное ТЗ) и мы начали думать (вдвоем!!!). Накидали диаграмму условной бизнес-логики, потом плавно перешли к реализации некоторых задач. Это было самое длинное, но самое шикарное интервью. Интервьюеру не были интересны мои академические знания или то, как я вызубрил мифическую базу. Он не пожалел времени, чтобы выяснить мой скилл поиска решений и информации. И, кстати, было видно, что ему и самому интересен такой процесс прощупывания соискателя. В итоге, я с околонулевыми знаниями зашел в команду и проработал там пару лет. Команда тоже оказалась офигенной, продуктивной и в какой-то мере фанатичной и тоже многие вошли так же, как и я - с околонулевыми знаниями и росли как спецы уже на проекте. Побольше бы таких вникающих и проницательных специалистов на собесах и тогда жить стало бы проще. Действительно тупые соискатели отсеивались бы автоматически, а люди с перспективами в недалеком будущем, но околонулевыми знаниями сейчас - спокойно заходили бы на позиции.
У каждого даже студента есть некоторый багаж знаний и наработок, которые он может предоставить. Так что вы все занимаетесь редкостным бредом, вместо того что бы реально посмотреть наработки и оценить, что человек из себя представляет, дело 5 минут. Всë что вы описываете это когда человек приходит как чистый лист и говорит, что у него ничего ещë нет за плечами... И тут вопросы сразу, а нужен ли вам он?
Но никак руки не доходят проект создать, да?)
И что подобный подход должен протестировать? Стрессоустойчивость человека и умение кодить, когда за плечом стоит начальник и смотрит в экран? Не знаю как у вас, но я, как и многие мои знакомые, не в состоянии кодить, когда кто-то смотрит за спиной. У меня в этом случае 90% концентрации на человеке и мысли о том, что за мной наблюдают, "надо не облажаться" и лишь 10% на задаче. Естественно, ничего хорошего тут не выйдет. Прекрасно помню, как на первом собеседовании мне дали пару простых задач и ждали ответ - я не смог на них сконцентрироваться, для одних решение придумал - но не оптимальное, другие не решил. Результат собеседующего устроил, но после собеса я захотел их все же решить: никуда не полез гуглить, просто хорошенько задумался и за пару минут решил все и оптимальным путем. Т.е. знания и навыки были, но решать под контролем зрителя задачки я не могу.
То, что вы описали - придумано миллион лет назад и называется "тестовое задание", разница лишь в том, что его дают на дом, дают срок и позволяют человеку решить его как и когда ему удобно. А не стоят над душой. Рассказывал знакомой дизайнеру как у нас проходят собесы, что там экзамены устраивают, задачки под присмотром решать заставляют: она в шоке была. Говорит, у нее никогда и близко подобного не было, у них так: на собеседовании общаются по душам, рассказывает где работала, что делала. Потом ТЗ - в свое время, без присмотра. Если результат компанию устраивает - кандидата берут. Все. ни экзаменов, ни задачек на бумажке, ни "вот тебе репа, здесь и сейчас скажи что там и как, а потом расшарь экран и при нас реши тз".
Вопрос лишь один: почему в любой другой сфере работодатель доверяет кандидату и только в ИТ считается, что если тз дать на дом - оно будет решено "другом знакомого".
Проблема в том, что это отлично работало 10 лет назад, но сейчас кое что изменилось. Во первых, ты не можешь давать уникальные тестовые всем, а если попробуешь загуглить тестовое из большинства крупных компаний то сразу найдешь уже сделанные. поменял в них названия переменных и готово - ты "сделал" тестовое. Когда у тебя огромная компания в которую куча людей хотят устроится и используют современные методы оптимизации прохождения интервью типа слива задач, вопросов и паровозиков всяких, то тебе нужно помимо проверки умений кандидата проверить ещё что эти умения настоящие.
Да, решать задачки с литкода на собесе весьма напряжно - там надо делать непростые вещи, порой не очевидные и если не додумался до сложного алгоритма то и не решишь и будешь потеть и нервничать.
В моем же примере ты сначала просто проходишь по проекту и поясняешь где чего тут лежит что и зачем работает. Это не лайвкодинг. Дальше тебе дают задачу и её нужно будет обсуждать с точки зрения реализации и архитектуры - это тоже не лайвкодинг. А дальше да, надо попросить закодить но во первых - там элементарная круд вещь, без "поворота красно-черного дерева", во вторых, любой адекватный человек в онлайне сможет понять где ты не тянешь по тому что нервничаешь, а где по тому что не знаешь. Если человек залип на очевидном месте ему нужно просто сказать прямым текстом - "сделай тут мапу и проитерируйся по ней" если человек И ТАКОЕ не может в онлайне выдать... ну даже не знаю, а точно нужен такой невростеник в команде? на сколько много ты как компания потеряешь, если такого не наймешь?
Что проверяет такое собеседование? Да буквально то что нужно для решения 90% задач которые возникают у разрабов в среднем - умение писать круды и быстро фичи вводить.
Лучше скажи мне какие вопросы решает "тестовое" задание каким бы оно не было, или что проверяет ответ на вопрос "что такое PECS" или мое любимое - дать кусок кода с каким-нибудь идиотизмом и попросить человека выступить в роли компилятора и сказать что не так. Вот какой в этом толк?
тут да, нужно потренироваться писать код в живую. К сожалению, этот этап есть у большинства компаний. Хорошая новость, этот навык легко тренируется. Открываете какой-нибудь leetcode и на простых задачах, представляя что общаетесь пишите решения. Потом на собесах с неинтересными вам компаниях закрепляете.
В целом собесы это отдельный навык.
классный способ для аутсорсинговых фирмочек. Пособеседовал десяток кандидатов - проект готов ;) ну или оценка / общий план
Все большую популярность набирает формат System Design Interview. Например, бэкенд-разработчику во время него дают задачу спроектировать сокращатель ссылок.
Все большую популярность набирает формат System Design Interview. Например, бэкенд-разработчику во время интервью дают задачу спроектировать сокращатель ссылок.
Пожалуйста, поправьте, а то кажется что бэкенд-разработчику во время бэкенд-разработчика дают задачу
Особенно забавно что теперь и у QA Automation тоже стали спрашивать алгоритмы, и говорят вы не пугайтесь там алгоритмы не сложнее medium на leetCode.
Интересно было бы услышать хоть один пример где бы он мог понадобиться QA Automation.
Скорее всего по большинству направлений избыток предложения рабочей силы. Кроме самых сложных. Последствие массовой компьютеризации 90х и особенно 2000х, когда дети все более массово росли с компьютерами. А ниши наоборот закрыты все больше, основные виды программ и движков давно написаны. Перегрев рынка, помноженный на экономические причины.
В РФ никакого избытка нет.
Избыток только джунов после курсов, а если в твоей компании только фулл офис сомнительного качества, будешь по 1 человеку в год нанимать. Или студентов на стажировку.
По личному опыту найти хорошие подработки последние годы стало много сложнее.
Раньше было так - захотел подработать поискал по своей специализации, откликнулся - сразу милости просим. Причем без всяких технических интервью, без тестовых заданий.
Сейчас - чаще всего вообще не отвечают. Плюс очень мало предложений без тестовых заданий и технического собеседования.
Градация на джуны, миддлы и сеньоры меня вообще умиляет. Тот же Билл Гейтс, много лет проработавший и незакончивший университет неоднократно говорил в интервью что самый лучший способ изучить чего-то это не лекции и не учебные задания а обучение в ходе выполнения настоящих реальных задач. Он именно так сам начинал программировать, до того как раскрутил свою корпорацию. Сейчас объявили бы дружом и никуда не взяли.
Плюс страшная вешь что когда возраст старше 50 многие начинают шарахаться - разрыв поколений.
Почему переусложнен найм? Думаю, потому что сама по себе отрасль сложная.
Насмешили. Меня не берут, просто потому что мне полтинник. В ваших мемасах не шарю.
У меня все больше вопросов к рекрутерам:
обратной связи нет, вообще никакой
на собесе присутствуют крайне редко(один раз собеседующие начали обсуждать свой проект, как-будто меня нету и это не обес, просто 20 минут слушал рассуждения)
предлагаемый уровень зп, они вроде должны видеть и понимать, что за оклад в 88к на испытательном девопса - найдут в лучшем случае джуна, а не мидл+
почему не смогли удержать предыдущего сотрудника?
А решение алгоритмических задач, которые нередко дают на собеседованиях, демонстрирует исключительно способность решать алгоритмические задачи. Специалист, который работает с алгоритмом
Полностью согласен! Систем дизайн интервью куда лучше справляется с оценкой реальной работы человека. Интересно услышать аргументы тех, кто считает ровно наоборот?
Сразу оговорюсь, есть области где это действительно нужно, как, например, знания линейной алгебры нужны для разработчика игровых движков и конкретно для таких позиций ноль вопросов.
Чем выше уровень вакансии, тем выше риски при найме нового специалиста, ведь цена ошибки синьора может быть очень высока для бизнеса и его клиентов
А в чем риски? В том что найдут кандидата, с которым не сработаются и через полгода нужно снова открывать? Ну так это может произойти и с максимально хардскиловым кандидатом, который легко закрывает абсолютно все задачи. Но по другим причинам. Или такой человек начнет фигачить напрямую в прод сомнительный код без проверок? Ну тогда вопрос к процессам внутри компании.
Мне кажется, эти риски закрываются испытательным сроком и нормальным онбордингом. Т.е. взяли кандидата, который показался адекватным как по хард скилам так и по софт скилам, а после онбординга уже сто процентов видно подходит человек или нет.
Тут плюс в том хотя бы, что есть понимание что человек 5 лет не пиво пил (если у него ВО). Ну и алгоритмическую сложность по своему коду должен навскидку представлять.
Но опять же, действительно, для составителя формочек такие знания излишни. Но как вариант, человека владеющего такими знаниями можно сразу отсекать. Работать ему в таком месте будет скучно, придумает ещё что ни будь… Как потом это разбирать если никто не рубит?
Цирк с наймом усложняется с каждым годом, зарплаты деградируют. И, самое главное, почти никого это не смущает, многие продолжают играть по этим правилам.
"Чукча хитрый однако"(с)
Сначала описание проблем соискателей - поставил лайк.
Потом проблемы галер представлены, как универсальные для рынка - лайк уже не отзовешь.
IT очень молодая отрасль. Нет профсоюзов. Нет сплоченности. Каждый сам за себя. Работники разобщены и работодателям это выгодно. Они и дальше будут снижать оплату и повышать требования. Кто им запретит. Недовольных увольняют, а работу искать все труднее.
Меня одного смутило слово "наём" вместо "найм"?
Тут вопрос в том, что вам, как компании нужно. Яндексу и подобным надо непременно чтобы ты мог писать код на доске (сейчас - редакторе без подсветки синтаксиса и компиляции / выполнения), чтобы код логически верно решал задачу, учитывал все особые случаи, и был в идеале написан сразу, без лишних помарок и исправлений. Тут выбор алгоритмических задач вполне логичен. В этом есть смысл, ищут человека который достаточно умен, чтобы не программировать методом проб и ошибок, постоянно запуская код и только уже в дебагере понимая как он работает. А тут человек может в уме все продумать, проговорить и написать решение близкое к чистовому. Тут не проверяется алгоритмическая эрудированность и математическая подготовка, а проверяются базовые программисткие способности, так сказать - истинный программисткий IQ. Если человек эрудирован, его запарят дальше, в ход пойдут красно-черные деревья, хитро сделанные сортировки пока не найдут область где кандидат плавает, чтобы он наконец начал программировать, а не выдавать готовые заученные решения.
Это старая школа, когда не было удобных IDE, человек писал программу на бумаге, оператор пробивал ее на перфокартах, потом приносил распечатку с ответом программы)) цена запуска была высока.
Надо ли это сейчас, ну в целом нет, большинству компаний это не надо, да и не смогут найти достаточно таких людей, приходится выбирать из того что есть. Тут еще и собеседующий тоже должен быть достаточно высокого уровня могущий сам в уме решать, а где таких взять. Кандидат выдал решение, тебе надо проверить. Поэтому обычно не жестят. Ищут массовых работников, на среднерыночную зп. Но с другой стороны, будь у вас возможность при прочих равных набирать умных людей, которые могут в голове продумать задачу, продумать решение, вплоть до примерного количества строк (чтобы написать на доске сразу без помарок), это же большой плюс, правильно? У такого чувака задача будет делаться не целый день вымучивая Гугл, IDE и дебагер, а за условно час. Потом QA если и найдет чего, то это уже не будут очевидные всем случаи, а что-то реально интересное, неучтенное в условиях. В итоге - большая эффективность, меньше временных затрат, всем хорошо. Дальше, какие-то компании могут себе это позволить, есть достаточное количество кандидатов, а какие-то нет.
В целом, если говорить о сценарии собеседований, то сейчас у большинства компаний он вполне разумный:
1) вопросы-ответы, проверяется базовая эрудированность в нужной программисткой области. Обычно это язык и технологии.
2) программирование, тут могут быть алгоритмические и приближенные к реальным случаям задачи. Проверяется умение программировать.
3) общение, личные качества, более глобальные вопросы - анализ и обсуждение предметных задач.
Три этапа последовательны и логичны: 1й позволяет базово проверить в теме ли вообще кандидат, и подходит ли по уровню знаний, позволяет отсечь нерелевантных людей. 2й - умение собственно программировать, а не эрудированность в алгоритмах и SDK. 3й - общение, кандидат может быть сильным, но любитель делать все по своему, а не то что надо.
Все это можно разделить на три собеса или впихнуть в один, кому как удобно. По времени обычно часа два на все этапы.
Есть компании которые набрали от всех помаленьку, там у них и скрининг, и расширенные вопросы-ответы, и алгоритмы, и программирование приближенное к реальным задачам и системный дизайн, и ФИНАЛ (на котором ты не просто общаешься, а это прям нестоящий тест на софт скилы). В итоге от 5 и большее собеседований суммарно часов 8. А потом выяснится, что они не тянут по ожидаемой зп. Из наших компаний это Авито - 100500 собеседований. Знайте, в других компаниях (включая гигантов с именем например VK или Яндекс) - 2, ну максимум 3 собеса.
Ну и второй этап - программирование, когда вы знаете, что именно проверяется всеми нормальными компаниями, повторюсь, вовсе не алгоритмическая и математическая подготовка, то алгоритмы не самый плохой вариант. Если вы кандидат, то будьте хитрее, не надо спешить выдавать "а, ну это сортировка методом вставок" или "о, сейчас применим балансировку деревьев" или "тут очевидно надо применить методы динамического программирования". Знаете решение - отлично. Не спешите писать код. Изобретайте велосипед, проговорите ход мысли, крайние случаи, придумайте тупое решение, потом потом получше, а потом "о, эврика")) За собес вам надо решить пару-тройку задач не больше.
Сто лет собеседований: почему наём в IT так переусложнён