Денис Чемерис

PRO ожидания от новичка на испытательном сроке

2025-01-13T17:41:39.775Z

Адаптация новичка в команде состоит из двух этапов:

Стажировка (от 1 недели до месяца) – решение вне проектных задач, обычно из пула технического долга;
Испытательный срок (классически всего 3 месяца, включая стажировку) – работа уже в команде в "боевых" условиях, но на связи с наставником.

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

Обычно у нас получается такой цикл:

Цикл испытательного срока

Стажировка или тестовая неделя/задача 📅

На этом этапе главная задача – показать, что ты умеешь давать результат в том виде, в котором он требуется. Для этого лучше идти по такой лестнице:

Процесс прохождения стажировки

В рамках этого периода мы обращаем внимание на поинты ниже.

1. Умение решать поставленную задачу.

Есть задача, есть примеры решения подобных задач, есть инструкции/регламенты/шаблоны для того, чтобы описать ТЗ. Это всё, что необходимо на этом этапе.

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

Здесь следует набраться терпения и показать результат.

2. Умение адаптироваться.

Да, компания новая, да, процессы часто - другие, или тем не менее не «один-в-один». Когда в компании есть 20+ аналитиков и они работают по существующему процессу (и им ОК), то вероятность, что до тебя все заблуждались, стремится к нулю, но она есть.

См. пункт 1, но сразу не критикуй, еще рано.

3. Внимательность.

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

Умение декомпозировать большую задачу на мелкие - в этом случае также будет кстати. Мелкие неточности и пропуск некоторых моментов допустимы, но не 3-4 раза подряд. Здесь ожидается, что через 1 итерацию ревью ТЗ будет принято.

4. Умение признавать ошибки.

Ошибки будут, и это следствие первых трех пунктов. Можно винить наставника, процесс адаптации или его отсутствие, неправильные регламенты, обстоятельства и всё что угодно, но только не признавать, что не спросил, когда нужно было, неправильно оценил задачу и/или просто невнимательно прочитал, или вообще не прочитал правила и регламенты.

На испытательном сроке от тебя не ждут подвигов. Они потребуются после. Поэтому умение быстро принять к сведению замечания, исправиться и идти дальше – экономит время и нервы.

5. Умение оценить свои силы адекватно.

Велик соблазн с первых дней показать себя с лучшей стороны и занижать оценки.

Это приводит чаще всего к тому, что работаешь ночью и/или в выходные, чтобы уложиться в поставленную оценку. Потом это трансформируется в негатив, т.к. вау-эффекта не случается — ты настоял на том, что сделаешь за Х дней, сделал за Х дней — это нормально. Не удивляйся, если потом от тебя будут ждать выполнения этой же задачи в твой же сжатый период.

Декомпозиция задачи здесь выходит на первое место. Умеешь разделять и объективно оценивать свою эффективность — проблемы с верной оценкой задачи у тебя не возникнет.

6. Наличие запросов на консультацию.

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

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

Тем более, повторюсь, что подвигов на этом этапе никто не ожидает.

7. Обратная связь от наставника.

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

По итогам выполненной работы собираем обратную связь с команды и смотрим, на сколько всё адекватно и комфортно. Если всё отлично, то двигаемся дальше.

Испытательный срок 🕒

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

8. Обратная связь от команды.

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

Если в общем обратная связь положительная, то работаем дальше.

9. Наличие вопросов и предложений.

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

И вот тут, уже по прошествии месяца работы, когда удалось поработать на новом месте по новым правилам, уместна любая объективная обратная связь, критика, предложения.

10. Стабильность

Далее закрепляем еще 1-2 месяца. И, вуаля, перед нами - новый системный аналитик.

Как тебе материал? Понравился? Ставь 👍

Всем отличной 🍁 среды и продуктивной недели!

Больше пользы здесь 👉: @pro_system_analysis

PRO собеседование системных аналитиков

2024-11-28T22:43:17.733Z

Часть 05. Оценка примера ТЗ и финальное собеседование

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

Этапы собеседования системного аналитика.

Этап 5. Оценка примера технического задания

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

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

Как мы проговаривали в предыдущей части (здесь), в конце пройденного технического собеседования будет правильным запросить пример технического задания в том виде, в котором его привык описывать кандидат на предыдущем или текущем месте работы.

Из практики:

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

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

Рекомендации:

Не поленитесь и подготовьте заранее своё лучшее техническое задание. Обезличьте его, чтобы не нарушать требований NDA. При рассмотрении примеров ТЗ обращается внимание на четкую и логичную структуру документа, на применяемые подходы к именованию и т.п., а не на примеры данных. Так что смело можете их закрашивать.

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

Этап 6. Финальное собеседование

На самом деле этот этап является самым непредсказуемым. На этом этапе могу задать самые неожиданные вопросы, т.к. состав участников непостоянный.

Обычно в финальном собеседовании принимают участие:

будущий непосредственный руководитель
будущий руководитель проекта/продукта, а иногда и в компании с владельцем продукта
будущий руководитель направления/департамента/управления
коллеги из HR

и такое разнообразие участников приводит к тому, что каждый может задать свой список вопросов.

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

Из практики:

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

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

Рекомендация:

Как и на предыдущих этапах собеседования нужно быть честными и тогда не придётся на протяжении всех этапом собеседования помнить что и где было сказано. Просто расслабьтесь и говорите как есть.

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

Заключение

Мы последовательно рассмотрели все 6 этапов собеседования кандидатов на должность системного аналитика. Конечно есть еще этапы по выставлению оффера и ожиданию выхода нового коллеги, но это за скобками.

От себя хочу отметить, что очень хотел бы проводить меньше собеседований и быстрее закрывать наши потребности в системных аналитиках, поэтому описал процесс максимально подробно.

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

Успешных собеседований!

Предыдущие части:

Как тебе материал? Понравился? Ставь 👍

Всем отличной 🍁 среды и продуктивной недели!

Больше пользы здесь 👉: @pro_system_analysis

PRO собеседование системных аналитиков

2024-11-28T07:02:28.225Z

Часть 04. Техническое интервью

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

Этапы собеседования системного аналитика

Этап 4. Оценка результатов технического собеседования

Техническое собеседование состоит из следующих этапов:

Знакомство с кандидатом;
Обсуждение нашей потребности;
Вопросы на понимание роли системного аналитика;
Проектирование простого web-приложения;
Ответы на вопросы кандидата.

Алгоритм технического собеседования

Шаг 4.1. Знакомство

На этом этапе наши задачи следующие:

Представиться;
Договориться о форме общения (в 100% случаев это переход на "ТЫ");
Рассказать о сценарии собеседования;
Рассказать о том, что потребуется от кандидата (напомнить про демонстрацию экрана, необходимость взять бумагу и ручку, если это нужно, стакан воды);
Напомнить про нашу компанию.

На этом этапе мы никогда не предлагаем: "Расскажи, пожалуйста, о себе".

Во-первых, всё что кандидат хотел бы рассказать о себе, должно быть в резюме, и мы его уже несколько раз изучили (Часть 2. Оценка резюме и Часть 3. Технический скрининг).

Во-вторых, обычно такой рассказ занимает минут 10-15, а мы еще не успели напомнить о нашей потребности кандидату.

Из практики:

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

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

Лайвхак:

Каждый раз я говорю одну и туже фразу, которая "топит лёд": "Сперва своими вопросами мы помучаем тебя. А потом у тебя будет шанс отыграться за всё и позадавать вопросы нас. Хорошо?"

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

Шаг 4.2. Напоминание о потребности

На этом этапе наши задачи следующие:

Напомнить кандидату кого мы ищем, т.е. кого называют "системный аналитик" в нашей компании и какие навыки требуются обязательно, а какие - опционально.
Рассказать про проект или проекты, куда сейчас выполняется подбор системных аналитиков.
Рассказать немного прo flow, адаптацию, методологию, шаблоны и т.п.

Лайвхак:

В конце обязательно задаём вопрос: "Подходят ли тебе наши требования и условия?".

Если кандидат говорит, что ему всё подходит, то переходим к следующему шагу. Иначе можно сэкономить 1 час времени и себе и кандидату, если предложение неактуально.

Шаг 4.3. Инструктаж

На этом этапе наши задачи следующие:

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

Лайвхак:

В конце обязательно задаём вопрос: "Готов?".

Мелочь, но позволяет настроиться на нужный лад.

Шаг 4.4. Вопросы на понимание роли системного аналитика

Здесь мы задаём вопросы по типу:

Кто такой "системный аналитик"?
На сколько сейчас ты работаешь близко к должности системного аналитика?
Какими инструментами и зачем ты пользуешься?
Как выглядит flow поставки ценности на текущем месте?

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

Из практики:

На этом этапе иногда становится понятно, что кандидат перед нами на самом деле:

Делает то, что делает "бизнес-аналитик";
Думает так, как думает "бизнес-аналитик";
Пользуется инструментами, которыми пользуется "бизнес-аналитик", использует слова, которыми чаще всего оперирует "бизнес-аналитик".

Тут мы еще раз уточняем: действительно ли мы хотим продолжать собеседование на должность "системный аналитик"? Если, тем не менее, ответ утвердительный, то идём дальше.

Шаг 4.5. Проектирование приложения

Всё начинается с демонстрации экрана кандидатом и проговаривания задачи.

На данном этапе мы предлагаем кандидату спроектировать небольшое web-приложение, которое решает достаточно простую прикладную задачу.

Из практики:

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

Например задачи:

Покупка билета или запись на приём к врачу. Обязательно говорим, что это mvp и что решение может быть неоптимальным, а наша задача дешево и быстро проверить гипотезу.

Цель: написать техническое задание для разработчиков.

Инструмент: на выбор кандидата.

Далее мы проходим по всем тем требованиям, которые были заявлены в вакансии, но не в форме вопросов-ответов, а в процессе проектирования.

Темы, которые проходим на собеседовании.

4.5. 1. Работа с требованиями и архитектура решения

На что смотрим:

Будет ли этап работы с требованиями (их соберут, опишут, переспросят - всё ли учли?);
Будет ли этап проектирования архитектуры (прежде, чем начинать проектировать базу данных или api, появится ли схема решения?)

Из практики:

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

Рекомендации:

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

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

4.5. 2. Проектирование базы данных

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

Здесь мы смотрим за тем:

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

По ходу можем задавать теоретические вопросы.

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

Из практики:

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

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

Обычно кандидаты сами всё понимают и согласны с нами, что по непонятным или понятным причинам не смогли пройти этот этап. Мы еще какое-то время беседуем, даём рекомендации и на этом заканчиваем.

4.5. 3. Синхронное взаимодействие

После того, как схема базы данных готова или условно готова, мы просим кандидата решить задачку по выводу на UI списка записей.

Здесь мы даём кандидату свободу предложить решение. Однако в подавляющем большинстве случаев мы начинаем проектироваться GET метод в стиле REST.

Как только мы получили первый вариант сигнатуры метода, мы начинаем процесс мутации первоначального варианта с добавлением новых вводных:

"А теперь представим, что есть фильтры. Что изменится?",
"А теперь давай представим, что записей в базе 1 млрд. Что изменится?",
"А еще представим ..." и т.д.

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

Из практики:

На этом этапе тоже случаются случаи, когда кандидаты не могут сформулировать техническое задание, т.к. обычная их постановка - это "Cделайте метод, который данные из базы перенесёт на UI".

Здесь аналогично. Подсказываем и подталкиваем, т.к. из-за стресса бывает, что ребята забывают простые вещи. Но если не помогает, то даём обратную связь и на этом заканчиваем.

4.5. 4. Асинхронное взаимодействие

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

Параллельно обсуждаем то, как будет выглядеть постановка на такое решение, какие есть подводные камни.

Из практики:

Обычно этот этап не занимает много времени.

4.5. 5. Дополнительные (необязательные разделы)

Здесь мы коротко пробегаемся по дополнительным компетенциям:

Работа с 1С-системами;
Работа с bpmn-движками;
и т.п.

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

Шаг 4.6. Вопросы от кандидата

Чтобы дойти до этого этапа, необходимо внимательно следить за таймингом и сделать так, чтобы у нас осталось 10 минут на ответы на вопросы кандидата.

Из практики:

Крайне редко у кандидатов есть вопросы, которые не укладываются в 10 минут, хотя мы готовы обсудить любые вопросы, связанные с процессами адаптации, производства, развития и т.п.

Поэтому в наших собеседованиях отсутствуют:

Вопрос "Расскажи о себе";
Нет никаких логических задачек и заданий на внимание;
Минимум теоретических вопросов, значение которых само по себе не гарантирует наличие навыков;
Задача ставится таким образом, чтобы при наличии практических навыков на каждый из этапов уходило 10-15 минут.

Мы всегда просим кандидата предоставить пример своего "лучшего технического задания". Очень часто возможности предоставить что-то с текущего места работы нет из-за NDA, поэтому у нас был этап проектирования, когда есть возможность задокументировать и составить ТЗ на решение, которое только что обсудили.
Из практики:

Почти в 100% случаев ТЗ нам предоставляют.

Завтра в 09:00 выйдет заключительная часть 🕘.

Будем говорить про анализ примеров ТЗ и финальное интервью.

Предыдущие части:

Как тебе материал? Понравился? Ставь 👍

Всем отличной 🍁 среды и продуктивной недели!

Больше пользы здесь 👉: @pro_system_analysis

PRO собеседование системных аналитиков

2024-11-26T20:27:19.136Z

Часть 03. Телефонное интервью

В рамках этой части рассмотрим 3 этап собеседования системного аналитика, связанный с оценкой результатов телефонного интервью (технический скрининг).

Этапы собеседования системного аналитика

Этап 3. Оценка результатов телефонного интервью

Само интервью, конечно, проводят специалисты HR, однако состав вопросов (технический скрининг) составляется теми, кто дальше будет проводить техническое собеседование.

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

Список групп вопросов выглядит так:

Общие вопросы про текущий опыт;
Опыт работы с требованиями;
Опыт работы с базами данных;
Опыт работы с интеграциями (синхронные и асинхронные);
Опыт работы с 1С;
Собственное позиционирование и планы по развитию.

Состав тем технического скрининга

Вопросы сформулированы так, чтобы понять владеет ли кандидат ключевыми понятиями, и сгруппированы по тем навыкам, которые были заявлены в вакансии (кроме группы 1 и 6 - они имеют общих характер). Интервьюер задаёт вопросы и фиксирует ответы без комментариев.

Группа 1. Общие вопросы про текущий опыт

Примеры вопросов по теме:

Есть ли опыт работы в финтехе (финансово-технической компании)?
Есть ли опыт работы по scrum?

Группа 2. Опыт работы с требованиями

Примеры вопросов по теме:

Есть ли опыт самостоятельного сбора требований?
Какие типы требований знаете?

Группа 3. Опыт работы с базами данных

Примеры вопросов по теме:

С какими СУБД непосредственно работали?
Есть ли опыт проектирования баз данных с нуля?
Какие нормальные формы используете в работе?

Группа 4. Опыт работы с интеграциями

Примеры вопросов по теме:

Есть ли опыт проектирования микросервисов с нуля?
Есть ли опыт проектирования rest-методов с нуля?
Есть ли опыт работы с брокерами сообщений?

Группа 5. Опыт работы с 1С системами

Примеры вопросов по теме:

Есть ли опыт работы с 1С-системами?
Есть ли опыт работы в режиме конфигуратора?
Какие объекты метаданных знаете?

Группа 6. Собственное позиционирование и планы по развитию

Примеры вопросов по теме:

Почему вышли на рынок труда?
Как оцениваете сами свой грейд?
Как видите свой карьерный трек?

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

Из практики

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

Есть опыт проектирования баз данных с нуля? Нет, только доделывал то, что было.
Есть опыт проектирования микросервисов с нуля? Нет, только доделывал то, что было.

К нам на вход по результатам телефонного интервью приходят:

Заполненная анкета технического скрининга;
Общее впечатление коллег от общения с кандидатом.

Оценка скрининга проводится по просмотру ключевых вопросов. Решение о переводе кандидата на этап технического собеседования (об этом поговорим завтра) принимается при наличии нескольких положительных решений от лидов системной аналитики.

Завтра в 10:00 выйдет четвертая и самая интересная часть 🕘.

Будем говорить про техническое собеседование.

Предыдущие части:

Как тебе материал? Понравился? Ставь 👍

Всем отличной 🍁 среды и продуктивной недели!

Больше пользы здесь 👉: @pro_system_analysis

PRO собеседование системных аналитиков

2024-11-25T21:40:58.467Z

Часть 02. Оценка резюме

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

Этапы собеседования системного аналитика

Этап 1. Предварительная оценка резюме

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

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

Этап 2. Оценка резюме

Фиксирую материал статьи по горячим следам. Передо мной прямо сейчас находятся 13 резюме. На всё про всё есть 15 минут, т.е. это примерно по 1 мин на резюме, т.к. через 15 мин начнётся он-лайн встречка по работе. За это время нужно сделать экспресс-оценку каждого резюме и сделать вывод о том, стоит ли переводить кандидата на следующий шаг.

Шаги оценки резюме

Шаг 2.1. Проверка читабельности

Читабельность и доступность резюме - это косвенно читабельность и доступность постановки на разработку. Как написал резюме, то скорее всего так и будешь оформлять доки на работе. Делается упор на структуру, наличие заголовков у разделов, нумерованные списки и т.п.

Из практики:

Безусловно, делается скидка на то, что при интеграции с HR-системой форматирование могло "поломаться", поэтому спасает GPT-модель, которую просишь "сделать красиво" и текст становится читабельным. Однако, если форматирование здесь не при чем, то это первая "засечка".

Рекомендации:

Оформлять резюме так, как если бы оформляли ТЗ. Все должно быть структурировано и доступно.

Шаг 2.2. Оценка возраста

Если возраст до 22, то уже есть еще одна "засечка", иначе идём дальше.

Из практики:

Есть внутренняя статистика, которая показывает, что кандидаты в возрасте до 22 лет не проходят техническое собеседование на должность системного аналитика (позиция, которая соответствует уровню middle).

Рекомендации:

Не накручивать и указывать реальный возраст. Я знаю ребят, которые в свои 22 года являются специалистами, которые уже имеют достаточный опыт и навыки, которым могут позавидовать специалисты 30+ и годами опыта в ИТ.

Шаг 2.3. Оценка общего стажа

Если общий стаж меньше 2 лет, то рассмотрение резюме на этом заканчивается.

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

Рекомендации:

Не накручивать и указывать реальный стаж. Есть правило 10 000 часов (чтобы стать профессионалом, считается, что заниматься делом нужно именно столько). И в случае с подбором специалиста уровня middle, можно их поделить на 3 (т.е. для этого уровня нужно поработать несколько (2+) лет), без этого никак. Безусловно, и здесь могут быть исключения из правил, но мы исходим из статистики.

Шаг 2.4. Сверка хронологии образования

Если выходит так, что период работы и период обучения пересекаются, то делаю еще одну "засечку".

Например, кандидату 21 год, дата окончания вуза 2025 год, но уже 3 года стажа работы СА - это еще один звонок о том, что к резюме нужно присмотреться внимательнее.

Из практики:

Направленность специальности по диплому не играет никакой роли. Всё решается на следующих шагах при анализе опыта и заявляемых навыков. Иногда само наличие высшего образования может быть не принято во внимание. Смотрим именно на даты.

Рекомендации:

Если была стажировка или должность "Младший системный аналитик" или "Аналитик-стажёр", или другая должность, которая соответствует уровню junior, то это объясняет наличие опыта лучше, чем "сухой" циферный стаж и неоконченное еще высшее образование.

Шаг 2.5. Анализ последнего места работы

На что обращаю внимание:

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

Категории оценки места работы

Из практики:

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

Рекомендации:

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

Указывайте только то, что потом сможете "защитить". Например, указан "опыт работы с Rabbit MQ", но на деле оказывается, что у человека есть только понимание того, как это работает, но сам он никогда ни в ТЗ про него ничего не писал, ни в настройки не заглядывал. Это не опыт.

Шаг 2.6. Анализ предыдущих мест работы

Здесь схема примерно такая же, как на предыдущем шаге. Разве что смотрится всё еще менее внимательно.

Из практики:

Опыт работы программистом более 2 лет является "плюсом". Периодически встречаю следующее развитие специалиста, из которого получаются отличные системные аналитики:

программист -> бизнес-аналитик -> системный аналитик

Шаг 2.7. Анализ продолжительности работы на каждом месте

Обращаю внимание на то, как долго задерживался на рабочем месте и как часто менял работодателей.

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

Рекомендации:

Если Вы попадаете под определение "джоб-хоппера", то указываете причину смены места работы.

На чём хочется заострить внимание:

Сначала просмотр одного резюме занимал сильно больше времени (до 10 мин), те самые "засечки" фиксировались и были обоснованием для перехода на следующий этап или отказа от дальнейшего рассмотрения;
Сейчас весь процесс анализа одного резюме происходит за 1-2 минуты, а итогом рассмотрения резюме является проставленный "+" или "-" в моей таблице;
Чем больше резюме отсматриваешь (чем выше насмотренность), тем быстрее принимается решение;
Безусловно есть риск неверно оценить и отказать перспективному кандидату, который просто некачественно оформил резюме или был неверно оценен (человеческий фактор никуда не делся, ошибки могут быть). Этот риск просто принимается и стараюсь нивелировать;
При наличии сомнений выбор делается в пользу "пропустить на следующий этап", что частично нивелирует упомянутый выше риск.

Главная рекомендация:

Всё самое важное должно присутствовать на первой странице вашего резюме и по объёму информации чтение должно занимать 1 минуту при беглом прочтении. После основной информации может быть любое количество приложений с перечнем пройденных курсов, пет-проектов, мест работы, достижений, хобби и пр. информацией, которую Вы считаете существенной, чтобы о ней рассказать.

Следующая часть уже опубликована по ссылке 👉: [часть 3]

Ссылка на вводную часть: [Часть 1]

Понравился материал? Ставь 👍

Всем хорошего 🍁 вторника и продуктивной недели!

Больше пользы здесь 👉: @pro_system_analysis

PRO собеседование системных аналитиков

2024-11-24T17:50:17.305Z

Часть 01. Введение

Больше четырёх лет назад я вышел на рынок труда в СПб. Я прошёл (точнее НЕ прошёл🙃) порядка 15 собеседований на должность "системный аналитик", которые были местами совершенно разные.

Тогда ещё все собеседования были очными и:

где-то решающим был вопрос про знание методологии "kanban";
где-то - навык решения квадратных уравнений;
где-то был нужен бизнес-аналитик;
и только местами всё было честно и искали того, кто займётся проектированием и формированием технических заданий для разработки.

Системный аналитик в 2020 году

Интересно, как обстоят дела сейчас?

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

Место системного анализа в ИТ-конвейере

