Оценка аналитика: взгляд со стороны IT-рекрутера

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

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

А требования к HR у вас есть?

Ох, там и дальше..

Другим важным требованием является знание UML, работал ли аналитик с UML, отрисовывал сам или использовал PlantUML, какие типы диаграмм ему приходилось использовать на проектах.

Судя по вакансии, задачи этого аналитика крутятся вокруг простых интеграций, поэтому из всего UML.нужны будут sequence-диаграммы. Диаграммы классов не нужны, состояний - возможно, развертывания и классов - нафик. Научиться рисовать sequence в PlantUML - дело пяти минут.

приходилось ли работать с Public API

Ась? Вы под этим термином что-то конкретное имеете в виду? Или просто был ли опыт подключения к сервису по заданной спецификации API?

на каком уровне приходилось работать с Kafka и тп.

Не вижу в вакансии Кафку. Предположу, что на этом этапе проекта ее там нет.

А какие уровни "работы с Кафкой" у аналитика вы разделяете?

Также часто требования включают работу с базами данных и SQL – приходилось ли тебе проектировать БД, какие модели данных описывал? Пишешь ли ты запросы к БД напрямую или используешь ORM?

Мне вот интересно, как системный аналитик пишет запросы к БД, используя ORM? СА писателем запросов работает вместо разработчика? Или, я наверное не в курсе, в админки СУБД завезли ORM?

Знание методологий разработки ПО (Agile, Waterfall, Scrum)

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

Прочие новости: вода жидкая

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

Пишешь ли ты запросы к БД напрямую или используешь ORM? И все в этом духе.

Если смотреть по тексту, то больше всего насторожили слова про чтение кода недокументированной системы и пассаж про написание запросов к БД, особенно через ORM. Да, способность по коду понять общую логику полезна, но тут надо трезво смотреть на вещи: не каждый аналитик способен (да и вообще не обязан) разбираться в хитросплетениях каких-нибудь лямбда-функций или сишных алгоритмов.

Такие вещи наталкивают на мысль, что работодатель ищет человека, на которого можно будет сгружать всё, что не понравилось делать остальным. При этом оплата, конечно же, будет ниже, чем у тех, кто "делегировал" эту работу аналитику. Я уже сталкивался с такого рода вакансиями раньше. Из примеров: улучшение плана выполнения запросов к БД; описание системы AS IS по коду legacy-системы; разбор инцидентов на проме в режиме 24/7; и даже разработка методологии работы с процентным риском. Ничего хорошего такие вакансии не сулят.

К тому же, если в перспективе ты рассматриваешь рост в архитектора или техлида, то уже на старте стоит прокачивать техничку и задаваться вопросами в стиле «почему в нашем случае оптимальнее использовать Rest‑сервис, нежели что‑то еще».

Ну и вообще, в последнее время наблюдаю, что аналитика всё чаще рассматривают как человека, который будет только "городить" интеграции. Складывается ощущение, что этап анализа задачи (изучение вопроса, погружение в предметную область, поиск потребностей, выравнивание понимания и пр.) уже никому не интересен сам по себе, ибо он якобы проведён. Получается такая идеализированная картина: тебе принесли задачу (уже якобы готовую), а от тебя ждут формальной фиксации этой задачи в каком-то документе/спеке (с применением сиквенсов, конечно, т.к. сиквенсы должны быть просто потому, что так все делают и у кого-то в чек-листе даже есть об этом пункт) и непременно описание интеграционных взаимодействий. Не говорю, что так везде, но смещение фокуса такое наблюдаю.

Очередная ода о пользе hr..... после такого собеседования senior пьёт корвалол, midle- виски, а руководитель слушает офигенную историю, о том, что в Москве людей нет, а из России все уехали.....

главное, что я не понял по статье — как так получилось, что оценку Hard Skills, и даже «скрининг», начали проводить рекрутёры. всегда это делали профильные специалисты

это самоубийство

«Мог ли он вежливо объяснить, что его интересует сейчас»

вы мне кажется путаете soft skills и attitude-values

кандидат мог резко оборвать разговор не потому, что не умеет иначе, а потому что не хочет с вами сюсюкаться, особенно в условиях, когда рекрутёры пытаются оценивать то, в чём не являются профи

«Помните, что soft skills — обширное понятие, и развитие в себе таких качеств как эмпатия, вежливость, навыки коммуникации»

как раз софты могли бы пытаться оценивать рекрутёры, тк ИТ-специалисты в них слабо ориентируются

но тут по вашему списку тоже видно, что вы в них как свинья в апельсинах

если это умения — то они должны быть формулируемы в виде, предполагающем оценку достижения результата (да/нет) и его качества:
— проведение интервью с заказчиком

— презентация и защита технических решений

— проведение групповых проектных сессий

что такое «вежливость»? какой у неё результат?