Как успешно пройти собеседование на должность системного аналитика в 2024-ом году

Привет, Хабр!

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

Процесс поиска начинается с общения с рекрутером. Какие же вопросы задать?

Вопросы рекрутеру

Перед тем, как вступать в долгую переписку уточните три основных момента:

  • предполагается ли у вакансии удаленный формат работы;

  • сколько этапов отбора;

  • какая вилка у вакансии.

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

Кстати, на вопрос о вилке рекрутеры часто отвечают что-то в духе: «Мы не можем сказать, какие у вас ожидания?» Пожалуйста, не юлите и прямо называйте ту сумму, которую вы хотите.

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

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

От компании к компании количество и продолжительность этапов интервью может отличаться, но чаще всего встречаются следующие:

  • Скрининг. Короткое знакомство с рекрутером и ответы на базовые вопросы. Этакая проверка на адекватность. Как правило не занимает более получаса.

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

  • Знакомство с командой/СТО. Формальная встреча, на которой редко спрашивают что-то техническое. Скорее как завершающий этап перед получением оффера.

  • Тестовое задание — только для джунов. Нет, предлагать его могут всем, но я не вижу смысла делать тестовое специалистам выше миддла. Спрос на аналитиков в РФ гигантский, скорее найдете компанию, где смогут проверить ваши скиллы без тестового (например, только на техе). Дают, как правило, после скрининга, но могут и после технического.

Отдельно хочу выделить скрининг. Подготовьте ответы на все банальные вопросы: почему решил сменить место работы? Какие сильные и слабые стороны? Кем видишь себя через пять лет (шучу, такое перестали спрашивать). Здесь очень важно правильно ответить на 2 вопроса: активно ли ищете работу и есть ли офферы на руках?

Работу вы ВСЕГДА ищите активно, и офферы ВСЕГДА есть.

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

Самопрезентация

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

Итак, чего же ожидает интервьюер, задавая вопрос: «Расскажите о своем опыте?» Как ни странно, короткий, наполненный рассказ о решаемых задачах и ваших сильных сторонах.

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

Что там было раньше мало кого интересует.

Сам я придерживаюсь следующей структуры:

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

  2. Рассказываю об одном-двух проектах – что делал? по какой методологии работал? размер команды? какие артефакты оставил после себя? какие инструменты использовал? В этом блоке подсвечиваю все ключевые слова из вакансии: работали по SCRUM, архитектура микросервисная, интеграция рестовая, в качестве асинхронного взаимодействия использовали брокер и т.д. Все, что интервьюер хочет услышать, он получает здесь.

  3. Отдельно выделяю какую-либо сложную задачу, которая выбивается из стандартной рутины. Рассказываю о ней как с точки зрения техники, так и с точки зрения влияния на бизнес.

  4. Полирую эту красоту дополнительными фишками, которые выделяют меня на фоне остальных. Например, говорю о том, что активно менторю и веду тг-канал. Заканчиваю всегда фразой: «Если остались вопросы, готов обсудить»

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

  1. Структура рассказа может совсем отсутствовать. Аналитик прыгает с темы на тему и теряет нить повествования. Как правило, такие кандидаты не пытаются ответить на вопрос, который видят впервые, а сразу говорят: «Я не знаю».

  2. Рассказ слишком затянутый. Такое встречается у аналитиков с большим опытом, а также людей 35+ Они расскажут вам, как учились в университете в 90х, как в нулевых работали на заводе, ближе к десятым дошли в IT, а потом время интервью выйдет…. Справедливости ради, если окажетесь в роли интервьюера и попадаете на такого кандидата, ставьте вопрос точнее: «Расскажите о последнем месте работы аналитиком?»

  3. Рассказ привязан к прошлому, специфичному опыту. Тут вроде слушаешь, и ТЗ они писали, и ФТ согласовывали и тендеры выигрывали и что только не делали. На деле, кандидат выполнял роль человека-оркестра где-нибудь в государственной компании, и с трудом представляет, как организована современная разработка.

Секция бизнес анализа

Вы складно рассказали о своем опыте, произвели первое положительное впечатление, теперь настало время проверить харды. Вообще интервью делится на 2 типа: компания может спрашивать общую информацию по бизнес/системной аналитике (топ-100 вопросов на СА) или же задавать специфические вопросы по стеку, который используют. И если первый тип мы сегодня разберем, то ко второму подготовиться проблематично, потому что все, что у вас есть – это вакансия. Вы и без меня знаете, что ожидание и реальность сходятся достаточно редко.

