Случилось так, что я собешу кандидатов на специфичную роль - технического лидера команды разработки.
Объем компетенций, который необходим для тех. лида максимально большой:
Проверить за полтора часа весь объем практически не реально. По этому, решил свести собес не к списку вопросов, а к решению абстрактной задачи.
Для меня основные точки проверки на собесе - это, конечно проверка навыков, но, прежде всего, способность критически мыслить и обладание инженерным взглядом на процессы, компетенции, технологии.
Сегодня не буду про то, что такое тех. лид, зачем он нужен. Сегодня будет про задачку.
Задача.
Крупный международный производитель бытовой техники решил разработать систему "Умный дом" - систему автоматизации для дома: дистанционное открытие дверей, включение света, бытовых приборов. Туда же входит история с управлением климатом, системы безопасности и все. что может управляется в доме дистанционно.
Целевая аудитория:
Частные домовладения, семьи среднего класса. Количество клиентов измеряется сотнями тысяч по всему миру.
Формат продукта.
- Система должна продаваться "под ключ", но продаваться отдельными модулями. При этом, каналы продаж компонентов могут быть разными: интернет-магазин, ретейлинговые сети, партнерские интернет и офф-лайн магазины.
- Компоненты системы должны управляться через интернет, предполагается, что возможно подключение компонентов через Wi-Fi.
- Система должна поддерживать условно неограниченное количество компонентов подключенных в одном домовладении.
- Система должна иметь возможность управления через мобильное приложение, WEB-кабинет пользователей системы.
- Компоненты имеют возможность запрограммированного пользователем поведения.
Дополнительный контекст:
- Сторонние производители так же должны иметь возможность подключать свои компоненты к системе.
- Предполагается сбор телеметрии - метрик функционирования компонентов.
- Возможен сбор более широкой статистики от пользователей давших на это согласие.
- Компоненты и их программно-аппаратная архитектура так же разрабатывается данной корпорацией добра.
Задач у меня много разных, стараюсь их не выдумывать на собесе, а готовить их заранее.
Процесс разбора задачи.
Прежде всего прошу кандидата пошарить экран и выбрать какой-либо инструмент для рисования блок-схем. Подходит любая нотация, box&arrows даже предпочтительнее за свою скорость. Единственное, что прошу не использовать - plantUML из-за относительно низкой скорости.
Первое, что должен сделать кандидат - задать уточняющие вопросы, задача составлена, хотя и просто. но с подводными камнями.
Второе и, наверное самое главное и сложное - найти точку начала решения задачи - самый проблемный или критический участок. с точки зрения продукта. В данной задаче их несколько, например: необходимо обеспечить кратчайшее время отклика на управляющие команды от пользователя в компонентах системы. На проблемы с временем отклика указывает количество пользователей, компонентов в системе и их критичность. В этой задаче несколько примерно значимых проблемных участков.
Третье. Выделение контекста, разделение системы на домены. Ну как бы DDD и вообще предметно-ориентированное программирование. Если человек не выделяет контекст - это не шоустопер, можно руководствоваться и своим опытом, не зная нюансов DDD, но в карму это однозначно минус.
Четвертое. Архитектура и выбор технологий. Самый объемный блок. Ну тут все очевидно, хотелось бы увидеть концептуальную архитектуру. Тут же говорим о интеграционных паттернах или о просто общих понятиях, eventually consistency и так далее. Тут же можно поговорить о особенностях развития API для клиентских приложений, обновлении структуры баз и всякое разное, к чему располагает нас эта задача.
Пятое. Выделение агрегатов или просто рассуждение о структурах данных. Оно может быть и не пятое. все зависит от того, выделен ли контекст, как спроектирована система. На этом этапе проверяем, скорее опыт кандидата. чем умение структурно работать с агрегатами. В конве этой задаче, полезно обсудить процесс регистрации компонентов, структуру аккаунтов и так далее.
Шестое. Деление на команды. Как бы, то что у нас нарисовано мы бы разбили на команды и как бы эти команды между собой взаимодействовали? Как бы строились процессы в командах и какая документация нам была бы в этих процессах нужна? Если успеваем по таймингу - какие роли или компетенции в нашей дружной конторе нам были бы нужны.
Седьмое. CI и релизный цикл. Мы понимаем. что система большая, что компонентов у нее много, как должен быть построен CI, как будут организованы репы, какой правильный флоу для гита выбрать? Нужен ли нам SAST и когда пригодится DAST? Есть ли понимание о quality gate'ах какими они должны быть.
Восьмое. Сервисные процессы. Что нужно, в нашей архитектуре тестировать и как? А если ресурсы у нас ограниченны? Как была бы построена поддержка, какие проблемы у поддержки могут возникнуть, за счет чего их можно нивелировать? Как и что мониторить, какие метрики для нас могут быть важны, как их собирать?
Что еще? Конечно, где-то между пунктами будет разговор про инфраструктуру, как будем геокластер мутить, какие у нас варианты для этого? Будет разговор про выбор и особенности баз данных, особенности распределенных транзакций, саги (прости господи) и всякое такое.
Обычно, собеседование укладывается в полтора часа. Может показаться. что вопросов сильно много, но я стараюсь помогать кандидату и если вижу правильное направление мыслей, переключаться на следующую тему.
Так же, очень хочу, чтобы кандидат получал удовольствие от собеседования, хотя бы такое же, которое получаю я)) По этому. стараюсь помогать . направлять кандидата, не допускать моментов, когда кандидат чувствует себя ниже меня по уровню.
Что меня триггерит ?
- Если человек на раннем этапе переходит к технологиям. Решать задачу, которую, очевидно. ты понимаешь не до конца - не признак высокого профессионализма.
- Оперирование собственным опытом. а не попытки найти релевантное решение. ну данный кейс очень просто описать фразой "я всегда так делал и было норм".
- Cover your assets - защита своего решения, когда оно очевидно не правильное. Раньше думал, что этот антипаттерн встречается только на длинной дистанции, а нет, есть ленивые жопы, которые даже на дистанции полутора часов ленятся переоценивать свои решения, относительно вскрывшихся вводных.
- Непоследовательность мышления. Бывает, что от стресса на собесе человек начинает прыгать между кусками задачи, стараюсь успокоить человека и вывести его на последовательное решение. Но бывает так, что это не стресс, а обусловленное недостатком опыта, образом мышления и фазой луны, человек не способен структурированно подойти к задаче.
- Необоснованное пренебрежение знаниями. На собеседовании, стараюсь создать атмосферу партнерства - выполняем задачу вместе. И если я, в силу опыта, указываю на необоснованность решения, очень значимо для меня, как к этим замечаниям относится кандидат. Бывают разные варианты: кандидат может начать искать новое решение, приняв замечания, он может настоять на своем решении с мотивацией недостаточности знаний и это тоже норм. Но бывают и те. кто игнорируют новые знания. И в этом тоже нечего плохого нет, но это опять же, минус в карму.
На этом, наверное и остановлюсь, до Александра Поломодова с его собеседованиями мне далеко. Надеюсь, что подобный формат задач может оказаться кому-то интересным и если есть желание почеленджить себя и меня - стучитесь, поучимся вместе.
Но ссылку на прекрасного Антона, я все же оставлю:
