Идеальный ИТ-аналитик (Как нанять лучшего аналитика в команду)

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

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

Зачем проводить техническое интервью?

Интервью, особенно техническое – весьма затратное для компании мероприятие, поскольку на него отвлекается время высококвалифицированных технических специалистов, которые и являются основным активом ИТ-компаний. Стоимость часа этих специалистов высока, а потребность в их услугах на проектах обычно больше, чем доступное время в сутках.

То есть компании тратят на интервью дорогостоящий дефицитный ресурс, так зачем они делают это?

Первое, что приходит на ум – чтобы проверить технические знания.

Да, это важно, но можно сделать с помощью тестов и заданий, существенную часть которых можно вообще автоматизировать.

Тогда, может быть, чтобы проверить адекватность кандидата?

Тоже верно, но с этим вполне справляются специалисты HR без привлечения технических экспертов.

Тогда зачем?

А вот зачем: как мы поняли ранее, наши кандидаты не идеальны, как, впрочем, и почти все в нашем замечательном мире. Поэтому проверка формальными тестами скорее всего отсеет существенно большую их часть, или не совсем ту часть, которая подходит нам, чтобы встроить их в «пазл» команды и проекта. Это произойдет еще и потому, что встроить можно и за счет других компетенций, которые даже и не упоминались в профиле. Таким образом мы не только можем существенно быстрее укомплектовать команду недостающими специалистами, но и построить уникальный «симбиоз», многократно усиливающий способности команды по решению задач.

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

Структура технического интервью

В ходе технического интервью обе стороны, кандидат и наниматель, отвечают себе на вопрос, могут ли они построить приемлемый «пазл» команды проекта вместе с этим кандидатом. Тут же определяются риски построения такого «пазла» для обеих сторон и соизмеримость условий и предлагаемой компенсации.

Теперь непосредственно о структуре интервью.

Конечно, умным людям всегда есть, о чем поговорить, поэтому интервью с аналитиком может затянуться. И всем нам, аналитикам, известно, чтобы оставаться в разумных временных рамках, целесообразно придерживаться плана и структуры. Так какие же блоки нужны, чтобы понять, подходим ли мы друг другу?

Блок 1 – правила игры

Сначала целесообразно узнать, как представляет себе кандидат позицию «аналитик», чего он ждет от работы, опираясь на имеющуюся у него информацию.

По сути, это первое задание на анализ и изложение результатов: что мы написали в объявлении, что известно о компании, что говорят другие сотрудники, что в прессе и в Интернете, что показывает собственный опыт – все это и изложит кандидат в ответе на вопрос.

Заданный в произвольном месте вопрос «а почему Вы так считаете?» отлично прояснит способность к логическому рассуждению и навыки ведения общего диалога. И не забываем про метапрограммы.

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

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

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

Блок 2 – базовые понятия

Базовые вещи, такие как жизненный цикл программного обеспечения, понятия требований, процессов, основы алгоритмов, несомненно, должны составлять тот базовый «гигиенический» уровень знаний, который имеет кандидат.

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

Вопросы тут задаются простые и прямые, например, «Какие основные этапы жизненного цикла проходит программное обеспечение при заказной разработке?», «Что такое требование?», и т.п. Диалог в этом блоке может пойти по-разному, приведем некоторые варианты.