– Папа, а идеальное собеседование существует?
– Нет, сынок, это фантастика.
(с)
Идеальные собеседования, в отличие от сусликов, практически никогда не встречаются в дикой ИТ-среде. Но стремление к лучшему вымирать не должно, поэтому предлагаем вашему вниманию несколько советов на тему того, как провести идеальное собеседование.
Думаю, все согласятся, что собеседование на позицию младшего разработчика и топ-менеджера должны отличаться. Но плясать нужно не от должности, а от целей, которые вы ставите перед будущим сотрудником.
Вот здесь и кроется первый подвох. Компании любят говорить, что им нужны только лучшие люди. Но в реальности очень часто берут не лучших, а подходящих под некие критерии (не всегда связанные с качеством), придуманные в компании, или, что еще хуже, родившиеся в голове самого эйчара. В результате такой деятельности в компании работают не лучшие специалисты, а сотрудники, выбранные по некоторому шаблону.
Давайте посмотрим, что нужно спрашивать и на что обращать внимание при собеседовании айтишников различных профессиональных уровней. В каждом случае я буду говорить о среднестатистическом соискателе, а не о гении, которыми многие из вас, естественно, являются.
Младший разработчик aka “джуниор”
Задача младшего разработчика быстро учиться и перенимать опыт. Делать мелкую работу по проектам – это один из способов обучения, а не причина, по которой вы должны взять его на работу. Задача компании сделать из джуниора мидла за минимально возможный срок (в идеале за 2-2.5 года).
* У многих компаний может появится соблазн набирать джуниоров, чтобы продавать их как мидлов. Продавать джуниоров по цене мидлов, конечно, выгодно, но гораздо выгодней продавать мидлов по цене двух сеньоров.
Для того, чтобы понять, как быстро джуниор может учиться и развиваться, расспросите на собеседовании, чем он занимался три года назад, два года назад, год назад (даже если в это время он учился в университете). Спросите какие книги сейчас читает, какие фильмы смотрит и что он изучает в данный момент. Посмотрите на прогресс. Если за последний год-два в работе, хобби, литературе и кино ничего кардинально не поменялось, то, скорее всего, в таком неспешном темпе он и будет у вас “работать”.
Хотите спросить о том, какие алгоритмы он знает? Вы можете это сделать, но должны понимать, что без практики любое знание алгоритмов будет означать, что он, скорее всего, их заучил. Лучше спросить о его курсовой или дипломной работе. Человек, который реально хочет учиться и развиваться, в этот момент преобразится и начнет очень увлеченно и более непринужденно рассказывать о своейникому не нужной поделке. Но для увлеченного человека эта “поделка” — важнейший проект в мире.
Если же он начнет рассказывать, что университет ничего не дал, за пять лет с ним ничего интересного не случилось — это тревожный звоночек. Так как ИТ, по большому счету, — это не ток-шоу, где вы главный герой, а обычная рутина по разгребанию легаси кода и написанию велосипедов. Есть вероятность, что с таким же энтузиазмом он будет делать и вашу работу.
Спрашивать кем себя видит джуниор через 5 лет – бессмысленно. Он согласится работать в первой же компании, которая будет не против его взять и дать немного денег на новый свитер.
* Не так давно появилась новая категория “джунов”, которые, начитавшись на форумах о больших зарплатах айтишников, начинают просить (даже, мы бы сказали, настойчиво требовать) стопитсот денег и массажистку в придачу за возможность лицезреть Его Величество, неспешно раскладывающим пасьянс из операторов и классов, два-три часа в перерывах между походами в университет и ночные клубы. Таких можно спросить, когда и где намечается ближайшая классная вечеринка и… попрощаться. Хотя, справедливости ради, добавим, что этот вирус замечен не только среди молодых специалистов.
Разработчик aka “мидл”
Мидл-разработчик – это ваша вьючная лошадь, которая будет выполнять большую часть всей рутинной работы и приносить максимальную прибыль. Поэтому для мидла важно быть “трудягой”, а не “звездой” или “классным чуваком”. Учтите, что среди мидлов больше всего не признанных чемпионов по настольному теннису.
На собеседовании необходимо делать большой упор на наличие тех или иных знаний и навыков (можно без углубления в теоретические дебри). Чем больше технических вопросов вы зададите, и больше правильных ответов получите – тем лучше для вас. Обязательно спросите, чем абстрактный класс отличается от интерфейса — как показывает практика, этим вопросом очень легко идентифицировать реальных мидлов.
Зона компетенции мидла – языки программирования, инструменты и технологии. Поэтому чем больше технических вопросов и заданий пройдет соискатель, тем лучше.
Вот тут сделаем ремарку о том, как лучше всего проводить технические интервью. Первый из способов – “писать код на бумаге” даже комментировать не будем – таких интервьюеров надо сжигать на костре (привет, Microsoft и все ее подражатели). О втором способе – сделать мини-проект, на который надо убить минимум пол, как правило, рабочего дня, тоже забудьте.
Итак, алгоритм таков: если соискатель спикер, активная и известная личность, можно посмотреть видео выступлений на YouTube, презентации на slideshare, проекты на github, codeplex и/или почитать его вопросы/ответы на stackoverflow. Если это не помогло или информация отсутствует, то вы, наверняка, захотите дать тестовое задание. Лучше его прислать по почте без указания срока на выполнение. Скорость выполнения, энтузиазм, качество выполнения, переписка и прочие вещи расскажут вам практически все об этом кандидате.
* Но если не соискатель откликнулся на вашу вакансию, а это вы его пригласили на собеседование или вам его порекомендовали, вы должны сделать всё, чтобы минимизировать потраченное соискателем на вас время. И да, если вы два месяца домогались его, чтобы он пришел на собеседование, не задавайте ему вопросы а-ля “почему вы хотите работать в нашей компании”. Ответ вас удивит и расстроит :)
Спрашивать кем себя видит мидл через пять лет – бессмысленно. Через пять лет вряд ли он будет работать в вашей компании.
Старший разработчик aka “сеньор”
Проблема со старшими разработчиками в том, что такой специалист может выполнять различные роли — технического лида, тимлида, интервьюера, специалиста по обучению и т.д. Как правило, эти роли совмещаются в той или иной степени.
Старший разработчик – это человек, который может сделать недельную работу своей команды за один день. Если вы ему не будете мешать. Но делать он этого не будет, потому что он старший разработчик, а значит он, скорее всего, будет проводить собеседования, заполнять матрицы на членов своей команды, пить кофе, присутствовать телом (но не душой) на многочисленных митингах, а также сеять внутри компаниикоммунизм скрам.
Задача интервьюера – определиться до интервью, кого компания хочет видеть: технического специалиста (упор на технологии) или тимлида (упор на менеджмент).
Если нужен технический специалист, то его нужно спрашивать о доменных областях, в которых он работал, предыдущих проектах, его реальной роли, уровне сложности проектов и размерах/составе команд. Зона компетенции технического сеньора – отдельные компоненты системы и их интеграция, хорошее знание сторонних инструментов (фреймворков, готовых решений, CMS и конкретных библиотек). Не задавайте ему вопросы на синтаксис языка – некоторые конструкции, он, скорее всего, уже забыл, а некоторые ему никогда в жизни так и не пригодились. Или будьте готовы к тому, что он вместо решения выскажет свою готовность отбить пальцы любому, кто напишет что-либо подобное в реальном проекте.
Если вам нужен тимлид, то вопросы должны касаться не технологий, языков программирования, а прочитанных книг по управлению людьми и проектами, аспектах конфликтологии. Убедитесь, что речь соискателя выглядит уверенно. Можно смоделировать какие-то жизненные ситуации (но без фанатизма) и предложить решить их. Но нужно быть готовым, что его методы и способы будут отличаться от ваших. Зона компетенции тимлида – умение быть убедительным, разбираться хоть немного в психологии и менеджменте, а также в технологиях на уровне инструментов (jira, tfs, asana и т.д.).
Нужно помнить, что технарей, которые одновременно являются как сильными специалистами, так и хорошими тимлидами, очень мало. Если вам попался именно такой – не отпугните и сделайте всё возможное, чтобы его заполучить.
Профессионал aka “гуру”
Гуру – это человек, который в критической ситуации может вытащить проект на себе или принять на себя удар. В обычной жизни могут быть заносчивыми, трудно поддаваться на манипуляции и хотетьочень много денег.
Гуру должен гордиться не количеством сделанных проектов или заработанных денег, а максимальным уровнем задач и проблем, которые он решил.
Что спрашивать гуру? Это сложный вопрос, так как гуру, как правило, обладает огромным опытом прохождения собеседований, поэтому перехитрит HR практически на всех уровнях. Пожалуй, самым правильным выходом является ситуация, когда гуру собеседует другой гуру или кто-то из топ-менеджмента. Гуру поймет технический уровень, топ-менеджер, скорее всего, определит, насколько человек подойдет компании. Как правило, если человек гуру, то это все знают и в таком случае каких-то сложных собеседований быть не должно.
Вместо выводов
Если вы ищете специалистов до уровня тимлида или техлида, то собеседование нужно строить исходя из должности и ваших требований (в больших компаниях эту задачу лучше всего поручить кадровому агентству), если выше – исходя из человека и его будущей роли (здесь уже нужно подключать личные связи и нетворкинг). И чем более высокую должность нужно закрыть, тем более индивидуальным должен быть подход. Все это связано с тем, что ИТ-сфера очень сильно отличается от других сфер, поэтому традиционные кейсы, стрессовые и прочие типы собеседований не подойдут. Ведь мидл может быть джуниором в одной компании и сеньором в другой.
Приятных вам собеседований!
– Нет, сынок, это фантастика.
(с)
Идеальные собеседования, в отличие от сусликов, практически никогда не встречаются в дикой ИТ-среде. Но стремление к лучшему вымирать не должно, поэтому предлагаем вашему вниманию несколько советов на тему того, как провести идеальное собеседование.
Думаю, все согласятся, что собеседование на позицию младшего разработчика и топ-менеджера должны отличаться. Но плясать нужно не от должности, а от целей, которые вы ставите перед будущим сотрудником.
Вот здесь и кроется первый подвох. Компании любят говорить, что им нужны только лучшие люди. Но в реальности очень часто берут не лучших, а подходящих под некие критерии (не всегда связанные с качеством), придуманные в компании, или, что еще хуже, родившиеся в голове самого эйчара. В результате такой деятельности в компании работают не лучшие специалисты, а сотрудники, выбранные по некоторому шаблону.
Давайте посмотрим, что нужно спрашивать и на что обращать внимание при собеседовании айтишников различных профессиональных уровней. В каждом случае я буду говорить о среднестатистическом соискателе, а не о гении, которыми многие из вас, естественно, являются.
Младший разработчик aka “джуниор”
Задача младшего разработчика быстро учиться и перенимать опыт. Делать мелкую работу по проектам – это один из способов обучения, а не причина, по которой вы должны взять его на работу. Задача компании сделать из джуниора мидла за минимально возможный срок (в идеале за 2-2.5 года).
* У многих компаний может появится соблазн набирать джуниоров, чтобы продавать их как мидлов. Продавать джуниоров по цене мидлов, конечно, выгодно, но гораздо выгодней продавать мидлов по цене двух сеньоров.
Для того, чтобы понять, как быстро джуниор может учиться и развиваться, расспросите на собеседовании, чем он занимался три года назад, два года назад, год назад (даже если в это время он учился в университете). Спросите какие книги сейчас читает, какие фильмы смотрит и что он изучает в данный момент. Посмотрите на прогресс. Если за последний год-два в работе, хобби, литературе и кино ничего кардинально не поменялось, то, скорее всего, в таком неспешном темпе он и будет у вас “работать”.
Хотите спросить о том, какие алгоритмы он знает? Вы можете это сделать, но должны понимать, что без практики любое знание алгоритмов будет означать, что он, скорее всего, их заучил. Лучше спросить о его курсовой или дипломной работе. Человек, который реально хочет учиться и развиваться, в этот момент преобразится и начнет очень увлеченно и более непринужденно рассказывать о своей
Если же он начнет рассказывать, что университет ничего не дал, за пять лет с ним ничего интересного не случилось — это тревожный звоночек. Так как ИТ, по большому счету, — это не ток-шоу, где вы главный герой, а обычная рутина по разгребанию легаси кода и написанию велосипедов. Есть вероятность, что с таким же энтузиазмом он будет делать и вашу работу.
Спрашивать кем себя видит джуниор через 5 лет – бессмысленно. Он согласится работать в первой же компании, которая будет не против его взять и дать немного денег на новый свитер.
* Не так давно появилась новая категория “джунов”, которые, начитавшись на форумах о больших зарплатах айтишников, начинают просить (даже, мы бы сказали, настойчиво требовать) стопитсот денег и массажистку в придачу за возможность лицезреть Его Величество, неспешно раскладывающим пасьянс из операторов и классов, два-три часа в перерывах между походами в университет и ночные клубы. Таких можно спросить, когда и где намечается ближайшая классная вечеринка и… попрощаться. Хотя, справедливости ради, добавим, что этот вирус замечен не только среди молодых специалистов.
Разработчик aka “мидл”
Мидл-разработчик – это ваша вьючная лошадь, которая будет выполнять большую часть всей рутинной работы и приносить максимальную прибыль. Поэтому для мидла важно быть “трудягой”, а не “звездой” или “классным чуваком”. Учтите, что среди мидлов больше всего не признанных чемпионов по настольному теннису.
На собеседовании необходимо делать большой упор на наличие тех или иных знаний и навыков (можно без углубления в теоретические дебри). Чем больше технических вопросов вы зададите, и больше правильных ответов получите – тем лучше для вас. Обязательно спросите, чем абстрактный класс отличается от интерфейса — как показывает практика, этим вопросом очень легко идентифицировать реальных мидлов.
Зона компетенции мидла – языки программирования, инструменты и технологии. Поэтому чем больше технических вопросов и заданий пройдет соискатель, тем лучше.
Вот тут сделаем ремарку о том, как лучше всего проводить технические интервью. Первый из способов – “писать код на бумаге” даже комментировать не будем – таких интервьюеров надо сжигать на костре (привет, Microsoft и все ее подражатели). О втором способе – сделать мини-проект, на который надо убить минимум пол, как правило, рабочего дня, тоже забудьте.
Итак, алгоритм таков: если соискатель спикер, активная и известная личность, можно посмотреть видео выступлений на YouTube, презентации на slideshare, проекты на github, codeplex и/или почитать его вопросы/ответы на stackoverflow. Если это не помогло или информация отсутствует, то вы, наверняка, захотите дать тестовое задание. Лучше его прислать по почте без указания срока на выполнение. Скорость выполнения, энтузиазм, качество выполнения, переписка и прочие вещи расскажут вам практически все об этом кандидате.
* Но если не соискатель откликнулся на вашу вакансию, а это вы его пригласили на собеседование или вам его порекомендовали, вы должны сделать всё, чтобы минимизировать потраченное соискателем на вас время. И да, если вы два месяца домогались его, чтобы он пришел на собеседование, не задавайте ему вопросы а-ля “почему вы хотите работать в нашей компании”. Ответ вас удивит и расстроит :)
Спрашивать кем себя видит мидл через пять лет – бессмысленно. Через пять лет вряд ли он будет работать в вашей компании.
Старший разработчик aka “сеньор”
Проблема со старшими разработчиками в том, что такой специалист может выполнять различные роли — технического лида, тимлида, интервьюера, специалиста по обучению и т.д. Как правило, эти роли совмещаются в той или иной степени.
Старший разработчик – это человек, который может сделать недельную работу своей команды за один день. Если вы ему не будете мешать. Но делать он этого не будет, потому что он старший разработчик, а значит он, скорее всего, будет проводить собеседования, заполнять матрицы на членов своей команды, пить кофе, присутствовать телом (но не душой) на многочисленных митингах, а также сеять внутри компании
Задача интервьюера – определиться до интервью, кого компания хочет видеть: технического специалиста (упор на технологии) или тимлида (упор на менеджмент).
Если нужен технический специалист, то его нужно спрашивать о доменных областях, в которых он работал, предыдущих проектах, его реальной роли, уровне сложности проектов и размерах/составе команд. Зона компетенции технического сеньора – отдельные компоненты системы и их интеграция, хорошее знание сторонних инструментов (фреймворков, готовых решений, CMS и конкретных библиотек). Не задавайте ему вопросы на синтаксис языка – некоторые конструкции, он, скорее всего, уже забыл, а некоторые ему никогда в жизни так и не пригодились. Или будьте готовы к тому, что он вместо решения выскажет свою готовность отбить пальцы любому, кто напишет что-либо подобное в реальном проекте.
Если вам нужен тимлид, то вопросы должны касаться не технологий, языков программирования, а прочитанных книг по управлению людьми и проектами, аспектах конфликтологии. Убедитесь, что речь соискателя выглядит уверенно. Можно смоделировать какие-то жизненные ситуации (но без фанатизма) и предложить решить их. Но нужно быть готовым, что его методы и способы будут отличаться от ваших. Зона компетенции тимлида – умение быть убедительным, разбираться хоть немного в психологии и менеджменте, а также в технологиях на уровне инструментов (jira, tfs, asana и т.д.).
Нужно помнить, что технарей, которые одновременно являются как сильными специалистами, так и хорошими тимлидами, очень мало. Если вам попался именно такой – не отпугните и сделайте всё возможное, чтобы его заполучить.
Профессионал aka “гуру”
Гуру – это человек, который в критической ситуации может вытащить проект на себе или принять на себя удар. В обычной жизни могут быть заносчивыми, трудно поддаваться на манипуляции и хотеть
Гуру должен гордиться не количеством сделанных проектов или заработанных денег, а максимальным уровнем задач и проблем, которые он решил.
Что спрашивать гуру? Это сложный вопрос, так как гуру, как правило, обладает огромным опытом прохождения собеседований, поэтому перехитрит HR практически на всех уровнях. Пожалуй, самым правильным выходом является ситуация, когда гуру собеседует другой гуру или кто-то из топ-менеджмента. Гуру поймет технический уровень, топ-менеджер, скорее всего, определит, насколько человек подойдет компании. Как правило, если человек гуру, то это все знают и в таком случае каких-то сложных собеседований быть не должно.
Вместо выводов
Если вы ищете специалистов до уровня тимлида или техлида, то собеседование нужно строить исходя из должности и ваших требований (в больших компаниях эту задачу лучше всего поручить кадровому агентству), если выше – исходя из человека и его будущей роли (здесь уже нужно подключать личные связи и нетворкинг). И чем более высокую должность нужно закрыть, тем более индивидуальным должен быть подход. Все это связано с тем, что ИТ-сфера очень сильно отличается от других сфер, поэтому традиционные кейсы, стрессовые и прочие типы собеседований не подойдут. Ведь мидл может быть джуниором в одной компании и сеньором в другой.
Приятных вам собеседований!
