PRO собеседование системных аналитиков
Часть 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. Дополнительные (необязательные разделы)
Здесь мы коротко пробегаемся по дополнительным компетенциям:
В разных компаниях есть разные необязательные требования, которые чаще всего располагаются в разделе "Будет плюсом" вакансии. Изучите и эти требования тоже.
Шаг 4.6. Вопросы от кандидата
Чтобы дойти до этого этапа, необходимо внимательно следить за таймингом и сделать так, чтобы у нас осталось 10 минут на ответы на вопросы кандидата.
Крайне редко у кандидатов есть вопросы, которые не укладываются в 10 минут, хотя мы готовы обсудить любые вопросы, связанные с процессами адаптации, производства, развития и т.п.
Поэтому в наших собеседованиях отсутствуют:
- Вопрос "Расскажи о себе";
- Нет никаких логических задачек и заданий на внимание;
- Минимум теоретических вопросов, значение которых само по себе не гарантирует наличие навыков;
- Задача ставится таким образом, чтобы при наличии практических навыков на каждый из этапов уходило 10-15 минут.
Мы всегда просим кандидата предоставить пример своего "лучшего технического задания". Очень часто возможности предоставить что-то с текущего места работы нет из-за NDA, поэтому у нас был этап проектирования, когда есть возможность задокументировать и составить ТЗ на решение, которое только что обсудили.
Из практики:
Как тебе материал? Понравился? Ставь 👍
Всем отличной 🍁 среды и продуктивной недели!
Больше пользы здесь 👉: @pro_system_analysis