Как оценивать кандидатов?

Итак, я время от времени провожу технические интервью. Технические не в смысле “напишите функцию, которая делает X”, а, как правило следующий этап после тех задания, где нужно оценить софт-скилы, умение принимать решения, взаимодействовать с командой и т. д. Ну и технические вопросы в духе “если бы тебе пришлось собирать пайплайн с нуля, какие джобы ты там хотел видеть?”.
Поскольку вопросы, как правило, очень открытые, время от времени возникают проблемы с интерпретацией. Например, я спросил Х, кандидат ответил Y, что вроде бы рядом, но не совсем. Возможно кандидат уходит от ответа. Возможно, я неправильно сформулировал.

В общем, накидайте, пожалуйста, рекомендаций по книгам/курсам/статьям и т.д. Можно на английском. Можно за деньги.

все что не касается технических навыков очень сложно оценить, особенно если у тебя 20-30 минут на общение, тут уже надо в зависимости от вакансии и команды подбирать список вопросов и требований, что для вас важнее и т.д.

Мне всегда нравилось онлайн задание на 2-3 часа, и как интеврьюверу и как проходящему интервью, можно с 1-2 людьми из будущей команды повзаимодействовать, понять насколько ок с ними общаться, насколько хорошо кандидат может задавать вопросы… но даже тут есть люди которые хорошо играют, а после получения оффера могут оказаться мега токсичны в команде. Так что испытательный срок никто не отменял.

Из ресурсов мне очень нравятся видео вот этого чувака https://www.youtube.com/watch?v=PJKYqLP6MRE, может подойдет.

1 лайк

Да, он очень крутой, жаль что перестал выпускать.
Примерный список вопросов есть, но не хотелось бы всем кандидатам скармливать один и тот же список, я предпочитаю затачивать его под кандидата по результатам тестового. Ну и опять же: как интерпретировать ответ? Например (вольный перевод с английского):
Q: расскажи мне о подходах к тестированию, которые ты используешь? (тут я хочу услышать про юнит тесты, интеграционные тесты, их плюсы и минусы).
A: у нас есть Jest, мы еще начали React testing library прикручивать.

Я неправильно задал вопрос? Или кандидат просто не дотягивает до уровня?

Да, на общение есть час, в него же входит время на вопросы кандидата (кстати, как их интерпретировать?)

а, так это не софт скилз)

Я неправильно задал вопрос? Или кандидат просто не дотягивает до уровня?

может показаться слишком общим. но никто ж не мешает задать наводящие вопросы: есть ли юнит тесты в проекте, на чем пишите, расскажи детальнее про тестовый фреймворк, какое соотношение small, medium, large test. и еще накидывать можно. а дальше уже добавлять вопросы по желанию, в зависимости от ответов кандидата, например он скажет что эксперт в Cypress и интеграционных тестах, тогда можно задать пару практических вопросов по Cypress, из реального опыта, что-то что нельзя нагуглить сходу.

1 лайк

зависит от вопросов. Если по теме, интересуется процессами, командой, технологиями, продуктом - отлично, значит он подготовился и ему не все равно куда собеседуется.

1 лайк

Доводилось проводити інтервью.

Я зазвичай просто питаю про те, чим людина займалась на попередній роботі, що цікавого кодили, які проблеми виникали, шукаю за що зачепитись щоб почати бесіду.

Про реальний досвід людині легше розповісти, плюс зазвичай половина це те, з чим я теж зустрічався.

З відповідей я беру початковий напрямок руху бесіди та бачу куди глибше копати, в яку сторону. Так зазвичай обом сторонам комфортніше, і я можу також отримати позитивний досвід а не лише питати про абстрактні речі.

Стосовно приклада про пайплайни, питання може бути задане, коли людина сама до пайплайнів доходить, тоді спілкування цікавіше.

Таким чином я будував структуру співбесіди, коли людина не мучиться і по відповідях можна створити думку про людину. зазвичай Х було 100% зрозуміло для людини.

Може це не про статті , книжки та курси , але трошки свого позитивного досвіду. )))

1 лайк

у нас обычно после HR интеврью я проводил техническое интервью (1.5 часа с небольшими практическими задачками) и где-то полчаса интервью с менеджером (чаще в другой день). Если все ок - интервью с заказчиком и оффер. В наше время если ты не Амазон или Фейсбук, а обычный аутстафф/аутсорс в Украине, то пытаешься ухватиться за каждого кандидата) и максимально помагать на интервью. Если с техническими знаниями все ок и в общении адекватным оказался, то остается молится чтоб он знал английский и смог пройти кастомерское интервью.

При этом все равно приходилось проводить 25-40 собеседований (не считая тех что HR завернули) чтоб закрыть 1 вакансию. Очень хорошо если есть ротации внутри компании.

Так что я б не стал изощирятся, спрашивать логические задачки (“Как сдвинуть гору Фудзи” и подобные книги) или сильно придераться к ответам). Разве что ты работаешь в Wix или Grammarly, там отбоя от желающих нет, можно и тестовое на недельку задавать))

1 лайк

Да, но тут же очень тонкая грань между “кандидат разбирается в вопросе” и “кандидата довели за ручку до вопроса на да/нет”

ага, тут нельзя однозначно измерить как рост или вес. Степень насколько нужно “довести за ручку” зависит от уровня сеньйорности.

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

1 лайк

Ниже не статьи-книги, но мой опыт и мысли.

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

Потом я пытаюсь понять какие характеристики для ситуации в которой будет работать кандидат критичны а какие нет. Например человек, проявляющий яркую индивидуальность не уживется с эгалитаристкой командой.

И во время интервью пытаюсь понять есть ли у человека какие из желаемых/нежелаемых характеристик. Прикол в том что очень много характеристик контекстные: иногда быть лидером хорошо иногда нет. Компания в моем лице ищет подходящего (это не значит что лучшего во всех характеристиках) человека. Кстати, я именно так смотрю на интервью в других компаниях: они ищут подходящего человека, и если меня не взяли, значит я по их оценке не подхожу.

На каждом из этапов выше можно очень легко допустить ошибку. Поэтому лучше всего вовлекать 2-3 человека в интервью чтобы каждый из них давал свою перспективу на кандидата.

Я смотрю на такие характеристики как:

  • Трудолюбие в смысле умения доводить задачу до завершения.
  • Любобытство. Очень хороший сигнал если человек интересуется чем-то за пределами рабочей темы. Но отсутстви любопытства не есть негативным сигналом.
  • Умение и желние учиться. Это самое главное. Потому что на нем можно построить все что угодно.
  • Несовместимости с той системой куда человек попадет. Обязательно коммуницирую свои предположения обратно кандидату. На практике этот пункт становится причиной выгорания и увольнений.
2 лайка