К основному контенту

Немного про наём, собеседование и испытательный срок от вашего КО

Давно (больше полугода) не занимался наймом, зато сам по собеседам походил.
Решил записать себе, пока еще свежо, идеи и ощущения от собеседований в качестве кандидата с проекцией через свой опыт собеседований. Ну и разбавлю их теми принципами, которым следовал, когда проводил собеседования сам. Их как-то больше получилось :)

Будет нифига не академично, жизненно, но со старомодным налетом человеколюбия.
Просто наброски-зарубки, с минимумом объяснений. Если кому интересно, можно подробней пообщаться.

Надеюсь, что статья будет полезна и новичкам-собеседующим (не только HR), и кандидатам, хотя ориентирована скорее на первых. Советы даны именно для собеседующих. Техножести и отсылов к примерам заданий на собеседах не будет. Я больше про "пообщаться".

Собеседования я проводил последние лет 12. В основном, это были собеседования разработчиков в продуктовые компании. В последний год работы в предыдущей компании удалось пообщаться и с тестировщиками (для них бонус в конце). Сам я собеседовался на должности повыше, но ошибки (мои и компаний) были очень похожими.

Важно понимать, все что описано ниже - это просто инструменты. Какие-то вам подойдут, какие-то нет.
Применимость зависит в первую очередь от потока на входе: если у вас богатый выбор из кандидатов, то, скорее всего, вы можете игнорировать советы и закрывать вкладку браузера. Хотя погодите!
Помните, жизнь сложная штука и может оказаться, что завтра вы будете кандидатом у собеседующего, которого вы пару лет назад неудачно отсобеседовали сами. Все, теперь можете закрывать.
Напоминаю, что я работал в продуктовых компаниях, в аутсорсе многое работает по-другому.

Вы должны понимать кого вы ищете: ключевые знания, навыки. В голове должны быть четкие критерии, по которым вы будете оценивать кандидата: обязательные "да", и точные "нет".

Обсудите их со своим рекрутером, офигенно когда вы работаете с ним в одном контексте. Мне по жизни чаще всего везло с HR и ковыряться в сотнях бесполезных резюме не приходилось.

Изучайте резюме: предыдущие компании, ссылки, блоги (профессиональные), соцсети. Там много полезного можно найти. Например, я как-то наресечил неуказанный в резюме github, и, возможно, это помогло мне поработать с одним из самых крутых своих разработчиков. Во всяком случае беседа получилась предметной, позитивной и открытой.
Уже как кандидату, мне было забавно на собеседе видеть удивление собеседующего, когда ты ему рассказываешь, например, про блог или про выступления на конференциях, хотя все это есть в резюме.

Постарайтесь игнорировать фото (хотя ковер на заднем плане, или фото в купальном костюме тяжело игнорить). Люди не всегда цепляют хорошие фото.
Собственный опыт - я как-то чуть не пропустил другого своего крутого разработчика из-за фото в резюме. Но тогда они еще было редкостью, так я себя оправдываю :)

Будьте готовы ответить про ЗП при первом общении с кандидатом. И не пытайтесь делать из этого вопроса трагедию (= типа, кандидат только о деньгах думает), ну глупо это.

Задание на собеседовании не должно/не обязано быть уникальным. Я знаю, что несколько компаний в городе использует один вариант (с некоторыми изменениям) тестового уже продолжительное время. Более того, я знаю что у меня были кандидаты, которые его уже видели. Но, это им не помогло. Потом что, см. следующий hint.

Задача не должна быть"да/нет" - лучше, если совсем нет правильного ответа или их много. Все ведь помнят про "открытые вопросы"? Так вот, идеально, если задача предполагает общение по нему, в стороны, в соседние области. И самое ценное - это именно это общение. Задача - это просто зацепка. Хороший вариант - code review куска программы.

Тестовое задание на дом в моей практике мало помогало, но многие любят. Важно понимать для себя, что оно вам дает. Хорошо работает, как фильтр при большом потоке на входе. Но, скорее уже после первого общения. Хотя наличие задания на дом после первого собеседа предполагает, как минимум еще одно общение. Комментарий одного из тех крутых, что выше упомянул: "Это еще и второй шанс, возможность показать, что ты хороший программист, просто переволновался."