Вторым процессом, после "производственного", который нужно было наладить в нашей компании, стал подбор системных аналитиков. И сначала собеседования у нас проводились силами архитекторов, и вопросы были в основном про архитектуру. После того, как системный анализ нашел своё место в ИТ-конвейере, когда появились границы ответственности и стало понятно, что является навыками, без которых никак, а какие из них можно освоить уже в процессе работы, изменился подход к собеседованиям.

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

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

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

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

То, с чего началось накидывание текста.

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

Итоговый процесс собеседования системных аналитиков

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

Следующая часть уже опубликована по ссылке 👉: [часть 2]

Понравился материал? Ставь 👍 Если есть замечания или запрос - напишите.

Всем хорошего 🍁 вторника и продуктивной недели!

Больше пользы здесь 👉: @pro_system_analysis

PRO шаблон описания REST-методов, который спасет от хаоса в API-документации📋

2024-11-10T16:30:12.207Z

Каждый системный аналитик, на мой взгляд, рано или поздно сталкивается с задачей формирования или доработки шаблона описания, в частности, rest-метода. В интернете можно найти примеры таких шаблонов, но большинство из них являются только начальным приближением.

Если сейчас внедряете у себя такой шаблон, то рекомендую основывать его на спецификации OpenAPI. И вот почему:

✅ Спецификация Swagger (OpenAPI) стал общепринятым для описания REST API, что делает его выбор логичным и практичным.

✅ Удобство для разработчиков и тестировщиков. Хорошо структурированное описание API в Confluence даёт возможность любому участнику команды, даже без глубоких знаний предметной области, быстро понять назначение и структуру метода.

✅ Возможность парсинга swagger в такой шаблон (об этом расскажу в следующих постах, подписывайтесь, чтобы не пропустить).

✅ Возможность использовать GPT-модели для генерации разных частей описания (об одном из таких примеров писал вот здесь https://t.me/pro_system_analysis/16).

Пример структуры шаблона

Как лучше всего организовать шаблон? 📑

1️⃣ Общая информация о методе

Описание метода – краткое пояснение, что делает этот метод.
URL и HTTP метод – указание на путь и тип запроса (GET, POST, PUT, DELETE и т.д.), иная информация, принятая для фиксирования в компании.

2️⃣ Параметры запроса

Указать в табличном виде для каждого входного параметра:

наименование,
тип параметра запроса (path, query и т.п.),
тип данных (boolean, string, object и т.п.),
ограничения (pattern, MaxIndex, MinLength и т.п.),
обязательность,
возможность принимать значение null
произвольный комментарий.

3️⃣ Параметры ответа

Указать в какой форме возвращается ответ;
Перечислить в табличном виде структуру ответа.

4️⃣ Примеры запроса и ответов

Пример запроса – привести пример реального запроса с параметрами и телом;
Примеры ответов – пример успешного ответа с примером структуры ответа и примеры негативных ответов с кодами 4хх/5хх (опционально).

5️⃣ Описание логики работы метода

порядок авторизации, в результате выполнения которого могут быть возвращены коды ответов 401 и 403,
валидации входных параметров (с учетом ограничений из раздела 2 и иные прочие проверки (например, условные), в результате которых может быть возвращён код ответа 400,
непосредственно саму логику работу метода: обращения к базам данных, выполнение вычислений, вызов методов других сервисов.

6️⃣ Диаграммы

блок-схемы,
sequence-диаграммы
другие принятые в компании графические артефакты.

В результате при обнаружении новых аспектов работы REST-методов, которые укладываются в спецификацию OpenAPI, которые не принимались во внимание на ранних стадиях документирования могут быть легко встроены в такой шаблон, например, учет Content-Type.

А что ты ещё бы добавил в такой шаблон? Какие элементы помогают твоей команде быстрее разобраться в API?

Поделись своим опытом в комментариях. 👇

Всем хорошего 🍁 понедельника и продуктивной недели!

Пойдёмте поработаем 👨🏻‍💻

made in: @pro_system_analysis