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

В конце добавила секцию с бонусными рубриками — советами и наблюдениями для тех, кто проводит собеседования или приходит на них как кандидат =)

9 (ладно, 7) кругов технического собеседования: как я тестирую соискателей

Итак, с какими‑то вещами кандидаты точно столкнутся у меня на собеседовании, а с какими‑то — точно нет. Начнем, пожалуй, с разбора первых.

1. Проверка любопытности по жизни

В поддержку предыдущего этапа я и тут люблю задавать странные вопросы: «А если вы работали с технологией А, знаете, что есть похожая на нее технология B, как думаете, зачем придумали B?». Причем я не залезаю в узкие области знаний: поддерживая пример про СУБД из первой части статьи, могу спросить: «Вот есть реляционные БД, а зачем начали придумывать нереляционные?». Я не жду академически точного ответа, мне интересно, насколько кандидат задумывается о мире вокруг.

2. Проверка понимания произносимого

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

Поясню на примере. Допустим, в разговоре кандидат произносит фразу «микросервисы более отказоустойчивы, чем монолит». Здесь я обязательно уточню, что именно кандидат имеет в виду под отказоустойчивостью и почему он делает такой вывод. Для проверки способности размышлять могу попросить порассуждать, всегда ли какое‑то популярное утверждение верно. Часто также использую вопросы с антонимами: например, если кандидат уверенно рассказал о нормализации данных, что она прекрасна и ее всегда нужно применять, могу задать вопрос: «Как вы думаете, бывает ли когда‑то полезна денормализация?». Если кандидат сам не озвучивает какое‑либо из достаточно частых утверждений, могу сама произнести нечто в стиле: «Популярным утверждением является то, что микросервисы более отказоустойчивы, чем монолит. Согласны ли вы с этим утверждением и почему?» (и да, я не против ответного вопроса «А что вы подразумеваете под отказоустойчивостью» =) ).

3. Проверка восприятия задач

Если я даю кандидату практическую задачу, я слежу за тем, додумал ли он фоном какие‑то вводные. Специфика аналитической работы такова, что додумывать за постановщика задачи — способ выстрелить себе в лучшем случае в ногу. Поэтому от хорошего аналитика я ожидаю, что он проинтервьюирует собеседника по возникшим вопросам и белым пятнам. Частенько замечаю, что кандидаты придумывают свою собственную задачу, переиначивая исходную из призмы собственного опыта. При первичном восприятии задачи полезно такого не допускать, иначе есть риск решить не проблему заказчика, а свою собственную.

4. Проверка, как именно кандидат ведет работу в качестве аналитика

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

Подобная беседа стоит того, чтобы ее провести. Разные грейды очень хорошо отделяются друг от друга: джуны сразу уходят в «микропроектирование», более сеньорные ребята же задумываются, есть ли уже подобный функционал в системе, и стараются выяснить детали его реализации. Здесь также можно отследить, готов ли кандидат мыслить критически, потому что в исходных данных нет описания проблемы, которую этим баннером пытаются решить. Достаточно небольшое количество кандидатов сначала заводит разговор об истинной болячке — за что получает значительный плюсик в карму =) Отмечу, что итоговый результат каждый раз в достаточной степени уникален, а пару раз был максимально неожиданным и для меня самой.

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

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

Что же на собеседовании со мной увидеть сложно

1. Удлинение собеседования в угоду протоколу

Есть среди интервьюеров в нашей компании определенный перечень вопросов, которые +‑ задают все. Вот только я противная и не слишком дотошно этому протоколу следую. Могу даже у кандидата уточнить,уверен ли он в своих знаниях по определенной теме, или лучше этот раздел опустить. Если я вижу, что собеседование не идет совсем никак (но такое было всего один раз на момент написания статьи) — могу закончить его достаточно быстро. Что же поделать, мне интереснее проверить способности размышлять и применять знания из тех сфер, в которых кандидат уверен, чем поставить галочки по всем хардам. Да, я проверяю любопытство, но не наседаю с этим. Хорошо это или плохо? Ну, вроде пока менеджеры проектов не кидали в меня помидорами за подобранных ребят:»D

Когда‑то человек, который собеседовал меня саму в STM Labs, сказал, что он уже по виду заходящего кандидата может понять, что и как. Для меня тогда это звучало весьма самоуверенно, но теперь я его понимаю. Искажение это восприятия или нет, но мне кажется, что по глазам можно понять процентов на 70%, насколько сильно человек привык к мыслительной работе. Однако этот критерий я использую только для накопления личной статистики =)

2. Общение по направлениям, с которыми аналитики не так уж часто сталкиваются (и не факт, что столкнутся у нас)

Хоть я и люблю людей «горящих» и любопытных, но всему есть свой предел. Есть блоки, редко касающиеся непосредственно аналитиков: для меня это, например, устройство модели OSI, вопросы автоматизации путем написания скриптов, вопросы работы на Linux. Если с этим придется столкнуться в проекте — не вопрос. Но просто так, для общего портрета кандидата… Не знаю. Прилично знать отличия HTTP от HTTPS, классно уметь писать скрипты автоматизации и т. п., но, например, вопросы работы IP‑сетей в последний раз меня лично затрагивали в эпоху работы в технической поддержке. Да и надо еще постараться, включая такие вопросы в стандартный протокол, найти в компании необходимое количество собеседующих, компетентных по всем темам. А вот если кандидат попадется достаточно подкованный, можно и в лужу сесть, просадив имидж компании. Гораздо актуальнее для меня найти соображашку, который в приемлемые сроки расковыряет незнакомую ему тему и начнет применять знания. А это снова не про харды, а про софты.

3. Одинаковые вопросы для всех грейдов

Здесь много сказано и без меня, что «надо знать на джуна» и «надо знать на миддла». Сама я добавляю чуть больше вопросов по хардам в зависимости от того, насколько сеньорнее себя оценивает кандидат. Но, как к этому моменту уже очевидно, я фанат софтов:D Чаще даже меняю задачи: для сеньора попробую придумать что‑то более неопределенное и на проектирование, буду давать менее конкретные вводные и больше свободы. Для джуна дам что‑то не на глобальном.

Куда: можно ли сделать собеседования еще эффективнее

Еще одна шутка‑минутка. Итак, пара моих реальных соображений:

1. Добавление более актуальных форм задач

Что мы делаем сейчас, решая практически любую задачу? Ищем информацию в Интернете. Хотелось бы придумать вопросы, для которых исходных навыков кандидата наверняка будет недостаточно, и ему придется обратиться к Google. И разрешить ему искать. Есть риск, конечно, что всю задачу он скормит одной небезызвестной языковой модели, но такой риск возможен с любым вопросом.

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

2. Добавление большей ориентации на проект

Хотелось бы больше вникать в то, кого ищет менеджер конкретного проекта, и о чем этот проект. Да‑да, софты решают, но клиентоориентированность тоже полезна. Почему я недостаточно клиентоориентирована сейчас? Я просто не успеваю в это, если честно:»D

Пока что вижу пару таких точек роста. Если кто‑то поделится в комментариях своими идеями, — буду очень признательна =)

Бонусная рубрика 0: чтобы что

В комментариях к первой половине статьи меня поймали на том, что рубрика «чтобы что» (т. е. зачем все эти ритуальные пляски) отсутствует.

Тут все просто — чтобы у компании были сильные специалисты, готовые к самым разным вызовам, ценящие свое дело и развивающиеся.

Бонусная рубрика 1: гармоничное сосуществование в паре

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

Не забывай про ближнего своего

Если есть второй собеседующий, и я оказалась в роли основного ведущего, то я стараюсь не забывать про своего коллегу. Спросила, что хотела — передала эстафетную палочку ему или ей. Один раз оказалась в ситуации, что меня для второго интервьюера как будто не существовало. Крайне неприятненько, не надо так.