Собеседование всей командой: даже если вы сами (в одно лицо) принимаете решение брать или нет, мнение команды будет очень ценным - им потом работать с этим человеком. А кому то еще и ментором быть. Понятно, что не стоит приходить толпой из 5-6 человек, но ключевые люди обязательны. Участвовать должны все пришедшие, просто "посидеть-послушать" не вариант. Так заодно и опыт собеседований передается. А "собеседовать" и "собеседоваться" - это разный опыт.

С кандидатом обязательно общаться, независимо от результата теста (помним ведь, что там нет "правильного ответа"). Поясню, я сейчас про сценарий: пообщался HR, выдал задание, потом идут технические специалисты. Так вот, идти обязательно нужно, хотя иногда пипец как тяжело, видя результаты выполненного задания. Почему? См hint про рекомендации.

Проекция на задачи - мне очень помогала попытка спроецировать человека (его знания) на те задачи, которые ему придется решать. Это дает возможность задавать правильные вопросы и услышать нужные советы.

Некомильфо скучать в смартфоне на собеседе - это просто неуважение к человеку. Скучно - нехрен вообще приходить. Сообщать через смартфон, что пора заканчивать собесед - тоже не вариант

Полезно иметь "кодовую фразу" для досрочного завершения собеседа. Иногда, то что человек не подходит, становится понятно еще до завершения привычного ритуала с вопросами. В такой ситуации достаточно просто сказать "код" и приступить к завершающей части.

Хорошее прощание - важно хорошо закончить собеседование. Человек должен уйти на позитиве. Даже если вы ему сказали нет. Как этого добиться?

Если определенно можете сказать "нет" - говорите. Но вы должны будете объяснить почему. И что нужно сделать, чтобы кандидат прошел повторное собеседование. Звучит бредово? Но это работает :)

Дайте рекомендации по подтягиванию знаний - мы просто давали список литературы по С++ (для разработчиков), тестировщикам отправляли эту статью.

Последние 2 пункта дают возможность услышать "это было самое крутое собеседование в моей жизни". И я такое слышал.

Ну и последнее: если есть сомнения, то трактуйте их не в пользу кандидата - суровая правда жизни. Нарушение этого принципа, неважно по каким причинам, в моей практике ничем хорошим не заканчивалось. Никаких компромиссов с "мы давно ищем", "вы слишком сложные вещи спрашиваете" и тп. Помните, мы начали с ожидаемых "да" и неожидаемых "нет". Еще есть такая мистическая штука, как "чуйка". Но она приходит с опытом и настолько мистична, что объяснить сложно.

Собеседованием и принятием офера кандидатом история не заканчивается. Дальше же у нас испытательный срок. А что с ним?

Коротенько, 3 совета от КО (у меня слезы, но эти пункты не везде выполняют):

Задание на испытательный срок - новенький должен понимать, на основании чего его будут оценивать. Тут разговор скорее не только о технической стороне вопроса, но часто и ее нет. Это необязательно должно быть задание на все 3 месяца. Обычно достаточно на первый месяц, дальше как пойдет.

Ментор - офигенно, если у нового сотрудника есть ментор на период испытания. Он должен знать, кого можно дергать по любым вопросам. Даже если считается, что любой в команде может ответить на любые вопросы. Тяжело задавать вопросы всем сразу. Ментором может быть или сам тимлид, или будущий тимлид, или просто один из членов команды по желанию. Но если у человека нет опыта менторства, то его нужно аккуратно допускать к новеньким. Ему самому в этом случае нужен ментор.

Обратная связь - минимум 3-4 раза в первые 2 недели, потом хотя бы раз в неделю. Задача ментора это обеспечить.
Тредик в твит по теме онбординга.

Обещанный бонус для собеседования тестировщиков: я часто на собеседованиях спрашивал про тестирование лифта. Я уже не помню сам придумал, или у кого то утащил идею. На прошлой неделе, по пути в бар на вечеринку спикеров конференции "Гейзенбаг", я оказался в лифте с Аланом Пейджем. На 7й этаж лифт добирался нешустро, останавливался через этаж и Алан ухмыльнулся - кто тестировал этот лифт? Я вспомнил про свой вопрос на собеседе и рассказал ему. Алан подумал сек 5, потом посмотрел на меня и сказал "Хороший вопрос, можно долго общаться. Много тем можно зацепить". Уж не знаю, что он подумал на самом деле, но выглядел он искренним :)

Что еще почитать:

Комментарии

Популярные сообщения из этого блога

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе