Привет, Хабр! Меня зовут Лиза, и я — руководитель команды подбора. В течение последних 3 лет я активно занимаюсь подбором IT‑специалистов, а системные аналитики занимают отдельное место в моем сердце. За это время я отсмотрела не одну тысячу резюме и провела несколько сотен собеседований. В рамках данной статьи я расскажу, как проходит оценка технических компетенций аналитика на этапе IT‑рекрутера, на что стоит обращать внимание во время собеседования, и на примере реальной вакансии поделюсь лайфхаками, как сделать взаимодействие аналитика и IT‑рекрутера продуктивным и приятным.
Если вы начинающий специалист, который решил строить карьеру в системном анализе, или уже закаленный проектами аналитик, желающий понять, чем руководствуется рекрутер, когда задает «очередной» вопрос, или же если вы начинающий IT‑рекрутер, эта статья будет для вас полезной.
С чего все начиналось?
В конце прошлого года я впервые выступила с докладом о том, как сделать общение с рекрутером более эффективным, на масштабной конференции для аналитиков (привет всем, кто задавал мне вопросы на Analyst Days!) Тема была очень тепло принята аудиторией и меня попросили написать статью для всех, кто не смог тогда участвовать в конференции. Кстати, если кому‑то удобнее послушать/посмотреть видео — делюсь ссылкой.
Приступим)
Все мы знаем, что среди IT‑специалистов общение с рекрутером — не всегда самый любимый этап поиска идеального проекта, но он, как правило, неизбежен. Для того, чтобы приведенная дальше информация была подкреплена фактами, мы с командой провели небольшое исследование — опросили наших сотрудников, и в частности аналитиков, на тему того, что им было важно при коммуникации с рекрутером, и почему они когда‑то выбрали именно нас)
Лидирующее место составил пункт описание этапности процессинга (57% опрошенных). Конечно, всем хочется заранее понимать, сколько времени он займет, есть ли какие‑то дополнительные особенности (тестовые задания, проверки СБ), стоит ли вообще начинать процесс, особенно если у тебя уже есть офферы на руках;)
Далее коллегам была важна информация о проекте и команде (52%) — и тут все понятно, никому не хочется получить «кота в мешке», поэтому рекрутер в идеале должен предоставить максимум информации. При этом какие‑то технические аспекты уточняются уже на этапе собеседования с руководителем, это все должны понимать.
Еще один важный пункт ‑ емкие и понятные вопросы от рекрутера. Мало кто хочет, чтобы первичный этап растягивался на час с плюсом. И чуть менее половины отметили, что им важно, чтобы рекрутер говорил на одном техническом языке с ними (насколько это возможно:) Это помогает лучше понимать друг друга и позволяет оценить компетенции рекрутера.
А что же важно самому рекрутеру, или...
Откуда берутся требования?
Перед тем, как мы перейдем к оценке тех. навыков на этапе общения с рекрутером, давайте рассмотрим, на что мы опираемся в своей работе:
Требования к вакансии — очевидный критерий, на нем заострим внимание чуть дальше.
Ожидания руководителя — именно этот пункт играет ключевую роль в процессе найма. Важно учитывать портрет «идеального кандидата» — кому‑то важны конкретные hard‑скиллы, кому‑то — soft, а кто‑то в первую очередь смотрит на то, насколько ценности кандидата совпадают с ценностями команды.
Различные регламенты по процессу подбора, включая количество этапов, наличие скринингов и тестовых заданий.
Коммуникации с IT‑специалистами, особенно аналитиками позволяют быть в курсе тенденций.
Изучение тематических статей, подкастов, интервью — дополнительные внешние и внутренние обучения также позволяют справиться с этой задачей.
Личный опыт и опыт коллег по работе с той или иной позицией или руководителем позволяет экономить время кандидатов и команды.
А теперь давайте скорее перейдем к оценке специалиста. С чего же она начинается?
Продающее СV по‑честному: как грамотно составленное резюме увеличивает шансы попасть в команду мечты
Не зря в народе говорили «встречают по одежке...» Это выражение хорошо накладывается и на процесс подбора. Резюме — это лицо кандидата перед рекрутером. Обращайте внимание на информативность, структурированность и четкость изложения опыта и навыков в своем резюме. За время работы ИТ‑рекрутером я отсмотрела большое количество резюме и пообщалась со моими коллегами в сфере подбора, и вот что могу вам сказать — пользуйтесь стандартным шаблоном составления резюме на hh! Если вы не планируете подавать резюме в какую‑то иностранную компанию напрямую, то не стоит ничего выдумывать, делать его в Figma и тп — так вы только усложните работу и себе, и рекрутеру).
А на что именно мы смотрим, когда знакомимся с кандидатом впервые, разберем далее:
Опыт (тут стоит быть честным, например, не выдавать учебный опыт за коммерческий). Многие начинающие специалисты могут очень хорошо составить резюме, но на собеседовании все равно рекрутер пройдется по навыкам, и все станет понятно. Тут лучше обозначать реальный опыт. Так вы добьетесь более качественной воронки по поиску «компании мечты».
Название желаемой должности дает ориентир, чего человек хочет и по итогу с большей вероятностью выберет.
Проекты. К сожалению, не все их указывают, но даже краткая информация о них позволит сократить время собеседования.
Результаты лучше обозначать, особенно, если вы рассматриваете какие‑то менеджерские позиции. Здесь могут быть количественные показатели или качественные. Например, успешно выпущен MVP продукта, разработаны микросервисы, отвечающие за... и тп.
Реально выполняемые задачи. Достижения команды — это прекрасно, но в своем резюме лучше также отразить, что было непосредственно в твоей зоне ответственности.
Ключевые навыки / технологии / инструменты, с которыми ты работал — о них поговорим в следующем блоке.
Краткая информация о себе, своих профессиональных (и не только) интересах — не обязательный пункт, но он может вас выделить среди всех). Также «О себе» — то место, где можно заранее уточнить, например, твои пожелания к компаниям.
Сюда же включу пункт «причины смены мест работы» — если в последнее время тебя преследовала череда неудач (или наоборот везения:), кратко отрази причины переходов.
Вывод: простое и лаконичное резюме с hh, честность, структурированность и немного оригинальности повысят шансы найти «тот самый проект мечты»)
Что может рекрутер: как происходит оценка hard skills рекрутером?
Резюме разобрали, теперь перейдем к тому, как проходит оценка тех.скиллов уже при общении.
Чтобы создавать тот самый мэтч с командой и руководителем, многие рекрутеры, помимо стандартных вопросов про мотивацию, причины поиска, интересы кандидата и т. п. — все мы знаем эти вопросы ;) — проводят технические скрининги.
Эти скрининги формируются на основе общения с руководителями и техническими экспертами. Однако, многие из вас не раз могли замечать схожесть вопросов у разных компаний, поэтому к моменту 3–5 собеседования кандидат в аналитики уже готов к ним и выдает все то, что рекрутер хочет услышать). Это классно, но на своем этапе нам важно понимать, насколько это соответствует действительному опыту. Рекрутер проводит первичную оценку, и если ваши слова на техническом собеседовании не подтвердятся, вы попросту потратите и свое время на «еще одно собеседование», и время руководителя. Во избежании этого приходится копать чуть глубже и задавать доуточняющие вопросы.
Для примера разберем основные требования к одной из вакансий, которая есть сейчас у нас в работе.
Например, в вакансии требуется знание и опыт описания бизнес‑процессов. Мы можем пойти издалека, попросить рассказать о составе команды, текущих процессах, кто за что отвечает. Мы уточним, как выглядели постановки, какие нотации использовал кандидат в своей работе (например, BPMN), и насколько глубок был его опыт (четкое следование нотации, уровень автоматизации или просто рисовалки).
Другим важным требованием является знание UML, работал ли аналитик с UML, отрисовывал сам или использовал PlantUML, какие типы диаграмм ему приходилось использовать на проектах.
Следующим ключевым навыком идет проектирование интеграционных решений или понимание различных типов интеграции (в зависимости от уровня специалиста). Умение описывать интеграции, проектировать веб‑сервисы, работать с брокерами сообщений — все это отражает профессиональный кругозор аналитика. На этом блоке вопросов я, например, выясняю, как выглядели постановки, приходилось ли работать с Public API, на каком уровне приходилось работать с Kafka и тп. К тому же, если в перспективе ты рассматриваешь рост в архитектора или техлида, то уже на старте стоит прокачивать техничку и задаваться вопросами в стиле «почему в нашем случае оптимальнее использовать Rest‑сервис, нежели что‑то еще».
Также часто требования включают работу с базами данных и SQL ‑ приходилось ли тебе проектировать БД, какие модели данных описывал? Пишешь ли ты запросы к БД напрямую или используешь ORM? И все в этом духе.
Знание методологий разработки ПО (Agile, Waterfall, Scrum) — тут редко прям заостряю внимание, т.к. сейчас большинство компаний строят процессы разработки в Agile‑методологиях.
И знание языков программирования — аналитик должен понимать технологическое окружение, в котором происходит разработка проектов. Более сильные специалисты могут ориентироваться в коде разработчиков (особенно это пригождалось и пригождается, если проект довольно старый или отсутствует нужная документация). Этот пункт рекрутер вряд ли сможет проверить в рамках своего этапа. Но если у вас есть навык чтения какого‑либо кода, то можно подсветить это во время общения.
Все эти вопросы мы стараемся уложить в максимально сжатый срок, т.к. понимаем, что тебе еще предстоит, возможно, не один, а несколько этапов, и не хочется отнимать у тебя много времени). Помним про «емкие и простые вопросы» на этапе с рекрутером.
Кстати, на IT‑рекрутере оценка скиллов может не замыкаться, нам на помощь могут приходить РЦК — это такие технические эксперты, которые могут провести точную оценку твоих скиллов и дать рекомендации по проектам, направить тебя в рамках дальнейшего професcионального развития и помочь быстро влиться в аналитическое коммьюнити компании. Кроме того, техлиды и различного рода руководители центров компетенций могут привлекаться к обучению команды подбора, чтобы наши с тобой технические скрининги проходили максимально легко и комфортно). В каких‑то компаниях РЦК есть, в каких‑то — нет, здесь скорее акцент на том, что у рекрутера могут быть сильные помощники).
Не хардами едиными...почему софт-скиллы так важны на современном рынке
Когда технический портрет кандидата составлен, стоит затронуть тему оценки софт‑скиллов, ведь на 10 отказов по хардам приходится около 8 отказов по софтам.
В начале я уже упоминала опрос наших сотрудников, в нем мы также попросили их поделиться своим мнением насчет важности Soft skills по отношению к hard‑ам.
Итоги исследования показали, что 66,7% опрошенных аналитиков не разделяют важность софт и хард скиллов, при этом почти 24% отдают приоритет — софтам, и только около 10% считают харды важнее. Цифры вполне впечатляющие.
Конечно же все зависит от вашей роли и вакансии, на которую вы претендуете. Для разработчика, например, харды будут в большем приоритете, а вот для аналитиков важно не сплоховать в софтах. Порой команда готова вложиться и подтянуть харды специалиста, но если по впечатлению от коммуникации не случился метч — вряд ли сложиться дальнейшее сотрудничество.
Приведу пример — у меня было собеседование с сильным СА, рассказала ему все про проект, команду, описала идеального для нее кандидата, вроде все сложилось, кандидат заинтересовался. Само собой, по опыту его пригласили на собеседование. Но спустя 5 минут технического собеседования он оборвал рассказ лида про проект, сказал команде, что мы «не сработаемся» и вышел из конференции, не обозначив причины. Понятно, что ему не понравилось что‑то и он не хотел тратить свое время, но как он это сделал — вопрос. Мог ли он вежливо объяснить, что его интересует сейчас и почему команда, с которой он общается, ему не подходит — конечно. Но не стал этого делать. И да, такое случается, но это может стать звоночком и для рекрутера, и для команды.
Помните, что soft skills — обширное понятие, и развитие в себе таких качеств как эмпатия, вежливость, навыки коммуникации и т. д., может произвести неизгладимое впечатление на руководителя и команду! )
Как влюбить рекрутера в себя и свои навыки?
В заключении, хочу подчеркнуть, что взаимодействие с рекрутерами может быть не только полезным, но и приятным опытом. Хороший рекрутер может помочь в составлении резюме, поиске нового проекта, дать карьерную консультацию или свести с нужным человеком, ведь, как правило, у него в знакомых большая сеть контактов.
Не стесняйтесь общаться с нами, обсуждать свои цели и пожелания, задавать вопросы, ведь наша задача — помочь вам найти идеальное место для роста и развития. Рекрутер — ваш партнер, готовый поддержать вас на профессиональном пути. Будьте открыты к общению, проявляйте заинтересованность, демонстрируйте свои hard и soft скиллы, и тогда у вас точно сложится дружба с рекрутером).
Благодарю, что дочитали до конца. Надеюсь, информация в статье поможет тебе при поиске идеального проекта.
Комментарии (6)
sshmakov
27.03.2024 12:13Ох, там и дальше..
Другим важным требованием является знание UML, работал ли аналитик с UML, отрисовывал сам или использовал PlantUML, какие типы диаграмм ему приходилось использовать на проектах.
Судя по вакансии, задачи этого аналитика крутятся вокруг простых интеграций, поэтому из всего UML.нужны будут sequence-диаграммы. Диаграммы классов не нужны, состояний - возможно, развертывания и классов - нафик. Научиться рисовать sequence в PlantUML - дело пяти минут.
приходилось ли работать с Public API
Ась? Вы под этим термином что-то конкретное имеете в виду? Или просто был ли опыт подключения к сервису по заданной спецификации API?
на каком уровне приходилось работать с Kafka и тп.
Не вижу в вакансии Кафку. Предположу, что на этом этапе проекта ее там нет.
А какие уровни "работы с Кафкой" у аналитика вы разделяете?
Также часто требования включают работу с базами данных и SQL – приходилось ли тебе проектировать БД, какие модели данных описывал? Пишешь ли ты запросы к БД напрямую или используешь ORM?
Мне вот интересно, как системный аналитик пишет запросы к БД, используя ORM? СА писателем запросов работает вместо разработчика? Или, я наверное не в курсе, в админки СУБД завезли ORM?
Знание методологий разработки ПО (Agile, Waterfall, Scrum)
Вы с этим поосторожнее, а то граммар-наци набегут и закричат, что ничего из перечисленного не является методологией. Первое - манифест, второе - модель, третье - фреймворк. Хотя это разделение практического смысла не имеет.
RomanSeleznev
27.03.2024 12:13+2Из скрина с резюме удивил пункт о понимании своей зоны ответственности. Как это может быть требованием? В каждой компании или даже команде ответственность разная, по-разному нарезан функционал между ролями и по-разному выстроен процесс. Соответственно, я бы это рассматривал как условия на конкретном месте работы, а не как входное требование.
Пишешь ли ты запросы к БД напрямую или используешь ORM? И все в этом духе.
Если смотреть по тексту, то больше всего насторожили слова про чтение кода недокументированной системы и пассаж про написание запросов к БД, особенно через ORM. Да, способность по коду понять общую логику полезна, но тут надо трезво смотреть на вещи: не каждый аналитик способен (да и вообще не обязан) разбираться в хитросплетениях каких-нибудь лямбда-функций или сишных алгоритмов.
Такие вещи наталкивают на мысль, что работодатель ищет человека, на которого можно будет сгружать всё, что не понравилось делать остальным. При этом оплата, конечно же, будет ниже, чем у тех, кто "делегировал" эту работу аналитику. Я уже сталкивался с такого рода вакансиями раньше. Из примеров: улучшение плана выполнения запросов к БД; описание системы AS IS по коду legacy-системы; разбор инцидентов на проме в режиме 24/7; и даже разработка методологии работы с процентным риском. Ничего хорошего такие вакансии не сулят.
К тому же, если в перспективе ты рассматриваешь рост в архитектора или техлида, то уже на старте стоит прокачивать техничку и задаваться вопросами в стиле «почему в нашем случае оптимальнее использовать Rest‑сервис, нежели что‑то еще».
Ну и вообще, в последнее время наблюдаю, что аналитика всё чаще рассматривают как человека, который будет только "городить" интеграции. Складывается ощущение, что этап анализа задачи (изучение вопроса, погружение в предметную область, поиск потребностей, выравнивание понимания и пр.) уже никому не интересен сам по себе, ибо он якобы проведён. Получается такая идеализированная картина: тебе принесли задачу (уже якобы готовую), а от тебя ждут формальной фиксации этой задачи в каком-то документе/спеке (с применением сиквенсов, конечно, т.к. сиквенсы должны быть просто потому, что так все делают и у кого-то в чек-листе даже есть об этом пункт) и непременно описание интеграционных взаимодействий. Не говорю, что так везде, но смещение фокуса такое наблюдаю.
Chetverg_g
27.03.2024 12:13+1Очередная ода о пользе hr..... после такого собеседования senior пьёт корвалол, midle- виски, а руководитель слушает офигенную историю, о том, что в Москве людей нет, а из России все уехали.....
sshmakov
Вообще-то вы ошибаетесь. В приведенной вакансии ничего не сказано о бизнес-процессах. Сказано о нотациях, но этими нотациями не только бизнес-процессы описываются.