Поиск верной стратегии

Чтобы все интервьюеры были одинаково полезны, важно правильно оценить происходящее. Я сталкивалась со следующими подходами к разделению обязанностей:

• один — ведущий, второй — на подхвате

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

• каждый отвечает за свой экспертный домен

У каждого из нас есть свой уникальный опыт и области экспертизы. Очень здорово учитывать сильные стороны друг друга. Была у меня с одним аналитиком такая синергия, на собеседования ходить было одно удовольствие =)

Бонусная рубрика 2: специально для кандидатов — приоткрываем завесу мира интервьюеров

Тут я хочу сказать всем кандидатам, что интервьюер тоже человек. Он тоже может устать, может недопонять вашу идею, может фоном думать о том, выключил ли он дома утюг. Нам тоже может быть страшно, например, что вы будете настолько классными, что мы не сможем провести собеседование =) Часто мы переживаем, что это не ваших знаний недостаточно, а мы плохо задаем вопросы.

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

Бонусная рубрика 3: ну а как ты сама себя ведешь в роли кандидата

Как‑то так, если честно:

О своих интервьюерных повадках рассказала, поделюсь и тем, какой я кандидат.

1. Честно сообщаю о своих слабых сторонах / областях, куда я сейчас не хочу развиваться

Для меня это, как минимум, проектирование user‑friendly интерфейсов. Ну вот неинтересно это мне, ну никак. И проектирование Frontend»а тоже плохо идет, надо бы поразбираться в специфике фреймворков, но мне интереснее нырнуть в ООП на Python, или развернуть у себя неведомую СУБД, ну что ж поделать. Неожиданно, признаваться в слабостях выгодно — я все чаще попадаю на проекты, где нужны навыки, которые мне нравится наращивать.

2. Честно говорю, что где‑то мне надо погуглить и расширить знания

Как‑то мне рассказали про кандидата в программисты, который на собеседовании сказал: «Я помню, как это делать, но точный синтаксис не подскажу, могу нагуглить». Прекрасный ответ, я считаю:D

3. Докапываюсь до задач, пытаясь понять, какую проблему они призваны решить

Часто задачи после этого резко отваливаются. Как‑то мне задали такую ситуацию: «Вам необходимо добавить в отчет новую колонку, в которую нужно вывести среднее по строке значение. Что будете делать?». Говорю: спрошу, что решит это среднее для того, кто пользуется отчетом. Почему они раньше без него жили, а сейчас не могут? Либо это был ожидаемый ответ, либо интервьюер не нашелся, как продолжать. В итоге я всем понравилась:D

4. Не готовлюсь к собеседованиям

Это лично моя заморочка, основанная на том, что можно вложить ооочень много информации в краткосрочную память, вызубрив все за пару часов до собеседования, но после него, когда наступит период расслабления, 90% информации (а то и больше) благополучно выветрится из головы. Получается, я обманываю компанию, в которую прохожу собеседование, демонстрирую интервьюерам знания, которых нет. Мне не нравится как факт обмана, так и потенциально завышенные от меня ожидания на потенциальном месте работы. Ничего, кроме лишнего давления, это не добавит.

5. А в целом я достаточно душная =)

Я не умею отвечать на стандартные для большинства вопросы. Недавно спросили: «Какие артефакты вы оставляете по факту проведенной работы?». Наверное, ожидалось нечто в духе: «Я использую нотации A, B, C, знаю ГОСТ 2029–100 500 и веду итоги каждой встречи». Интервьюер получил не это, а вопрос: «Какова структура команды, и где заканчивается зона ответственности аналитика? Если есть архитектор, это одна история, и зависит даже от того, насколько этот архитектор про технику…» — и так далее.

Потому что аналитик — это способ мышления. А как я его буду отображать в артефактах — задача многопараметрическая =)