Comments 64
Много и подробно, прочёл с интересном.
А водятся относительно «идеальные работодатели», где описанные квесты проходят нормально, по-человечески?
Ну, у нас на позицию программиста код писать не просят. Собеседование это именно беседа с менеджером. И там сразу видно, подойдёт ли компания человеку или человек компании.
А с какого момента у вас все-таки просят писать код?
Когда человек уже год проработал на позиции программиста? Никогда?
Писать тупой круд можно научить и обезьяну, а вот найти адекватного участника команды довольно тяжело.
Хлопаю стоя!
Дык правильно, на тупой круд можно и нанимать адкватных обезьян, все верно.
Я думал, тут речь про собеседование на позицию разработчика, а не джейсоноукладчика.
С момента выхода на работу, пробный период полгода. Если не смог-не сработались, то досвидания. Но такого практически не бывало, ибо неадекватов и без кода видно.
В принципе, мне чаще попадались как раз нормальные. Тех. беседа по теме будущей работы с учетом резюме, вопросы по делу и не дублируются. Тестовое сделал за пару часов, сразу сказал, что буду делать на фреймворке, который знаю. Норм отнеслись, ибо дело не в фреймворке.
Во-первых, спасибо автору за статью - прошёлся по больному.
По поводу "идеального" интервью: мне на текущей работе при собеседовании позадовали вопросы, а потом просто посмотрели в реальном времени, как я пишу код. Дали простую задачку типа "тайный Санта": на вход список строк, на выход - словарь ключ+значение. И про типы данных, и про логику, и про сложность поговорили. Было приятно и мне, и им. Минус в том, что высокого менеджера или человека с обширными знаниями не было, поэтому часть скиллов оказалась невостребованной, о некоторых вещах так и не узнали.
А третьего дня проходил интервью с сеньором, но это было неприятно и мне, и ему. Вопросы от "расскажи про все принципы solid", до ковариантности делегатов, работы мьютексов и уровней изоляции транзакций, 2 с половиной часа. В какой-то момент я перестал скрывать недовольство от его "матрицы скиллов", где нужно ставить галочки.
Сделал для себя замечание: надо при таких вот "коллоквиумах" считать количество вопросов, которые гуглятся за 1 минуту. Если их больше 70%, вряд ли компания ищет инженера, умеющего моделировать и решать сложные технические задачи. Тут скорее подойдёт студент-выпускник, который хорошо пользуется stack overflow. Или это просто некомпетентность иньервьюирующего?
Здесь, я нашёл для себя оптимальную формулу. Выслать кандидату до общения небольшое техническое задание (2-4 часа активного кодинга).
Нет. Данное решение не скэйлится. Если вам надо нанимать десятками, то интервьюер загнётся или надо нанимать выделенного человека — жирно. Как скоро интервьюер начнёт «забивать» на проверку таких тестовых, задумывались? Если человек в продакшене пашет?
На тестовое «покодить» максимум 15 минут, притом пофиг записать в блокноте/IDE, рассказать как работать будет или псевдоколом, главное — донести решение до интервьювера.
Вопросы Да / Нет. Если вы задаёте бинарный вопрос и ожидаете неких объяснений — предупредите об этом собеседуемого. Несколько раз получал отзыв от рекрутёра, о том, что ожидали от меня большей проаквтивности именно в вопросах такого формата. По возможности старайтесь избегать таких вопросов.
Задавать уточняющие вопросы — это нормально. Не понятно, уточняйте. Можно давать развёрнутые ответы, например: «Вася Пупкин, работал ли ты с EF?” Можно ответить да\нет или: «EF — это ORM. Все орм строятся по примерно единому подходу — маппинг данных из бд на дто/поко, конкретно с еф не работал, но вот даппер активно использовали…»
У вас в статье есть хорошие выводы как про «предупреждайте», но материал не структурирован, скачете туда-сюда.
А в чём проблемап того, что "решение не скэйлится"? Если поток кандидатов небольшой (1-2 в неделю и меньше) — оно подходит очень хорошо. Как по мне — плохо как раз пытаться найти серебряную пулю, которая подойдёт и стартапу из 5 человек, и огромной компании. Разным масштабам — разные решения.
Разные требования для разных масштабов — да. Возможности скейла и оптимизации надо закладывать сразу или оговаривать, что данное решение применимо для определенного спектра задач. Плюс скейл проще использовать на задачи для 1-2 в неделю(стартап) и 10-150 в день(кровавый энтерпрайз). В первом случае просто ряд шагов из процесса можно выкинуть.
Скажите что «преждевременная оптимизация корень всех зол»(с)? XD
В моей голове, десятками нанимают компании где работают сотни. И если необходимо нанять 10-20 человек, то в компании на несколько сотен человек, выделить одну человеконеделю на проведение собеседований, наверное, не так и страшно.
Для меня интервью — это нанять человека, который, с некоторой вероятностью, начнёт приносить пользу. Во многих случаях, «покодить 15 минут» даст меньшую точность чем 2-4 часа тестового задания. И в случае найма 10 человек лучше, чтобы эти 10 человек и остались на долгий срок в компании, а не начинать поиск через несколько месяцев снова, когда оказалось, что за 15 кодинга было принято неверное решение со стороны интервьювера. Но опять же, нет серебряной пули и всё нужно адаптировать под вашу конкретную ситуацию.
По части уточняющих вопросов:
Можно ответить и «EF — это ORM. Все орм строятся по примерно единому....», а можно начать рассказывать про Lazy Loading, или про контекст или ещё много про что. Но, по моему мнению, можно сразу задать вопрос, который не будет требовать догадок от собеседуемого в какую сторону начинать думать.
Интервьюверу тоже стоит готовиться к собеседованию и задать вопрос «Работали ли вы с EF?» — на поверхности, а вот хороший вопрос, который заставит вас не только вспомнить некоторые знания, но и подумать — это уже «Совсем другая история».
Даже не так. У нас отдел — порядка 700-800 человек. Нанимают десятками. Но наш проект, как и большинство других, сильно меньше, человек 10. Найм — один человек в год примерно. Интервью при этом проводит специалист из проекта, то есть занимается он этим от силы раз пять в год, ну может 10, большего потока кандидатов не припомню. А такого чтобы сотня человек работала реально на один проект, я вообще никогда не видел — всегда есть более мелкие команды, которые и определяют тонкости требований к человеку, которым им нужен.
выделить одну человеконеделю на проведение собеседований, наверное, не так и страшно
Слышали такое слово экстрамайл?
Да не страшно выделить, но есть другой нюанс люди проводящие собеседование устают, выгорают. Учитывайте нагрузку в продакшене и то что IT компании — не благотворительные организации. Собеседования всегда идут как дополнительная нагрузка. Учитывайте что чем крупнее компания, тем более жесткие KPI по финансовым показателям. Поэтому когда вы посчитаете стоимость найма на скейле — ужаснётесь. И никто не будет давать время только на собеседования. ¯\_(ツ)_/¯
Для меня интервью — это нанять человека, который, с некоторой вероятностью, начнёт приносить пользу
Что значит для вас пользу? Для меня пользу — вполне измеримые метрики:
- Будет работать в компании от года и более;
- Утилизация 90% времени в год;
- Есть ещё несколько метрик, но они достаточно специфичны.
Останутся ли люди в компании на длительный срок — это ряд факторов. Давайте рассмотрим пример: наняли вы человека, но заказчик его поливает грязью. Просто сам заказчик такой, любит унижать людей в открытую. Как думаете человек которого явно унижают долго терпеть это будет? Поэтому вопрос не только в найме.
Заодно научитесь работать на рынке кандидата. У него 10 предложений, а то и более. Вы предлагаете Х денег, но и ООО «Рога и копыта» предлагают Х денег. А описание проектов у них круче чем у вас. Наймёте ли вы кандидата с тестовым в 4 часа? Сомневаюсь. В «Рога и копыта» тестового нет.
Да и позволю себе нескромность, как человек у которого больше 400 интервью за плечами. Как правило мне достаточно 30 минут чтобы понять стоящий кандидат или так «мимо крокодил». Осечки случаются, но подбив статистику, меньше 4%. Просто практика.
А где же случай, когда дается тестовое задание на несколько дней, а потом работодатель исчезает даже без обратной связи?
Уже было такое пару раз.
Почему бы и нет, если задание выглядит интересно, и коротко. У меня, впрочем, потолок гораздо ниже, чем у автора — если делать дольше чем на пару часов, то это сразу же "всего доброго".
Вообще, тестовые задания — это не так уж и плохо, в том плане, что они позволяют отсеять контору на ранних этапах общения. Задание невменяемых размеров? Плохо сформулировано? Написано (если это задание вида "исправьте") ужасающим кодом? Ну и отлично же, просто шлем контору лесом и идём дальше. Win-win.
Иногда это довольно здорово работает, типа как я общаюсь с конторой, позиционирующей себя сверхмодной, сверхмолодежной, и сверхпрогрессивной, и они высылают тестовое вида "поправьте этот код, чтоб он работал", а код написан на окаменевшем JS (везде var, например) способом "я тут за 5 минут что-то накорябал и потом удалил 2 строчки из накорябаного". И всё сразу становится понятно про контору.
Какое по вашему мнение идеальное задание? Можно пример?
а код написан на окаменевшем JS (везде var, например) способом «я тут за 5 минут что-то накорябал и потом удалил 2 строчки из накорябаного». И всё сразу становится понятно про контору.
Так этот код может действительно написан лет десять назад за десять минут и больше его никто не трогает, ибо его цель — отсеять неадекватов не могущих понять даже такой код, и ничего более.
Так этот код может действительно написан лет десять назад за десять минут и больше его никто не трогает, ибо его цель — отсеять неадекватов не могущих понять даже такой код, и ничего более.
Ну и прекрасно. Зачем мне идти в контору, которая даже не в состоянии написать задание, соответствующее своему декларируемому имиджу? Пускай и дальше "отсеивают".
Играть в телепатию вида "почему у вас такое задание странное" еще можно было бы, если б работников было бы гораздо больше рабочих мест. Но ситуация запредельно обратная, и в случае даже малейших сомнений гораздо проще сказать "нет, спасибо" и идти смотреть предложения дальше.
Общий знаменатель — бэкенд / фуллстек разработчик с 6-8 годами опыта
«Немного» по разному проходит. С джуном никто разговаривать не будет, пока он не выполнит тестовое задание, предлагать же тестовое задание условным сеньерам перед собеседованием — значит отсеять 90% кандидатов. О чем говорят сами HR.
Я делаю, если это из последних этапов и мы уже обсудили границы предложения по цене.
Не вижу ничего плохого в том, чтобы показать навыки в удобном работодателю формате, если я уверен в том, что мои запросы будут удовлетворены клиентом.
Для себя я это определяю, как часть моей услуги по разработке.
Я когда буду искать работу сделаю. Во-первых мне прикольно, во-вторых можно сделать одно и показывать его сразу всем, в-третьих сразу проверяет компанию на предмет постановок ТЗ и возможности диалога.
n-лет назад так делал, отлично зашло. Попросили todo app на ангуляре, я сделал практически без стилей. На вопрос "а чо так ужасно выглядит" честно заявил, что для тестового задания выглядит нормально, всё работает и код они могут посмотреть. И сразу строчку в резюме, типа "вот такое приложение сделал по такому заданию", бац.
Потом, правда, уже на ИРЛ собеседовании там был слишком счастливый менеджер и слишком грустный программист, который спрашивал меня сколько будет 2 + '3', так что пришлось отказаться от оффера.
Вообще не понимаю минусов в тестовых заданиях для кандидата — если не пытаться услужить всем, а делать одно и именно то, для чего оно предназначено — показать свои архитектурные и кодовые умения.
Вечером поковырял 2 часа, простой пример предоставил. Работаю в компании уже много лет.
Как тестирую или отсеивают тех, кто в последствии не будет работать…вообще никак?
Я говорю про таких кандидатов, которые за год или более не смогут ничего дать взамен зарплате.
Вопросы Да / Нет. Если вы задаёте бинарный вопрос и ожидаете неких объяснений — предупредите об этом собеседуемого.
Был такой кандидат как-то.
- Приходилось ли работать с тем-то и тем-то?
- Да.
...
...
- А насколько плотно?
- Очень плотно.
...
...
- А можно поподробнее?Очень тяжело было беседовать, ощущал себя фашистом, пытающим партизана.
Какой вопрос - такой и ответ. Попробуйте формулировать мысли конкретнее.
На самом деле нет. Интервью подразумевает в первую очередь диалог, а не допрос с пристрастием. Зачем мне коллега, который даже к собеседованию подходит с позиций итальянской забастовки?
Хороший разработчик должен уметь думать и размышлять. И именно это в первую очередь важно на техническом собеседовании, а не знание определений всех буков SOLID'а, например.
А "делаю шо велено, а шо не велено, то не делаю" — таких пучок за рубль в базарный день, но спасибо не надо.
Работник должен догадываться что от него хотят и рвать зад делая ненужную работу, которую менеджер потом просто выбросит в урну, цмакая языком? Как поставили задачу - то и получите. Взаимно скажу, что неадекватных работодателей даже больше, чем неадекватных работников. Особенно смешны, когда приходит человек на работу, а ему говорят "ну вот, ищи себе сам занятия, делай /не понятно что/ и жди /непонятно чего/.
Вы очень знатно передёрнули. Но раз уж свели к работе, то ладно, давайте поговорим за неё.
Вы задумывались, чем отличается миддл от синьёра? Даю подсказку — не опытом и не знаниями. Главное отличие в том, что мидл просто пишет код(желательно хороший), а синьёр решает поставленную задачу. Именно за то ему и платят его не гуманный прайс, что он не "догадывается и рвёт зад", а погружается в задачу, анализирует, декомпозирует и предлагает наиболее правильное решение.
Теперь что касается собеседования. Техническое интервью — это не сдача ЕГЭ и не заполнение чеклиста про технологии (они все и так в резюме перечислены). Это попытка выяснить, что за человек перед тобой. Насколько он разбирается в тех самых технологиях, которые в резюме указал. Насколько он способен принимать решения и обосновывать их. Всё это практически невозможно выяснить, если человек полностью закрыт и каждое лишнее слово приходится тянуть из него клещами.
Ну и стоит отметить, что за проведённые мною… достаточно много собеседований, практически никогда не возникало проблем с взаимопониманием и коммуникацией (спасибо HR за фильтрацию). Почему-то в большинстве своём, для кандидатов (некоторые из которых на голову меня круче), не составляло труда поддерживать конструктивный диалог и "догадаться", что на вопрос "приходилось ли работать с тем-то?", ожидается не "да/нет", а "да, на таком-то проекте вот так-то использовали с такими нюансами" или "нет, но, емнип, там то-то и то-то".
В Украине сейчас на зарплату меньше $7-8K на тестовое не согласится наверное вообще никто, учитывая что предложения дают всем подряд через час после краткого собеса из-за нужд рынка, который снижаться не будет.
Про пункт имитации важности. На моём опыте были люди, которые разговаривали на техническом языке с менеджером. И тут возникало недопонимание. В некоторых компаниях разработка общается с менеджментом через переводчика в лице тех лида, но не везде это так. Поэтому скил простыми словами объяснить сложную штуку весьма востребован бывает) Поэтому такие вопросы и задаются. Там, где это важно. Имитация важности тут не причём)
Интересная статья. Как думаете тестовое задание на 2 недели это перебор или норм?
Если 2 недели каждодневого кодинга, то это однозначто нет. Слабо представляю ситуацию, когда в течение 2х вы работаете на 2 ставки без внятных целей и мотивации.
Задача звучала примерно так: «разработать модуль расчета зарплаты в ERP системе» с нуля.
Если на junior/middle позиции тестовая задача в некоторых случаях и имеет смысл, то для senior/lead позиций это уже моветон.
отнюдь.
на само же деле… реально… ну может небольшой процент от числа рекрутеров и «влиятельных лиц» прочитает… да. это вероятно.
но почти уверенно можно утверждать, что даже прочитавшие — не будут на практике что либо менять.
и вот почему:
1. «у них» и так все хорошо. кажущаяся нехватка «айтишников» реально не так страшна, судя по тому какой реальный бардак в части рекрутинга творится на кадровом рынке — а если точнее — так долго этот бардак не может выжить, если бы это реально осложняло нанять кадры и как следствие срывало бы бизнес. А это значит, что особо никто не будет что-то менять. Да и каждый год «появляются» все новые и новые тысячи если не десятки тысяч голодных до сеньорских зарплат вчерашних студентов. Так что наиболее вредные и наиболее жадные «рекрутеры» по сути всего лишь ждут не дождутся пока соискатели начнут соглашаться кодить и прочим айтишничеством заниматься — за стандартные 50 тыщ. ру. («а че, мне плотят 50 тыщ, а ему 100...150...250...350 ??? за что!!??»)
в общем, если точнее — они просто троллят соискателей, в ожидании «ну вот этот вроде пусечка что надо». и статьями на хабре это никак не остановить.
2. Собеседуемые на все смотрят только со своей стороны, забывая что у «противной» стороны (рекрутеры и влиятельные лица) есть свои резоны вести себя так как ведут (например те что указаны выше или иные резоны). Причем довольно часто в этих «резонах» вообще нет никакой рациональной логики. На стороне работодателя как правило просто «не заморачиваются» и делают как делается. а когда какойто «умник» начинает качать права — то этому соискателю как правило отказывают с вердиктом «фууу… какойто он токсичный»… и некоторым даже так и говорят в лицо, лично мне не говорили, но я полагаю, что некоторые «молчаливые» отказы были именно по этой причине. впрочем я не жалею — и даже рад, что отказывали. ибо хоть я и не спорю обычно… но иногда (редко) бывает так, что чтото сказать все же приходится…
Вывод — все это бесполезно. Статьи на хабре. Писанина в телеграм в тематических чатах.
Вообще бессмысленно. потому что, пока бизнес не начнет реально нести потери — от таких горе рекрутеров и «влиятельных лиц» — никто ничего не изменит.
ps
Да я понимаю, почему пишут такие статьи. Ведь статьи такие логичные. Все по сути верно.
Тем более, как-то обидно когда вроде вот — отличная вакансия, а тебя «зарубили»…
Но реальность иная… увы. Примут вас или нет — это часто совсем не о том, как хороши ваши навыки и насколько вы соответствуете требованиям вакансии.
Чаще вас зарубят потому что вы «токсичный какой-то… и еще требует какуют то обратную связь… давай кыш отседа!»
Но глядя на себя в прошлом, и сейчас, могу точно сказать, что я тот человек, которому вот такие статьи пригодились. Возможно это просто ошибка выжившего, но даже если найдётся 1 на тысячу, который попытается проанализировать написанное — это уже больше чем ничего.
Думаю что многие рекрутеры (говорю про технических людей, так как знаю больше про них) на самом деле умнее, именно как рекрутеры, чем иногда кажутся рекрутируемым. Например кажущиеся нечеткими (предел конечно есть) вопросы помогают понять в каком направлении человек начинает мыслить, и иногда это очень способствует пониманию его реального опыта и знаний. Мой собственный опыт показывает, что вопросы из серии "порассуждать на тему" вполне полезны.
При этом естественная реакция человека, которого не приняли, искать недостатки в работе рекрутеров. Это работает свого рода мультипликатором. Те, которых приняли, редко задумываются о недостатках процесса.
По моему опыту практика тестовых заданий - едва ли не наиболее бесполезная интервью-практика. Если подумать, тестовое задание дает минимум дополнительной информации о кандидате. Давать большое тестовое задание неэтично - кандидат может (совершенно справедливо) разозлиться и помахать компании ручкой. Если тестовое задание небольшое - где гарантия, что кандидат сделал сам а не скомпилировал кусочки кода со stack overflow?
Если тестовое задание используется, чтобы интервьюер потом обсудил его с кандидатом - это, простите, выглядит как лень интервьюера.
ИМХО не надо ничего выдумывать, надо проверять базовые знания - решать задачи, обсудить вопросы дизайна, поговорить о прошлом опыте - это заменит тестовое задание, можно ж попросить рассказать о каком-то проекте, которым соискатель гордится. Всем выгода - соискатель будет рад рассказать о предмете своеей гордости, а интервьюер будет рад покопаться насколько соискатель глубоко в этом проекте разбирается.
Все эти поиски кандидата, который готов выдать результат прям завтра - это либо от лени либо от нежелания компании вкладывать хоть чуть-чуть в развитие кандидатов.
Может не случайно Amazon, Google, Facebook и Apple не дают никаких тестовых заданий?
И чем плох вариант решения задачи копированием со стаковерфлоу? Или ваша компания не использует гугл и сторонние сайты, а пишет все с нуля сама ?
Придумайте такое задание, которое не скопировать со стаковерфлоу . А решать базовые задачи - что это показывает ? То, что в вашей компании базовые задачи на сортировку пузырьком ? Или , вы пишите самописные костыли ? И да, базовые задачки можно и заучить, уровнь знаний кандидата они точно не отображают
Он плох тем что не дает информации о кандидате. Ну он смог стырить откуда-то решение - отлично, он умеет интегрировать друг с другом куски чужого кода. Но ведь это более простая задача, чем разрабатывать самому.
Сравните с вопросами на интервью, когда вы проверяете умение кандидата оценивать выч сложность, умение манипулировать стандартными структурами данных, умение объяснить почему это решение плохое, а другое хорошее - и также уметь объяснить в каком именно смысле решение считается хорошим или нехорошим. Ну и конечно же, дизайн - там всегда есть простор для интересной беседы.
Для меня такой кандидат на порядок ценнее. А если он не знает DI фреймворков или не имеет настраивать мониторинг или его взяли делать веб, а он сроду им не занимался - вообще ни разу не проблема, научится.
Короче оцениваться должны мозги (потеенциал) а не опыт. Точнее - важно и то и другое, но мозги важнее.
Когда сколько-то лет назад в Амазоне нас учили собеседовать кандидатов, кто-то задал вопрос - а почему не даем тестовые задания и т.п. Ответ был такой - компания пробовала разные интервью-практики, но время показало что нынешняя система интервью (только дизайн и кодинг вопросы, плюс немного разговора о лидершипе и ничего больше) работает лучше, чем все испробованные прежде.
"На одном из технических собеседований у меня было 6 технических интервьюеров"
На одном из технических собеседований меня собеседовали 11 человек.
Т.е. я должен быть таким умным, что должен был прийти с уже готовым решением.
По общению с рекрутером я оказался первый из десятка кандидатов, кто вообще прошел до очного собеседования.
Да, тестовое задание мне очень понравилось, очень грамотное, такие редкость, но и мне пришлось потратить на него целый свободный день. В других условиях навряд ли я уложился бы в сутки, это их требование по времени.
Очные тестовые задания с вакансией никак особо не коррелировали. Т.е. когда-то придумали задачи и используют на всех собеседованиях не смотря на вакансию.
Мне например понравился live-coding, как в парном программировании.
Как минимум собеседующему сразу стало видно как я работаю и думаю.
Причем это заняло не много времени для обеих сторон.
По тестовым заданиям. Некоторые пишут, что это круто и неплохо их выполнять. Наверное они еще не сталкивались, когда у тебя 10 и выше предложений и если на каждом тебе предлагают ТЗ 2-8 часов, то начинаешь отказываться от этого. Находятся те, кто и без ТЗ принимает. Иногда, если говорят, что на 2-3 часа и у меня давно не было свежего на гилабе, то на одно выполнение могу согласиться. Но если говорят, что рассчитано на 8 часов, то я просто посылаю такого. Считаю это неуважение к соискателю.
По live-coding нужно учиться его проходить. Первое я с треском провалила, т.к. начала дико тупить. Нормально получилось только на 3й раз. Но лучше этот вариант, чем ТЗ.
Последнее время думаю по проходить собеседования, с одной стороны я наверно засиделся и окоченел на текущей работе, с другой я чувствую себя недостаточно подготовленным к этому всему. Читаешь статьи про собеседования и становится страшно, много непонятных слов) Наверно я уже слишком стар для этого всего
Немного о собеседованиях и совсем чуть-чуть о тестовых заданиях