Регулярно мы видим в интернетах множество размышлений или криков души на тему содержания собеседований в IT. Мол, и интервьюировать не умеют, и задачи дают не релевантные, и вопросы бессмысленные, и, вообще, собесы в IT это ритуал и карго-культ. Сидит там интервьюер и думает: «чего бы такое ещё спросить», самоутверждается, а решение принимает в итоге наобум и по первому впечатлению.
В то же время компании в своих блогах пишут, как они за все хорошее, против всего плохого.
Если коротко, то я тоже считаю, что среднестатистический собес – это бессмысленный трэш, и сам я иногда провожу их неудачно. Раньше вообще проводил «как все» – то есть отвратительно. Затем, задумался. А что, если я постараюсь осмыслить, зачем я провожу интервью и почему задаю те вопросы, которые задаю? Может быть, мне будет проще отбирать релевантных кандидатов? Или я хотя бы смогу сэкономить немного времени, убрав из процесса что-то лишнее?
Добрый день. Меня зовут Михаил Толстой. Я работаю ведущим руководителем проектов в Ozon Tech и пишу в телеграм-канал «М-м-м, Толстой».
Вагона терпения описывать в один присест всё-всё-всё, что я пробовал, у меня нет (и едва ли у вас было время столько разом читать) – поэтому ловите сперва разбор самого одиозного из элементов технического интервью – live-кодинга.
По какой схеме пойдет дальнейшее повествование:
как было;
что я думаю;
что я попробовал;
нюансы и ответвления;
что вышло;
промежуточный итог.
Как было
Когда я только начинал свою карьеру, никакого морального права оценивать ребят с улицы у меня не было. А потом в один прекрасный день ты уже миддл-инженер и тебя направляют мучить кандидатов. Ну или как минимум соучаствовать в этом мучении. Лычка сеньора уже автоматом превращает тебя в палача.
Ты сразу же задаешься вопросом «А как это делается?» и начинаешь выдавать комбо из того, что делают твои коллеги (ну они ж умные) и того, как собеседовали тебя. Дедовщина. Служи, как дед служил.
И вот уже ты сам просишь людей написать что-то на доске/ на листке / в нотпаде или в веб-приложении для лайвкодинга.
И ты не останавливаешься – грейды растут, а подход не меняется, кандидата просят по-быстрому повертеть строки из гласных, полазать по разноцветным деревьям, что-то мутное поскорить и найти самый палиндромный палиндром.
Кандидат же насилует себя литкодом (или не насилует, а просто мычит, когда получает задачу на подсчёт фигурных скобочек)
И часы жизни спускаются на скрип пера по бумаге, чтобы написать то, что никогда не скомпилится.
Почему так происходит...
Что я думаю
Итак, порассуждаем, зачем на собеседовании задавать вопросы и задачи?
Чтобы на основании ответа понять, подходит ли кандидат на позицию. Обладает ли он требуемыми навыками.
«Обладает ли требуемыми навыками» – имхо, эта фраза располагает и дальше мыслить в канцелярите. Ты начинаешь в описании вакансии указывать требования в общих терминах, чтобы звучало ухххх, на все 300к/наносек. «Уверенное владение», «экспертные знания», и прочий «опыт работы с Х». В итоге на вакансию откликаются самые самоуверенные, а не те, кого, ты на самом деле жаждешь найти.
Попробуем быть проще. Переформулируем вопрос:
А умеет ли кандидат делать то, что ему, собственно, придется делать на работе?
Тогда логичным кажется, чтобы он на собеседовании показывал что-то максимально похожее на его работу.
— Будет ли он писать код?
— Конечно, да
Окей, на этом этапе какой-то кодинг в процессе отбора получается необходим. Простите, все, кто ждал, что я предложу выкинуть этот этап совсем.
— Он должен писать алгоритмически сложный код?
— Примерно никогда
— А какой код он будет писать?
— Ну, как у нас тут.
Если вы хотите, чтобы новый член вашей команды писал быстро код, как пишете его вы, то и задача пусть будет похожа. Вы занимаетесь перекладкой джейсонов, так может стоит проверить может ли кандидат их перекладывать?
— А как он будет писать код?
— Как и мы в IDE…
Почти все, с кем я общался, считают, что разработчик должен уметь пользоваться инструментарием. Но почему инструментарий – это только утилита греп или kubectl?! Он в IDE сидит 90 процентов времени, может неплохо было бы уметь ей пользоваться?
— Да он ничего не может без автокомплита!
— А с автокомплитом он может то, что требуется?
Забивать гвозди микроскопом – это не только про инструменты и фреймворки. Это ещё и про людей. Вам нужен человек, который в конкретной команде будет выдавать определенный результат. Вам правда важно, будет ли он гуглить как называется тот или иной метод? А если не важно, то зачем подвергать стрессу кандидата и «разрешать выдумывать нужные методы»?
— А как он будет проверять написанное?
— Ну мы пишем тесты, и он тоже будет.
Попросите человека написать тест с использованием знакомого ему фреймворка. Лично я в своем опыте вижу корреляцию между перформансом специалиста и тем, насколько резво и легко он пишет несложные тесты.
Вы же планируете платить ему за это, почему бы не проверить?
Что я попробовал
У меня есть несколько простых задач. Часть специфична для языков, библиотек и кейсов (ну и опыта кандидата).
Но есть и универсальные.
Моя любимая — «удаление троек».
На вход подается коллекция целых чисел.
Напишите метод, который удаляет из коллекции все тройки, для всех нечётных чисел, вызывает метод с побочным эффектом (пусть это будет печать в консоль), удаляет все семёрки, умножает всё на 2 и возвращает коллекцию-результат.
Я подожду пока вы досмеётесь. :)
Итак, приходит кандидат, я прошу его запустить свою IDE, свой сетап в котором ему удобно и привычно. Предупреждаю, что задача без подвоха, и скидываю условие.
Я проверяю как он его читает. Мне интересно, какие вопросы он задаст.
Как он выстроит коммуникацию?
Кто-то предупреждает, что задача выглядит такой простой что «давайте я напишу, а вы потом скажете, правильно ли я понял».
Плюс: что предупредил о намерении.
Минус: что не смог сформулировать план реализации – в реальной жизни тоже пойдет писать как можно быстрее.
Кто-то решает уточняет должны ли действия происходить в том же порядке что и описано в задаче, является ли множество упорядоченной последовательностью шагов.
Кто-то сразу приводит пример входа и выхода (устный TDD получается)
Кто-то уточняет что подразумевается под коллекцией результатом. Новая ли коллекция, какие для нее есть условия и ограничения. Что за коллекция подается на вход.
Кто-то просто молча начинает писать.
Подумайте заранее, кто впишется в конкретно ваш коллектив?
Или вам все равно, как человек работает, лишь бы был результат? Такое тоже может быть.
И дальше я смотрю, что будет. Ожидаемый результат – это быстрое без тормозов использование стандартных и/или любимых библиотек и алгоритмов.
Приходит Java-девелопер за триста и начинает, мыча, for-циклы крутить. Окей – нет стримов в анамнезе, но может какие-то библиотеки помогаторные? Пусть подключит тогда! Ну или вот такой опыт у него… Во-первых, мы это узнали вообще. Во-вторых, вдруг он так пишет быстро. Быстрее, чем ты на своих цепочках методов в Scala.
Затем я предлагаю проверить решение. Хотя и предпочитаю кандидатов, которые сами об этом заговаривают и или задают вопросы или сразу пишут автоматическую проверку.
Если кандидат начинает писать тест-кейсы в мейне, я спрашиваю его, как он проверяет свой код на текущем месте работы. Прошу создать тестовые файлики и смотрю, как он использует тест-фреймворк, ассерты, и как он тесты вообще запускает.
Конечно, мы все дописываем тесты чаще, чем подключаем тестовые библиотеки, поэтому в настройке IDE я не жду скорости молнии. Но странно нанимать человека, который не может подключить тест-систему…
Нюансы и ответвления
Дьявол в деталях.
Разумеется, ситуации в разных командах и компаниях разные. Тем более, нужно быть честными с самим собой и чётко понимать, что именно вам нужно от кандидата.
– Но мне нужен программист, который справляется с более сложными заданиями!
– А как вы это поняли?
Некоторое количество моих знакомых улучшили свой найм, когда провели ревизию своих сложных задач.
Такие задачи и правда бывают. Даже занимаясь «перекладкой джейсонов», бывает нужно и деревце обойти или мапы потранспонировать. А иногда продукт действительно не простой, и надо что-то на специфических конструкциях языка поделать или учесть какую-то хитрую особенность API.
— Какая задача покажет, что он сможет писать такой же сложный код как у нас?
— Та, для которой вы писали этот сложный код.
Постарайтесь найти ваши реальные сложные куски кода и приведите их к формату задачи на собеседование! Идеально было бы помнить:
как ваши текущие инженеры это решали;
были ли обсуждения;
помощь коллег;
сколько дней или итераций ревью съел кусочек кода.
Может быть на самом деле вам и не нужно, чтобы кандидат решал эту задачу в одно жало и за 40 минут.
Как вариант, проэмулируйте с ним парное программирование – определите, что и по каким ответам он должен понять. Проверьте, сможет ли он эффективно с вами коммуницировать.
А если вам правда надо писать с листа именно такие штуки – ну их и проверяйте.
– Ой, у нас легаси, с ним надо разбираться, мы сами эту дичь не писали.
– Значит и он не будет.
Очень часто задача не написать фреймворк или алгоритм, а разобраться в существующем коде, чтобы найти ошибку или порефакторить его, не сломав. Иногда можно собрать тестовый проект и предложить кандидату выкачать его в свою IDE, подключить и посмотреть, как он работает с исходниками, как он будет реагировать на вашу кодовую базу.
Но мы сейчас так уйдем от основной темы статьи.
Что получилось
Я собеседовал этими тройками программистов на Java, Scala, C++, Python and Javascript. Сеньоров-помидоров, ми-ми-миддлов и джунов, – всех с разными ожиданиями, разумеется.
Поскольку хороший кандидат уровня миддл и выше справляется с этим быстро, то остается время «помять задачу», обсудить число проходов, как оно вообще под капотом (если не на голых циклах человек решение родил). Обсудить особенности тестовых фреймворков. Ну или можно дать еще одну задачку. Поразительное количество человек валились, мямлили что-то неадекватное, не умели собрать и запустить свою программу. Что уж говорить о подходе к тестированию.
А если бы задача была сложная – надо бы было дать кандидату время, потом еще пожалеть его, вдруг он не додумался по какой-то причине.
А если кандидат не справляется с тройками, то я очевидно не готов с ним работать. Вежливо сворачиваемся, общаемся и пытаемся разойтись в хороших отношениях на бодрой ноте. 8 таких интервью экономят полный рабочий день.
Если же кандидат справляется с подобной и/или более специфической задачей, похожей на его будущий труд, то я увидел всё что хотел, остальное я добью другими вопросами и другим форматом.
Знакомство с лучшими из работавших у меня инженеров, началось с удаления троек, и кучу людей я успешно этими же тройками отсеял. И ни разу у меня не было претензий к написанию кода, потому что я стал проверять то, за что собираюсь платить.
Промежуточный итог
Проанализировав работу, которую придётся выполнять вашему будущему коллеге или подопечному, вы можете разговаривать с ним более честно и меньше теряться в сомнениях «на собесе он ок, а каково будет с ним работать». Собеседование можно свернуть раньше, увидев тот или иной красный флаг, и честно его обсудить.
Кандидат при этом может получить релевантный фидбек.
Рассказ о вашем собеседовании может настроить сарафан на более подходящий поток.
Первый рабочий день принесет вам значительно меньше сюрпризов.
Впечатления о человеке (на основании впечатлений вы и решаете «брать или не брать») больше похожи на впечатления от его настоящей работы.
Нашёл ли я серебряную пулю? Конечно, нет! Как минимум потому, что мы нанимаем человека, инженера, а не просто машину по написанию кода. А проверить личные качества и софты — это ещё более сложная задача.
Но, надеюсь, описанный выше подход, позволит выиграть на эти проверки немного времени и ресурсов.
В следующих частях мы посмотрим, что ещё мы можем проверить и обсудить с кандидатом, чтобы повысить шансы нанять именно того, кого нужно.
Желаю вам работать с людьми, подходящими для своих позиций!
Комментарии (66)
KILYAV
02.12.2023 13:52+3"Все" посты одна сплошная ошибка выжившего, все пишут о тех кого наняли, я вот хотел бы почитать о тех кого не наняли.
saboteur_kiev
02.12.2023 13:52+1Кучу людей, которые не способны продемонстировать логику, навыки указанные в резюме и хоть какую-то проактивность.
Как написано в статье, "Дьявол в деталях."
Не так важно какой вопрос и ответ были заданы. Важны детали - как человек отвечал, как он подходил к ответу. Чтобы понять процесс мышления и оценить насколько он адекватен.Насколько проста коммуникация с человеком - если ты ему задаешь один вопрос, а он отвечает на совсем другой, и даже после уточнения говорит в другую сторону - такой человек не подходит. Он будет постоянно лажать с задачами (предполагаем, что интервьювером отправляют адекватного человека ;)
Dinver
02.12.2023 13:52+2Либо человек гик с синдромом самозванца, интроверт и просто не может сосредоточиться на собеседовании. Про этот вариант большинство просто забывает. А потом оказывается что в компании все активные и общительные, но по нетривиальным задачам работает 1-2 человека, случайным образом попавшие в компанию, а у остальных лапки.
tolstoymv Автор
02.12.2023 13:52В целом согласен с вами, коллега. Но все же считаю, что вопрос и ответ важны. Но только, если вопрос релевантный. Потому и предлагаю спрашивать что-то максимально приближенное, чтобы сам ответ тоже имел смысл.
tolstoymv Автор
02.12.2023 13:52+1Я полагаю, что на своем основном языке из коллекции элементы пофильтровать - это что-то абсолютно базовое. Тут нет алгоритма над которым надо думать или решать задачи оптимизации.
Вы бы хотели работать с человеком, который не может этого сделать?
Собственно если мы делаем более сложную, но релеватнтную (!) задачу, это помогает получить человека с релевантными навыками в моменте.
Если же цель нанять человека на вырост, то и проверять я бы предложил его умение вырастать.
Подскажите пожалуйста, что вы подразумеваете под "почитать о тех кого не наняли"? Может я бы смог удовлетворить ваш интерес.
Ares_ekb
02.12.2023 13:52+10У меня есть несколько простых задач.
Как он выстроит коммуникацию?
Кто-то предупреждает, что задача выглядит такой простой что «давайте я напишу, а вы потом скажете, правильно ли я понял».
Плюс: что предупредил о намерении.
Минус: что не смог сформулировать план реализации – в реальной жизни тоже пойдет писать как можно быстрее.На мой взгляд, если сделать ещё одну итерацию в развитии вашего подхода, то можно и не давать человеку искусственные задачи, даже простые, и не гадать: "Ага! Он не уточнил постановку задачи, пошел сразу удалять все тройки, не уточнил сроки реализации и важность каждого из требований. А что если мне нужно удалять только каждую четную по счету тройку, а нечетные оставлять? Что если удаление троек - это основная фича и её точно нужно реализовать, а вывод в консоль - второстепенная фича и её можно сделать во вторую очередь? Ну, всё, раз не задал эти вопросы даже на такой простой задаче, то что от него можно ждать на более сложных?"
Я немного утрирую, но если вас интересует как человек выстраивает коммуникацию, работает с требованиями, умеет ли декомпозировать, приоритезировать, планировать задачи, то можно тупо спросить его об этом! Как он всё это делал на прошлых проектах. Для этого даже не нужны никакие задачи, не нужно проводить какой-то сложный анализ поведения соискателя, анализировать его мотивы. Если человека спросить какими интересными проектами он занимался, какие задачи и каким образом решал, то (сюрприз!!!) он в большинстве случаев об этом сам расскажет.
FirsofMaxim
02.12.2023 13:52+5А не думаете - «на словах я Лев Толстой, а на деле…»?
Ares_ekb
02.12.2023 13:52Это видно уже после первых ответов на конкретные вопросы. Всегда можно провалиться в детали. Сначала спросить чем человек в принципе занимался, что это был за проект, кто им пользовался. Спросить чем конкретно занимался именно он - только бэком или иногда и фронтом. Занимался ли базой данных. Какие сущности были в схеме данных. Какие были сервисы, модули, классы. Можно задать много вопросов по процессу разработки, сколько человек было на проекте, как он с ними взаимодействовал. Бывало ли что в постановке задачи ошибка или постановка в принципе нереализуемая. Бывало ли что задача оказывалась сложнее, чем её изначально оценили. В зависимости от ответов можно проваливаться всё глубже и глубже. Или наоборот задавать вопросы всё шире и шире, чтобы понять на сколько целостное представление у него о процессе разработки вообще.
С одной стороны, такое интервью очень мягкое, потому что это просто беседа, к которой не нужно специально готовиться. Человек сам волен направить её в любую сторону, говорить о том, что ему ближе и интереснее. С другой стороны, это капец какое сложное интервью, потому что к нему невозможно подготовиться на курсах или решив сотню задач на литкоде. Представьте, что соискатель - это тот же Лев Толстой или человек с очень развитыми коммуникативными навыками, наверное самый мемный пример - это Mike Ross из Suits
https://www.youtube.com/watch?v=tcx3zwhEIOw
или бабушка вашего соседа по этажу - кто угодно, и они полгода прокачивались в прохождении интервью на разработчика. Неужели вы не отличите человека, который реально что-то разрабатывал от человека, который просто красиво об этом рассказывает? Да, встречаются люди, которые на интервью не умолкают и очень складно говорят, но, блин, реальный опыт человека или если нет опыта, то его способности, мотивация видны, я не представляю как это можно скрыть. Конечно есть в некотором роде талантливые люди типа Элизабет Холмс, но она менеджер, и в разработке такое сложно представить. В конце концов, на испытательном сроке будет видно работает человек или нет.
На мой взгляд такое интервью проверяет реальный опыт человека. Или если опыта нет/мало, то позволяет понять чем он в принципе интересуется, как впишется в проект. В отличие от алгоритмических секций, которые проверяют одну единственную вещь - решал человек аналогичные задачки или нет. Если решал - это клёво, и наверное он не будет реализовывать алгоритмы с кубической сложностью там где достаточно линейной, возможно ему будет легче дебажить сложный код и т.д. Но сможет ли он писать понятный код - уже хз, хотя с этим проблемы бывают гораздо чаще чем с алгоритмами. Сможет ли в целом поддерживать качество кодовой базы, а не умножать хаос. Сможет ли он самостоятельно декомпозировать сложные задачи. Сможет ли нормально работать с аналитиками, другими разработчиками, тестировщиками. Меня лично это интересует в профессиональных навыках человека куда больше чем умение решать алгоритмические задачки.
kosmonaFFFt
02.12.2023 13:52Минус такой беседы - не про всё на прошлых проектах человек имеет право рассказывать, и никогда заранее не догадаешься, насколько глубоко такая беседа может зайти.
Ares_ekb
02.12.2023 13:52+2Мне сложно придумать такой пример. Если это только что-то связанное с гостайной, какими-то ноу-хау или чем-то не очень законным. Я ни разу не встречал таких людей. В любом случае я думаю, что нет никакого секрета в том как на проекте был организован процесс разработки, были ли аналитики, тестировщики, как велась работа с ветками в Git, как декомпозировались задачи, на сколько сложным было приложение (сколько сущностей в схеме данных, сервисов, модулей и т.д.), как была реализована аутентификация, авторизация и куча других технически вопросов, на которые вполне можно ответить, не раскрывая секретов. Или просто отказаться отвечать, это вообще не проблема.
kosmonaFFFt
02.12.2023 13:52Ну вот про текущий проект я про аутентификацию, авторизацию, архитектуру и кучу других вопросов не имею права рассказывать, хоть это и не гостайна, обычный NDA. Про процессы/работу с гитом, состав команды и что то такое же общее могу.
tolstoymv Автор
02.12.2023 13:52+1Все так!!
вот поэтому:
1 - я в статье предлагаю не давать алгоритмических задач, если это не критический навык для позиции
2 - увы времени не так много и если не обсуждать дотошно одну единственную мелкую тему, то очень легко не успеть докопаться, а потом узнать что человек ничего сам из того, о чем поет, не делал.
Я прям видел такое сам, один раз попался сам, и у знакомых примеры есть. А часами трындычать сложно - у кандидата есть жизнь и работа, а ты чаще всего не Гугл чтобы тебя терпели с таким подходом - там у кандидата офферов пачка обычно.
lllamnyp
02.12.2023 13:52+1Иногда некоторые предприятия нанимают сварщика и предлагают ему сварить вместе две простые детали. Но я ещё не слышал, чтобы кандидату на должность сварщика предложили рассказать, как он будет варить шов.
Fafhrd
02.12.2023 13:52А много ли сварщиков могут зарефакторить свой шов через пару недель, если деталь в продакшен ушла?
Работа на производстве несколько отличается от тапанья по клавишам и возможности откатить изменения в любой момент.
lllamnyp
02.12.2023 13:52+2Если в публичном апи реализовать контракт, который через неделю окажется с неприятными сайд-эффектами, его уже тоже так просто из реализации не выкинешь.
Ares_ekb
02.12.2023 13:52+1И не нужно спрашивать как он будет варить шов. Можно спросить как он варил швы раньше, как готовил поверхность, какие электроды использовал, какое оборудование, что если был нужен широкий или длинный шов (он варил их в один проход или в несколько), просто вел электродом по прямой или зигзагом, какая была техника безопасности, варил ли он швы в каких-то сложных условиях (на трубе под большим давлением, на большой высоте, в замкнутом помещении, в угольной шахте, ... - если такое требуется на объекте), как проверял качество шва, бывало ли такое что он сварил шов, а потом всё развалилось нафиг. Причём на эти вопросы нет правильного и неправильного ответа. Они просто показывают на сколько человек погружен в эту тему или хочет в неё погружаться.
Практические задачи - это наверное тоже хорошо. Но, блин, всё-таки между ИТ и сваркой есть разница. Сварщик на работе будет реально варить швы и если он не смог сварить тестовый шов, наверное не сможет сварить и реальный - возможно они не сильно отличаются.
А в ИТ тестовые и реальные задачи обычно не имеют вообще ничего общего. Алгоритмические задачи просто проверяют как человек готовился к интервью. Если не готовился, то он его не пройдет, каким бы гением разработки он ни был. А если готовился, то скорее всего пройдёт независимо от того на сколько отстойный он разработчик. И вопрос нафига такое интервью вообще, что оно проверяет? Знание алгоритмов - это безусловно бонус, возможно более полезный чем знание английского на уровне upper-intermediate, умение вышивать крестиком, водительские права категории Б и т.д. И я считаю, что разработчикам очень полезно прокачиваться в алгоритмах. Но это никак не основной скилл разработчика.
lllamnyp
02.12.2023 13:52И не нужно спрашивать как он будет варить шов. Можно спросить как он варил швы раньше
Это, кстати, два разных вопроса и опытные интервьюеры их различают и, в зависимости от сигнала, который ищут, задают либо один, либо другой.
в ИТ тестовые и реальные задачи обычно не имеют вообще ничего общего.
Мне показалось, что статья как раз пытается разобраться с этой проблемой. В каком виде для вас лайвкодинг был бы приемлемым, как этап найма?
Ares_ekb
02.12.2023 13:52Лично я думаю, что лайвкодинг используется в следующих ситуациях:
Если в компании очень большой поток кандидатов и нужно максимально просто и эффективно их отсеивать. Если отсеяли хорошего кандидата, ну, ничего страшного, завтра будет ещё десяток.
Если у самого интервьюера небольшой опыт или вообще нет опыта и он не может оценить кандидата, просто беседуя с ним.
Если собеседование на джуниорскую позицию без опыта.
Если нет времени, сил, желания запариваться с интервью, то гораздо проще дать очередному кандидату очередную задачку, чем думать, напрягаться, задавать какие-то вопросы.
Если хочется сделать интервью максимально объективным. Решил задачу за полчаса - ставим плюсик. Успел оптимизировать алгоритм - ставим два плюсика. Не сделал задачу - ставим минусик. В итоге суммируем оценки и превращаем кандидата в число. Сортируем этот массив, получаем N лучших кандидатов, делаем им оффер. Хотя у меня есть смутное ощущение, что при этом упускается что-то важное. У каждого кандидата свой уникальный опыт, свои уникальные качества, которые в итоговую сумму не попали, потому что мы даже не спрашивали соискателя о его проектах, интересах.
Вообще я наверное не против лайвкодинга и сам время от времени решаю какие-то задачки, что-то изучаю. И алгоритмическая секция наверное не сильно оскорбила бы мои чувства :) Но на текущем проекте я вообще не вижу никакого смысла давать людям алгоритмические задачи, для меня важнее на сколько человек может работать самостоятельно, декомпозировать сложные задачи, соотносить важность фичи и сложность её реализации, писать понятный код, который потом не нужно переписывать, что-то обсуждать, если задачу непонятно как делать или есть много вариантов решения.
tolstoymv Автор
02.12.2023 13:52+2С каждым вашим комментарием, все глубже понимаю, что вы хотите сказать и с большей частью соглашаюсь.
Моя позиция такая - чаще всего алгоритмы не нужны, но базовый навык программирования и владения своим инструментом важен.
Его и проверю.
Сеньор удалит тройки за 5 минут, тест бахнет еще за 5-10. На этом с кодом все, поехали обсуждать остальное, что я бы хотел про него узнать, у нас еще минут 40 будет минимум.
Kergan88
02.12.2023 13:52Моя позиция такая - чаще всего алгоритмы не нужны, но базовый навык программирования и владения своим инструментом важен.
Так вы делаете распространенную ошибку, связанную с подменой понятий. То, что подразумевают под "задачами на алгоритмы" - это _и есть_ задачи вроде вашей, на поиск троек. Т.е. проверка базовых навыков программирования.
Проблема в том, что уровень кандидатов настолько низок, что они даже этого не могут и потом рассказывают, как их завалили "задачей на алгоритмы". Реальные задачи на алгоритмы (то, что подразумеваете под ними вы или другой человек, который _умеет программировать_) на собеседованиях практически ни когда и ни кто не дает.
Т.е. на самом деле в данном случае обсуждается проблема, которой не существует в реальности. Она выдумана.
tolstoymv Автор
02.12.2023 13:52+2Абсолютно с вами согласен. В этой статье я предлагал обсудить именно лайвкодинг и обсуждение навыков кодирования.
Если человек ничего не спросил и просто сделал, это не значит что я не готов с ним работать, но это факт, который тоже стоит пометить.
Точно так же пометить, как он отреагирует если сказать ему, что задачу можно было понять по разному.
Но разумеется финальный вывод про работу с требованиями я делаю не на задачах а на отдельных для этого вопросах.
Продолжаю повторять - нужно проверять, то, что ты хочешь получить.
В данном случае кажется мне не стоило упоминать про коммуникацию вообще - вы меня поняли не так как я рассчитывал. :) Спасибо, за комментарий, иначе я бы этого не узнал.
kosmonaFFFt
02.12.2023 13:52+2import java.util.List; import java.util.Map; public class C5_Parser { private static final String dn = "CN=Ivanov Ivan Ivanovich,ADDR=Russia, Tatarstan rep., Kazan city, Some str.,bld. 404,OU=Development,DC=some-org,DC=ru"; public static void main(String[] args) { List<Map.Entry<String, String>> parsed = parse(dn); System.out.println(parsed); } private static List<Map.Entry<String, String>> parse(String dn) { return null; } }Делюсь задачкой для собеса - распарсить кривую DN строку, в которой внутри значений могут попадаться неэкранированные запятые. Задачка основана на реальных событиях, и в реальности решилась минут за 10. Если у кого есть похожие простые задачки, тоже делитесь.
Sad_Bro
02.12.2023 13:52В результате должно быть ключ значение да ?
DC -> ["some-org","ru"]Если так, то может быть лучше тогда результат складывать вMap<String, List<String>>?kosmonaFFFt
02.12.2023 13:52+1С таким API как в задачке должно быть две пары DC->"some-org" и DC->"ru".
Asker1987
02.12.2023 13:52+7Ещё одна статья про "алгоритмы не нужны" или демонстрация эффекта даннинга-крюгера. Подобное стремительное снижение стандартов скоро приведет к неспособности выдержать конкуренцию у индусов, которые делают то же, но просто демпингуют цены. Читать документацию они умеют не хуже нас, а в большинстве даже лучше, потому что английский язык для них официальный государственный. Соответственно, они первыми и быстрее хавают первоисточники. Но даже если предположить, что нет, то в чем наше преимущество? До сих пор это было советское наследие в виде мощного математического аппарата. Если копнуть во все успешные российские проекты - везде олимпиадники у корней. Тот же ВК - 2кратный чемпион мира по программированию. Но нет же, весь хабр испещрен статьями о ненужности алгоритмов. За последнюю неделю это четвертая статья. Сплошные фреймворковые программисты.
Hokum
02.12.2023 13:52+2Так в большинстве своем и нужны «фреймворковые программисты». Статья предлагает спрашивать на собеседовании лишь то, что релевантно тому чем придется заниматься. Нужны алгоритмы или ещё какие-то специальные знания - спрашивайте.
Обидно когда на собеседовании спрашивают и про алгоритмы и про проектирование масштабируемых систем держащих сотни тысяч запросов в секунду, а на практике надо перекладывать сообщения из очереди в очередь с частотой десять сообщений в секунду.
BugM
02.12.2023 13:52Почти хорошо. Будет проблема с некоторыми людьми вроде меня. Я не включая мозг за минуту бахну однострочник на стримах и буду глупо смотреть на вас с вопросом: А что на самом деле делать-то надо? Потом уже постараюсь договориться и выяснить а что имелось в виду на самом деле. Вероятнее всего начну говорить про проблемы сайд эффектов внутри стримов. Мол падают, оборачивать правильно надо, обрабатывать что вернулось и все такое. Уточнять что-то когда написать занимает реально минуту можно и не сообразить.
Потом подключение тестов. Я попробовал подключить junit в чистую идею. Ну в целом за один запрос в Гугл и минут 5-10 оно заработало. С нервами будет посложнее и подольше. Люди в среднем подключают тестовые библиотеки примерно никогда. Стоит намекнуть что это стоит сделать заранее.
Остальное все просто хорошо.
tolstoymv Автор
02.12.2023 13:52Вы бахнете однострочник на стримах. Я буду в восторге. Я даже буду на вводной к задаче предупреждать вас, что задача "ровно на столько простая", просто напишите. Затем мы напишем с вами тестик другой. И пойдем уже погружаться в детали или иные навыки которые мне от вас нужны, которые тоже надо как-то глянуть.
За 5 минут я узнаю что имплементация кода с коллекциями по инструкции не представляет для вас трудности и вы вообще в жизни писали тесты.
icya
02.12.2023 13:52Прошу прощения, но, как мне кажется, задача про "удаление троек" это такая же литкод-задача, как и надоевшие всем задачи на деревья/палиндромы/скобки (моя первая ассоциация, которая мне пришла после прочтения условия - замысловатая поза йога).
У меня есть несколько простых задач. Часть специфична для языков, библиотек и кейсов (ну и опыта кандидата).
А можно пример с одной из таких задач, специфичной по кейсу, для джун+/миддл (просто любопытно)?
sergiodev
02.12.2023 13:52Я бы тоже тесты в main написал, т.к. это намного проще и не надо вспоминать как там пользоваться JUnit (на последнем месте работы не писали тесты).
tolstoymv Автор
02.12.2023 13:52Ну я же вижу что вы делаете! В смысле я вам скажу, а давайте пожалуйста тесты, как только увижу что вы полезли в мейн.
Если у вас проблемы с тест фреймворком, то у вас нет сейчас навыка, которого я жду на позиции - если вы сможете быстро вспомнить за пару гуглежек - ну и супер
denim
02.12.2023 13:52TL;DR - замените ваш литкод мидиум на литкод изи, нажимайте на софт скилы во время кодинг интервью
В сухом остатке - софт скилы норм не поняли и кодинг не потестили как надо.
tolstoymv Автор
02.12.2023 13:52софт скилы надо проверять отдельно, то что простая задача говорит о кандидате все - этого никто не утверждал.
если вам нужен код на уровне выше чем литкод изи - значит нужен, к вам вопросов нет, просто будьте уверены и задачи подбирайте похожие на ваши проекты и кодовую базу.
ToSHiC
02.12.2023 13:52Что-то зачастили посты про задачки и собеседования.
У меня для противников задачек такой вопрос. Эти задачки (в том числе та, что в этом посте) - они уровня задачей из ЕГЭ по информатике, ну или после первого курса программирования в институте/колледже такие задают. Т.е. они правда про самые базовые знания и понимание того, как работают самые базовые типы того языка, на котором, по заявлению кандидата, он постоянно пишет код. Ровно как базовые упражнения на площадке для водителей, типа параллельной парковки, или сварить 2 пластины для сварщика. Вы считаете, что спрашивать такие базовые навыки, которыми обладает студент, если не школьник, у человека, который заявляет, что он профессионал, некорректно?
Я частично понимаю заявления про "я же пишу код в IDE, а тут меня на бумажке заставляют писать". Но вы же код-ревью не в IDE, делаете, правда? А там вы как понимаете, что ваш коллега аргументы функции не перепутал? Наверное, самые популярные то вы запоминаете, да?
Ну и это один из самых объективных и прозрачных видов интервью. В "разговоре по душам" или в рассказе про прошлый опыт возможно огромное количество человеческих ошибок, как на стороне кандидата, так и на стороне интервьюера, а код - вот он, перед всеми. Как пластины у сварщика.
Kernell
02.12.2023 13:52Забавно, человек из Ozon рассказывает про плохие собесы, в то время как на собесах Ozon, HR по телефону задаёт вопросы с листочка, про сложность алгоритмов List в C#, и это на должность веб-разработчика в логистику.
12rbah
02.12.2023 13:52задаёт вопросы с листочка, про сложность алгоритмов List в C#,
Пока тред в faang не сменится и там не скажут что "лучше спрашивать про конкретную работу/проект" вряд ли что-то поменяется. У меня спрашивали какой алгоритм внутри сборщика мусора в го, я мб чего-то не понимаю, но хз зачем это знать, т.к. я явно не буду в исходниках компилятора пытаться исправить что-то
tolstoymv Автор
02.12.2023 13:52+2ну моя статья не в корп блоге Озона, это мои личный опыт и мнение - за шарповые вакансии в логистике я вам не поясню (
oldmurik
02.12.2023 13:52Вот я одного не понимаю. Для программирования берут программиста. Почему для интервью берут не интервьюера, а снова программиста? То есть берут человека, без опыта, без знаний и заставляют работать. Каков результат? Чаще всего плохой. Вы же не скажете интервьюера за питон проверять ошибки в коде. Потому и дичь творится на собеседованиях, что никто не знает, что происходит. Ни кандидат, ни представитель компании.
tolstoymv Автор
02.12.2023 13:52Именно - я тоже так думаю, что собеседовать - это отдельный навык. Его надо тренировать. Отсюда и статьи и тренинги и вся хурма!
boov
02.12.2023 13:52начинает, мыча, for-циклы крутить.
А что не так с for-циклами?
Я не из мира java, но предположу, что при работе с коллекцией там есть встроенные механизмы, которые могут хорошо параллелиться, что даст выигрыш на реально больших коллекциях.
tolstoymv Автор
02.12.2023 13:52+1С фор циклами проблем нет. Проблема с мычанием.
Написать на форах замену map, filter и тд это сложнее чем махать стандартными алгоритмами, если человек сходу быстро написал - красаучик.
zedsh
02.12.2023 13:52У меня это простая задача на области видимости, на понимание отличия локальных и глобальных переменных в языке. Не решают 80%.
Anfet
02.12.2023 13:52Прочитал задачу и сразу стали интересны запятые. Все тройки - это все цифры "3" или тройки чисел? Почему спрашиваю. Далее идёт фраза "для всех нечётных". Это странно. Тройка нечетна изначально.
Вызывает печать. В какой момент? В момент удаления или когда-то потом.
Удаляет семёрки. Тут понятно.
Умножает все на 2. Ок. Разве что оверфлоу может быть. Мало ли какая там коллекция. Что напишем в этом случае?
Интересно
DevNul
02.12.2023 13:52Признаюсь, если даже предлагают что-то там начать писать на звонке, то я отказываюсь. Для этого всего у меня есть GitHub, который скидываю всегда заранее.
Правда я и варюсь в этом всем почти 15 лет
tolstoymv Автор
02.12.2023 13:52Если ваш гитхаб большой и релевантный, то это большой плюс и для позиций где надо прям имплементить логику это тоже инструмент знакомства с вами.
Хотя лично я попросил бы тройки удалить все равно - в вашем сетапе и с имеющимся навыком вы бы сделали это оч быстро.DevNul
02.12.2023 13:52+3Так я как раз про то и пишу, что я бы просто отказался.
Лично я не могу переключать голову из режима говорения в режим написания моментально, а также собеседование - мягко говоря не самая приятная штука. Человека первый раз вижу вообще и тд
У кого-то общительного, может, это происходит без проблем, но у многих - нет. Это вызывает только раздражение и отторжение.
А то получается как-то странно, вот куча кода разного в репозиториях, а никто даже не захотел посмотреть и просит сделать что-то, стоя над душой. Выглядит часто больше как попытка самоутвердиться и поднять чувство значимости.
Сразу ощущение, что как-то не по пути нам и тд. А то тут часть волос уже седых проскакивает, а тут снова как 15-20 лет назад на экзамене. Хотя нет, на экзаменах-то вопросы заранее известны и можно подготовиться - кажется, что это не просто так))
К счастью работ море вокруг с нормальными ЗП и людьми.
Да и есть альтернативы написанию - это вместе посмотреть на кусок плохого кода и обсудить как его исправить. Собственно я так и делаю иногда, когда сам провожу - это воспринимается абсолютно нормально людьми.
Особенно бывает интересно, когда уже начинаю я в ответ спрашивать человека, который собеседует меня, и внезапно оказывается, что он сам-то ничего не может ровным счетом сказать и написать. И, как деликатно и интеллигентно выше выразились, сам начинает "мычать".
Уж извините, но когда человек про других людей говорит, что они "мычат" - сразу как-то все понятно становится
tolstoymv Автор
02.12.2023 13:52Касательно формат - о да, от задач зависит - и посмотреть код, как вы предложили, это отличная практика, особенно если ищешь человека которому надо смотреть много кода.
И "мычать", действитель, не самое удачное слово. Спасибо, что указали мне на это.DevNul
02.12.2023 13:52+2Я не хотел обидеть - поэтому извиняюсь, я вообще комментарии никогда почти не пишу никакие. Но меня прям это слово резануло пока читал в дороге, что даже написать решил что-то в комментарии и тд
Pavel_nobranch
02.12.2023 13:52Проходил недавно собеседование с отрицательным результатом. Много думал. hh и Мамба это одно и тоже. Собеседование и продажи это одно и тоже. А я в продажах не работал. Скачал книгу 49 законов продаж. Узнал то, что сам бы никогда не додумал. По итогу на сайте своего проекта выкинул страницу где я "рисовал чаек за клиента" (Правило № 18). В общем извлек значимую пользу из отрицательного результата.
OlgaVivanova
02.12.2023 13:52Я бизнес-аналитик, немного знаю Python и это мой первый комментарий, поэтому:
# удаляет из коллекции все тройки, для всех нечетных чисел вызывает побочный метод печати в консоль, удаляет все семёрки и возвращает коллекцию-результат def ozon_interview(a): a = [i for i in a if i != 3] print(*[i for i in a if i%2]) return [i*2 for i in a if i != 7] # пусть на вход подается список целых чисел через пробел: print(ozon_interview([*map(int, input().split())])):-)
profFortran
Главный и единственный вопрос: нафига мне этот церебральный коитус? Я лучше пойду к тем, кто не будет мне мозг выдуманными под веществами задачами сношать.
Sad_Bro
А почему нет? Это частая ситуация когда человек не понял аналитику и бросился делать и хорошо если он возникающие вопросы потом задаст в ходе реализации, а не спустя неделю выкатит свой вариант "как он понял".
Честно говоря такое собеседование кажется целесообразным, не перекачивают задачками алгоритмическими, практические задачи, какие то поведенческие вещи тоже проверяются.
tolstoymv Автор
Церебральный коитус? Почему?
ItsNickname
Потому что для уважающего себя человека решение подобных задач оправдано только если он в Гугл на позицию ведущего разработчика собеседуется.
Почему я должен каждому барану доказать что я не мошенник? У меня есть профильный диплом и стаж работы. Что вам ещё надо? Почему токарь на заводе просто показывает диплом, почему бухгалтер просто показывает диплом и опыт работы, почему буквально везде достаточно диплома для доказательства своей компетенции?
В ИТ уже снова пришли "нужна какая-то система сертификации что человек не дебил" так вам дурачкам давно дали такую сертификацию. Называется диплом об образование высшем или среднее-техническое.
tolstoymv Автор
Я недавно перед школьниками выступал и думал на тему диплома и ИТ. И вот что накумекал:
Я универ заканчивал, когда язык Go публичным стал.
React выпустился первый раз, когда я уже работу работал.
Так что если вы ко мне придете и скажете что у вас диплом и стаж большой, а у нас стек современный и вы сказали, что его трогали, то вот простая задача. Предельно простая, но не проще.
Условному куберу 10 лет нет. В легаси проектах используется не он. Так что позвольте вас опросить, чтобы потом никто не пожалел.
Но и альтернативу рассматривать, полагаю стоит. Типа если чувак имеет релевантный гитхаб (редко) или диплом специфический под задачу...
То есть я продолжаю гнуть свою линию, что надо плясать от вакансии и желаемого кандидата.
ItsNickname
А причём тут технологии? Меня в институте учили как работает компьютер, архитектура ЭВМ, матанализ, ТФКП, вычислитеная математика, дискретная, теорвер, теория множеств, теория кодирования, сетевые технологии, схемотехника, алгоритмика(не алгоритмы), алгоритмы и структуры данных(это вообще первый семестр).
Я вообще не изучал в вузе никаких языков и технологий. Зато учил такие вещи что мне теперь все ваши докеры, куберы, Го, Расты и 100 ЖС фреймворков это буквально "мы изобрели велосипед". Мне достаточно просто устного описания любой "новой технологии" чтобы сказать вам в учебнике за 60го или 70го года она описана.
У вас представление о вышке как-будто там курсы для войти, но там вообще не учат ни языки, ни фреймворки. Там учат людей которые могут написать язык или фреймворк, а также освоить любой из них за неделю до уровня джун+ и за месяц полностью.
MaksimMukharev
Если вы не имеете практического опыта с курьером, то решить задачу на требуемом уровне у вас не получится, не хватит практического опыта. Соответственно, нет смысла вас нанимать на определенные задачи и надеяться на то, что вы сможете настроить кластер с необходимыми характеристиками. Учить, вероятно, вас может быть некому, а тренироваться на крупном проекте вам никто не позволит.
Из этого и складывается ограничение.
ItsNickname
Мы про джунов и интернов говорим или че? Если человек с 5+ годами стажа не может за 2 дня разобраться в такой просто вещи как докер или кубер, то он имбицил.
Я не понимаю какие такие волшебные навыки я должен иметь? Знать и уметь все на свете нереально. Для проверки практических навыков достаточно простого вопроса "вы работали с [CENSORED]?" Эти вопросы может задать и [CENSORED] по телефону
GrakovNe
Снимите пальто, пожалуйста. Вы заходите в сообщество, называете людей, цитирую, "баранами", а про себя говорите так, будто знаете все технологии в мире
Если так, вам ничего не мешает пройти техническое собеседование в любую компанию, кроме гордыни
Но почему-то мне кажется, что на собеседовании выяснится что "этивашигорасты" - не единственное, что ожидают от кандидата и без умения в вежливое общение и уважение к другим участникам беседы, даже самые исключительные инженерные навыки блекнут
GrakovNe
Потому что не просто показывает
В Омске на агрегатном заводе, который делает много чего серьезного и промышленного, после базового изучения анкетки (весьма дурацкой, кстати) и чтения дипломов, кандидата подводят к станку и просят выточить деталь по не очень сложному чертежу. Станок обычно хороший, но ручной, без ЧПУ и автоматики
Если токарь не справляется с условной втулочкой или не может нормально прочитать чертеж, с ним вежливо прощаются, несмотря на его разряды, заслуги и дипломы
Tim_86
Пожалуйста, напишите, как вы предлагаете проводящим собеседования отсеивать кандидатов с красивым резюме, приписанным или фейковым опытом работы, но не имеющих реальных, практических знаний, умений и требуемого опыта.
ItsNickname
Поговорить с ними? Если вы сам специалист высокого уровня, то вам достаточно просто беседы чтобы понять что человек вам врёт. Коли вы так не можете значит вам рано проводить собеседования по причине недостаточной компетенции.
tolstoymv Автор
это зависит от проверяемых умений. задача на удаление троек показательна в плане реализации алгоритмов и написания простой бизнес логики, позволяет сразу опознать определенный контингент.
про другие навыки и умелки будем рассуждать в следующих выпусках.