В блоке по бизнес анализу спрашивают классические вещи из «Разработки требований к программному обеспечению». От роли БА/СА на проектах и видов требований до документирования и моделирования. В последнее время на вопросы по бизнес-анализу выделяют не так много времени, зато активно спрашивают по системному, а конкретно интеграциям. Структурно блок БА делится на следующие части:

  1. Общие вопросы о роли БА/СА

  2. Жизненный цикл проекта и гибкие методологии

  3. Работа с требованиями

  4. Работа с документацией

  5. Моделирование

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

Общие вопросы

Здесь спрашивают о том, чем вообще занимается бизнес/системный аналитик. Какого его роль и ценность в команде? Какие задачи он решает? В чем разница между бизнес и системным аналитиком? А может быть можно обойтись вообще без аналитика? Какие артефакты являются результатом работы аналитика? Какие инструменты он использует?

Жизненный цикл проекта и гибкие методологии

По жизненному циклу не так много вопросов, тут скорее важно понимать, какие этапы ЖЦ существуют и что на них делает аналитик. А вот по гибким методологиям спрашивают хорошо. Что такое SCRUM и Kanban? В чем разница между этими подходами? Какие роли и церемонии есть в SCRUM? Назови манифесты Agile. Исключительно теоретические знания, которые не применяются в работе, но почему-то спрашивают.

Работа с требованиями

Спрашивают вообще все что касается требований. Привести классификации требований. Какие методики сбора требований существуют? Какие применить в той или иной ситуации?  Как управлять требованиями? Как валидировать и верифицировать их?

Работа с документацией

Все что касается документирования и фиксации требований, как традиционные виды (ТЗ), так и гибкие (Use Case/User Stories). Какие разделы бы включили в ТЗ и почему? Как составили бы интеграционную спецификацию? Знакомы ли с ГОСТ 34? Что такое Use Case и User Stories, приведите примеры?

Моделирование

Спрашивают знание основных нотаций. Что такое BPMN и какие элементы есть? Какими диаграммами UML пользуешься? Плюс конкретные вопросы по отдельным UML диаграммам, в духе – Какие виды связей на диаграмме классов можешь назвать?

Резюмируя, в бизнес-анализе очень помогают развитые софты и умение «болтать». Все, что касается работы аналитика и требований – вопросы дискуссионные, на которые можно распыляться долго. Да, конечно, всегда есть правила и рекомендации, но никто не запрещает сказать: «А у нас в компании было вот так» и придумывать, придумывать, придумывать.

Секция системного анализа

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

  1. Архитектура ПО

  2. Веб-сервисы

  3. Базы данных

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

Архитектура ПО

Какие виды архитектуры ПО бывают? Какая разница между монолитами и микросервисами? Какие плюсы и минусы монолитов и микросервисов? Паттерны реализации микросервисной архитектуры?

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

Веб-сервисы

За этой темой кроятся вопросы, затрагивающие интеграцию. Причем от верхнеуровневых, до конкретных. Какие виды интеграции можешь назвать? В чем разница между синхронной и асинхронной интеграциями? Что такое REST и SOAP? В чем разница между ними? Что такое ESB? В чем разница между брокером и ESB? Какие способы аутентификации можешь назвать?

На самом деле, тут копать и копать, можно выдергивать отдельную технологию и рассуждать о ней. Но наиболее часто и глубоко спрашивают про REST. Что такое RESTful принципы? Какие методы HTTP можешь назвать? Какие методы идемпотентны? Какие коды ответов знаешь?

Из интересного, меня однажды спросили: «Почему для реализации чата используется WebSocket, а не gRPC?»

Базы данных

Классика, которую спрашивают, как у бизнес, так и у системных аналитиков. Чаще всего просят решить простенькую задачу на SQL, с использованием JOIN, и агрегатных функций. Если говорить о теории, то я бы выделил следующие вопросы: В чем разница между SQL и noSQL базами данных? Что такое нормализация? Что такое транзакция? Какие способы масштабирования БД можешь назвать?

Практическая секция

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

Задача на SQL

Наиболее популярное задание, проверяющее соответствующий скилл. Чаще всего аналитика просят написать SELECT с использованием JOIN из одной или нескольких таблиц, применив агрегатные функции и группировку.

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

Моделирование предметной области

Здесь чаще всего аналитика просят спроектировать какую-либо диаграмму, показав процесс или предметную область. Мне доставался и BPMN, и Sequence, и ER. В зависимости от уровня вакансии компания может вообще не привязываться к какой-либо нотации, а просто проверить системное мышление кандидата.

