Как нанять техлида и архитектора решений: оценка архитектурных навыков

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

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

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

Сначала определитесь, кого именно вы ищете

«Техлид», «архитектор ПО» и «архитектор решений» часто используют как синонимы. Это разные роли, и многие неудачные наймы начинаются с вакансии, в которой смешаны все три. А если на самом деле вам нужен человек, который возглавит всю разработку, то это руководитель разработки или CTO, и такой поиск ближе к подбору топ-менеджеров, чем к найму архитектора.

РольГлавный фокусТипичный масштабРезультат работы
ТехлидПоставка и качество кодаОдна командаРаботающий продукт, код-ревью, технические решения внутри команды
Архитектор ПОВнутреннее устройство системНесколько команд или платформаАрхитектура сервисов, стандарты, технический роадмап
Архитектор решенийСоответствие технологий задачам бизнесаПроект, продукт или решение для клиентаАрхитектура решений, интеграции, оценки, анализ компромиссов

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

Что вы на самом деле ищете

Архитектура — это о важных вещах, какими бы они ни были. С этой мыслью удобно подходить и к собеседованиям. Вам нужно понять, умеет ли кандидат увидеть, что важно в конкретной ситуации, и что он с этим делает.

Он мыслит компромиссами. У любого архитектурного решения есть цена. Спросите, почему на прошлом проекте выбрали PostgreSQL, а не MongoDB, и сильный кандидат расскажет, чем пришлось пожертвовать и выбрал бы он то же самое сегодня. Если в его рассказе каждое решение звучит как единственно верное, стоит насторожиться.

Ему важно, как система ведёт себя, а не только что она делает. Продукт редко падает из-за фич. Его роняют нагрузка, сбои, дыры в безопасности и счёт за облако, которого никто не ждал. Опытные архитекторы поднимают эти темы сами. Если нужен чек-лист, с которым можно сверять ответы, подойдёт Azure Well-Architected Framework, даже если вы не работаете с Azure: надёжность, оптимизация затрат, операционная эффективность, производительность и безопасность.

Он документирует решения. Архитектура, которая существует только в голове одного человека, уходит вместе с ним. Спросите, как кандидат фиксирует решения и как выглядят его схемы.

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

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

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

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

Отбор до собеседований

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

Список из 40 технологий вдохновляет меньше, как и формулировка «участвовал в принятии архитектурных решений» без единого решения, которое человек принял сам. Стоит присмотреться и к карьере, состоящей только из новых проектов: три года сопровождения системы учат больше, чем её запуск.

На первом звонке хорошо работают два вопроса:

  • «Какое архитектурное решение вы сегодня приняли бы иначе?»
  • «Сколько стоила эксплуатация вашей последней системы и откуда вы это знаете?»

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

Задания на собеседовании, которые работают

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

Разбор системы, которую строил кандидат

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

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

Кейс из вашей предметной области

«Спроектируйте Twitter» в основном проверяет, читал ли кандидат те же статьи, что и все. Лучше возьмите упрощённую версию реальной задачи вашей компании с реальными ограничениями: фиксированный бюджет, пять инженеров, легаси-система, которая проживёт ещё год, и дата запуска. И внимательно следите за первыми десятью минутами. Сильные кандидаты тратят их на вопросы, а не на рисование.

Смена условий на ходу

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

Критика проектного документа

Дайте кандидату короткий проектный документ с несколькими заложенными ошибками и попросите дать обратную связь. Так видно, как он замечает риски и как формулирует критику, а это очень важно для того, кто будет ревьюить чужую работу. Для такого документа удобен формат ADR (Architecture Decision Record): контекст и проблема, рассмотренные варианты, принятое решение и последствия.

Разговор с бизнесом

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

Для техлидов: код-ревью

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

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

Используйте оценочную таблицу

Без согласованных критериев обсуждение после собеседований превращается в «мне она понравилась» против «он показался больше теоретиком». Короткая оценочная таблица помогает сохранить объективность.

КритерийСлабоСильно
ТребованияСразу начинает проектироватьСначала спрашивает о пользователях, нагрузке, ограничениях и приоритетах
КомпромиссыПодаёт один вариант как очевидно верныйСравнивает варианты и объясняет, чем пришлось пожертвовать
Нефункциональные требованияВспоминает о них, только когда спросятСам поднимает вопросы надёжности, безопасности и стоимости
КоммуникацияГоворит на жаргонеПодстраивает объяснение под собеседника
ПрагматизмПо умолчанию выбирает модные технологииСоотносит сложность решения с реальной задачей
ЛидерствоГоворит только о своей работеПоказывает, как влиял на других и помогал им расти
Знание предметной областиНет релевантного опытаПонимает бизнес-задачи вашей отрасли

Оценивайте каждую строку от 1 до 4. Главное — момент: каждый интервьюер заполняет таблицу сам, до общего обсуждения, а не во время него. Иначе обычно побеждает самый уверенный голос в комнате.

Тревожные сигналы

Некоторые сценарии встречаются так часто, что за ними стоит следить. Кандидат называет Kafka или Kubernetes раньше, чем спрашивает, для чего нужна система. Не может вспомнить ни одного решения, о котором жалеет. Предлагает микросервисы, event sourcing и service mesh для команды из трёх человек. Во всех прошлых неудачах виноваты другие. Или просто не может объяснить свою схему простыми словами.

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

Найм техлидов и архитекторов в Беларуси

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

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

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

Иностранные компании без юрлица в Беларуси могут нанимать через Employer of Record. Наши услуги payroll и EOR включают оформление договоров, начисление зарплаты и соблюдение местного законодательства через нашу собственную компанию — резидента ПВТ. Поэтому ваш архитектор будет оформлен на тех же условиях, что и многие его коллеги.

Первые 90 дней

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

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

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

Часто задаваемые вопросы

Чем техлид отличается от архитектора решений?

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

Сколько этапов собеседования нужно, чтобы нанять архитектора?

Обычно хватает трёх-четырёх: скрининг-звонок, разбор прошлой системы, кейс на проектирование и встреча с заказчиками или руководством. Дополнительные этапы редко дают новую информацию.

Должен ли архитектор решений писать код?

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

Достаточно ли собеседования по system design, чтобы оценить архитектора?

Нет. Стандартный вопрос по system design показывает, как человек подходит к задаче у доски. Но не показывает, как он принимает решения на протяжении месяцев и объясняет их другим. Дополните его разбором реальной системы и разговором с бизнесом.

Сколько времени занимает поиск архитектора решений в Беларуси?

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

Нужны ли архитектору облачные сертификаты?

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

Чем поможет recruitment.by

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

Ищете техлида или архитектора решений? Пришлите нам вакансию, и мы вернёмся с планом формирования шорт-листа.