23 Jan 2013

Как проводить собеседования?

Расскажу свою точку зрения о том как проводить собеседования на должность разработчика, в частности на Java разработчика.

В первую очередь расставим цели:

  • Подобрать разработчика в свою команду

  • Он должен помочь нам с проектом технически

  • С ним должно быть приятно работать

К сожалению большинство собеседующих забывают об этих целях и во многих случаях собеседование скатывается к:

  • Озадачить кандидата задав ему сложный вопрос

  • Показать как я крут

  • “Он решил эту задачу, берем!” или “Он не решил эту задачу, он не достоин”

Как же все-таки должно проходить собеседование:

  • Для начала вам нужно расслабить кандидата (сделайте ему массаж ;)). Человек, отвечающий на вопросы и человек, работающий в команде, - это два разных человека. Хорошего разработчика можно запутать и он будет плохо отвечать на вопросы, и наоборот - плохой разработчик может знать как все должно выглядеть в теории, но никогда не делать этого на практике. Вам нужно добраться до разработчика спрятавшегося на время собеседования где-то глубоко внутри, а не послушать ответы “студента”.
    Если в его резюме перечислены хобби, поспрашивайте о них. Если для вас важно, чтоб человек знал английский, начните с проверки английского, а там уже можно порасспрашивать и про увлечения, и про школу с дет садиком, таким образом убьете двух зайцев. Важно, чтоб человек с вами начал общаться как с коллегой, но и в кабак его при этом вести не стоит - всему есть меры.
  • Не используйте тесты. Никогда вам тесты не покажут ни квалификацию разработчика, ни того какой он командный игрок. Во-первых, тесты просто раздражают, они нудные. В итоге разработчик может уйти от вас с негативом, а это в свою очередь скажется на авторитете компании, он ведь обязательно поделится своими впечатлениями с друзьями. Во-вторых, вы думаете внешние (центральные) экзамены, которые школьники сдают для поступления в ВУЗ хоть как-то показывают уровень студентов? Э-э-э нет, уровень - это не знание ответа на вопрос, а понимание предмета.

  • Попросите кандидата показать свой код прежде чем приглашать на собеседование. У многих есть какие-то open source проекты, которыми им будет приятно похвастаться.

  • Дайте человеку пописать код (особенно если у него не было чем похвастаться перед собеседованием). Прям на собеседовании выделите ему машину и IDE, чтоб увидеть как этот человек пишет. Причем,

    • Условия должны быть максимально приближенные к реальным. Человек не должен писать в notepad, это глупо, он не будет писать так на работе.
    • Задание не должно быть сложным, любое сложное задание может занять дни, даже если вы считаете что оно короткое и его можно написать за полчаса, у кандидата может сложится другая картина. Например, вы можете предложить написать какую-то коллекцию. Никогда вам человек не напишет правда качественную, оптимизированную коллекцию, с документацией и тестами за полчаса. Если же вам нужны лишь очертания коллекции, тогда объясните четко кандидату что вы от него хотите. Имейте в виду, что вам важней то, как кандидат пишет в реальной жизни, а не то как он пишет “когда надо быстро-быстро ой-ой-ой”. Я предпочитаю давать задачи, типа, найти максимальное число. Она тривиальна, поэтому кандидат вполне может уложиться в полчаса. Также из очень классных заданий - написание immutable классов, это элементарно сделать и это важно в каждодневной разработке.
    • Кандидат должен четко понимать что от него хотят. Если вы хотите оптимизированное решение, объясните это кандидату. Если вам нужно близкое к реалиям решение, объясните это кандидату. Если вам важно просто понимание кандидата, объясн…
  • Старайтесь не спорить с кандидатом, ваша цель - определить его уровень, а не переспорить его.

  • Задавайте вопросы по-настоящему важные для вас. Если у вас в проекте используется технология А, Б, В, а вы для комплекта расспрашиваете о Э, Ю, Я которые и близко к вам не относятся, значит вы не преследуете свою изначальную цель - найти сотрудника в ваш проект.
    Бывает, что компания крупная и важно знать уровень разработчика в разных областях, мол, может другой проект возьмет. В таком случае сначала убедитесь, что он не подходит вам, ну и все равно знайте меру.

  • Вам нужен не ответ, а понимание предмета. Вы не должны останавливаться на том, что человек дал вам ответ на конкретно поставленный вопрос, вам нужно обязательно копнуть глубже, попросить привести разные примеры, как человек то или иное применял на практике и т.п. Просто ответ вас не интересует, вас интересует насколько глубоко человек разбирается в предмете. С одной стороны кандидат который разбирается в предмете может не знать определенного ответа но разбираться в общем; ну и как всегда есть те, кто просто знает ответы на вопросы.

  • Неправильный ответ на заковыристый вопрос не дает минусов кандидату. Если вы задаете очень тонкий вопрос, вас не должно смущать что человек этого не знает. Во-первых, какой прок от этого вопроса? Что он, определит уровень кандидата? Эти знания, возможно, в жизни ему никогда не пригодятся. Во-вторых, ну не наткнулся он на ту же статью, что вы прочли вчера, зато он может быть сильным в другой области, осваивать которую нужно полгода.

  • Не задавайте вопросы по алгоритмике и математике, если ваш проект в этом правда не нуждается. Это очень популярная тема на собеседованиях, однако как математика, так и алгоритмика нужна в очень узком спектре задач. Я встречал очень сильных в программировании людей, которые не разбирались в этом: математика была давно и забылась, а алгоритмика как не была нужна, так и не стала. Даже если периодически какие-то знания нужны в вашем проекте - насколько они критичны? Любые знания, которые можно быстро нагуглить - просто крошка по сравнению с тем, чему люди учатся годами.

  • Лучше нанять толкового junior’a, чем бестолкового senior’a. Очень большой процент разработчиков остается на одном и том же уровне всю жизнь. Их много, и они бесполезны. Намного лучше нанять свежего разработчика с мозгами, который начнет разбираться в предмете уже через месяц. К сожалению рецептов как найти таких шустряков у меня нет, только после месяца-двух работы с людьми можно о чем-то говорить.

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

  • Не будьте категоричными. Если кандидат не знает какого-то важного аспекта, возможно он ему может быстро обучиться. Старайтесь оценивать человека в общем, а не по конкретным вопросам.

  • Расскажите свое мнение кандидату. Это лично моя фича и в некоторых ситуациях она не приемлена, однако я предпочитаю делиться своим впечатлением с кандидатом. Чтоб человек развивался, он должен понимать что не так и куда нужно двигаться. Сделайте человеку полезно и расскажите где он был неправ или неточен.

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