Пример задачи на собеседовании звучит как: Спроектируй логическую модель данных для интернет-магазина по продаже книг. Или другой пример: Спроектируй Sequence диаграмму для процесса оплаты в банковском приложении.

Задача на работу с API

Здесь открывается пространство для творчества. Самая простая задача, найти ошибки в JSON или XML.

Вопрос поинтереснее может звучать так: Спроектируй endpoint для интернет-магазина по продаже книг.

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

Вопросы после технического интервью

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

«Чем мне предстоит заниматься ежедневно? Что входит в мои обязанности? Расскажи примерный день системного аналитика»

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

Ответ в духе: «Ну, у нас вообще-то не было никогда системного аналитика, и мы его берем, потому что это круто и модно» — плохой.

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

«Каким образом выстроены рабочие процессы? По какой методологии работаете?»

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

Если вам ответят: «Каждая задача уникальна и требует тщательного обсуждения со всей командой», знайте, в таком месте лучше не работать.

«Есть ли план развития сотрудников? И план развития компании в целом?»

Вопрос нужен, чтобы с порога понимать, будет ли возможность прокачивать экспертизу и развиваться. Работодатель может не иметь внутреннего портала с курсами, но компенсировать внешнее обучение. Спрашивая подобное, с большой долей вероятности вам дополнительно расскажут о процессе пересмотра зп. Плохой же ответ звучит как: «У нас настолько интересные задачи, что сотрудники развиваются, просто решая их». Читай его как: «Через 3 месяца тебе станет скучно, но мы ничего с этим не сделаем».

Также стоит спросить вопросы, которые волнуют вас по прошлому опыту. Например, переработки, KPI и прочее. Узнавайте обо всем, что доставляло неудобства ранее, дабы не нарваться на те же грабли. Например, на прошлом месте работы премиальная часть моей зп (аналитика) зависела от SLA тикетов поддержки. Естественно, я первую очередь решал запросы пользователей, а не занимался тем, что мне действительно нравится.

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

И еще полезные советы

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

Собеседования и реальная работа практически не имеют ничего общего

Большинство интервью проверяют теоретические знания, а практика отходит на второй план. Работа, в большинстве своей, предполагает решение конкретных, узких задач. Вы можете на автомате клепать синхронные интеграции по имеющейся документации, укладывая их в стандартные процессы. Но это не поможет, если на собеседовании вас спросят об аутентификации, асинхроне, нереляционных БД и тому подобное. Можно быть мощным практиком, но без базы и понимания, почему мы делаем так, а не иначе, собес не пройти. Из этого вытекает второй совет…

К собеседованиям нужно всегда готовиться

Теория спокойно улетучивается, когда не пользуешься ей постоянно. Время, потраченное на подготовку, конвертируется в лучший оффер. Будет очень досадно, если вы мастер юз кейсов, но забыли повторить виды требований по BABOK. Глобально это не поставит на вас крест, но точно даст работодателю повод предложить меньше денег. И даже со структурированной информацией в голове, опыт важно правильно подать. Поэтому стоит…

Научиться продавать себя как высококвалифицированного специалиста

На собеседовании обе стороны немного лукавят: компания может умолчать об устаревшем стеке или объеме техдолга, но и вы не должны говорить все как есть. Например, SQL вы используете раз в месяц, чтобы проверить наличие данных в базе. На вопрос работодателя: «Владеете ли вы SQL?» справедливо ответить: «Да, владею, использую в работе, строю отчеты». И тут два варианта событий: вам либо предложат решить задачу, которую вы осилите (ведь вы же готовились и повторили синткасис), либо ответят: «Ну, окэй» и пойдут дальше. Всегда подавайте себя чуточку лучше, чем вы есть на самом деле, если возникнут сомнения – вас тут же проверят. Не нужно закапывать самого себя. И наконец последний совет…

Всегда торгуйтесь за оффер

Получив долгожданное предложение о работе очень просто сказать: «Да, я на все согласен». Но подождите, есть вероятность, что работодатель сможет дать еще больше. Не бойтесь торговаться. Наиболее простой способ написать что-то в духе: «Спасибо за предложение, вы мне очень понравились, но у меня есть другое предложение, и я не могу выбрать, где мне будет лучше. Есть ли возможность улучшить условия?» Оффер не отзовут и на вас не посмотрят криво. В худшем случае скажут: «Извините, мы не можем изменить условия». Тогда просто примите как есть, и останетесь при своем.

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

Хочется еще больше полезного материала по системному анализу? Я веду тг-канал (Не)Системная аналитика, где рассказываю о софтах и хардах. Жду всех!

 

Источник

Читайте также