Найм Solutions Architect: на что смотреть и как оценивать кандидатов

Нанять Solutions Architect сложнее, чем кажется. На собеседовании кандидат может уверенно говорить о микросервисах, облачной инфраструктуре и масштабировании. Но главный вопрос звучит иначе: сможет ли он выбрать решение, которое действительно подходит вашему бизнесу, бюджету и команде?

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

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

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

Самая дорогая ошибка в таком найме случается ещё до первого собеседования: название вакансии тянет на себе больше, чем её описание. «Solutions Architect» используют широко, и в итоге компания собеседует на роль, о которой внутри никто толком не договорился. Один руководитель представляет технического лидера, который работает руками. Другой — человека, который общается с клиентами и помогает закрывать сделки. А кандидаты приходят не те и не другие.

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

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

РольОсновной фокусТипичный охватКого брать, если нужно…
Solutions ArchitectТехническое решение конкретной бизнес-задачи от и доОдин проект или инициативаСвязать потребности бизнеса с тем, что реально можно построить
Enterprise Architect (корпоративный архитектор)Технологическая стратегия и стандарты в масштабе всей компанииВся компанияДолгосрочно согласовать технологии между множеством команд и систем
Software / Application Architect (архитектор ПО)Глубокое внутреннее устройство одного приложенияОдна кодовая база или продуктСтрогая архитектура одного сложного приложения
Cloud Architect (облачный архитектор)Облачная инфраструктура, миграции и стоимостьУровень инфраструктурыЭкспертиза именно в AWS, Azure или GCP
Pre-sales Solutions Architect (пресейл-архитектор)Проектирование решений для клиента на этапе продажиСделки и потенциальные клиентыТехническая экспертиза, которая помогает выигрывать сделки

Чтобы быстро определить нужный профиль, ответьте на один вопрос: этот специалист должен помогать команде проектировать и реализовывать продукт или разрабатывать технические решения для продажи клиентам? Работа — это в основном разработка с нуля или распутывание того, что уже есть? Он живёт внутри одного продукта или соединяет много систем между собой? От ответов зависит и нужный уровень, и то, как вы будете оценивать кандидата. Если вам на самом деле нужна технологическая стратегия в масштабе всей организации, вам, скорее, требуется корпоративный архитектор и фреймворк вроде TOGAF; если нужно, чтобы один сложный продукт вёл человек от и до, — это ближе к архитектору ПО. Путаница между ними — одна из самых частых и дорогих ошибок найма.

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

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

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

Умение работать с облачными сервисами. Современная архитектура почти всегда использую облачные сервисы AWS, Azure или GCP, поэтому практическое знакомство хотя бы с одним крупным облаком — почти обязательное условие. Сертификат вроде AWS Certified Solutions Architect — полезный показатель, что человек хорош в теории, но это не доказательство практики. Немало сертифицированных кандидатов ни разу не выкатывали систему в прод, и немало сильных архитекторов не обновляют сертификаты. Проверяйте сам навык напрямую.

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

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

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

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

Привычка учиться. Технологическая база меняется без остановки — достаточно заглянуть на Habr, чтобы увидеть, как быстро сменяются инструменты и подходы. Лучшие архитекторы — это непрерывно учащиеся люди, которые держат знания свежими, в идеале с релевантным доменным опытом (финтех, здравоохранение, e-commerce), который сокращает время на ориентирование в задаче.

Как оценивать Solutions Architect: рабочий фреймворк

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

1. Оценивайте опыт, а не активность. Смотрите не на список технологий в резюме. Вам нужны доказательства, что человек вёл решения от и до и доводил их до результата на реальном масштабе. Какие бизнес-задачи он решал? Что именно спроектировал и что произошло, когда это вышло в прод? «Участвовал» во многих системах — совсем не то же самое, что «спроектировал» несколько и довёл их до продакшена.

2. Проведите интервью по проектированию систем. Дайте открытую, приближенную к жизни задачу — «спроектируйте систему для X» — в идеале близкую к тому, с чем реально сталкивается ваша компания. А дальше наблюдайте за ходом мысли: процесс говорит больше, чем итоговое решение. Сильные кандидаты сначала уточняют требования и ограничения и только потом что-то предлагают. Они структурируют задачу, набрасывают ключевые компоненты и вслух рассуждают о компромиссах, масштабе, данных, безопасности, точках отказа и стоимости. Давайте выбор: «А что будет, если трафик вырастет в десять раз?» Вы проверяете рассуждение над вариантами, а не заученный «правильный ответ».

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

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

5. Разберите поведение и реальный опыт. Используйте структурированные вопросы по методу STAR: об архитектурах, которыми человек гордится, о решениях, которые оказались неверными, и о моментах, когда стейкхолдер шёл против. То, как человек рассказывает о провалах, особенно показательно: зрелые архитекторы спокойно говорят о компромиссах, которые не сыграли, а слабые описывают каждое прошлое решение как безупречное.

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

Стартовый набор вопросов для собеседования Solutions Architect

Подгоните их под свой стек, но эта подборка стабильно отделяет сильных кандидатов от «хорошо подготовленных»:

  • Проведите меня по системе, которую вы спроектировали от и до. В чём была бизнес-задача и какие решения были ключевыми?
  • Спроектируйте систему для [задача, близкая вашему бизнесу]. Рассуждайте вслух по ходу.
  • Расскажите об архитектурном решении, в котором вы ошиблись. Что произошло и что бы вы сделали иначе?
  • Как вы выбираете между «сделать самим» и «купить готовое»?
  • Опишите случай, когда вы убедили команду принять дизайн, против которого она поначалу возражала.
  • Как стоимость влияет на ваши архитектурные решения? Приведите конкретный пример.
  • Стейкхолдер хочет фичу, которая серьёзно подорвёт масштабируемость. Как вы построите этот разговор?
  • Как вы держите свои технические знания в актуальном состоянии?

Красные флаги

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

  • Начинает искать решение, не разобравшись в задаче.
  • Защищает один «правильный» ответ вместо разговора о компромиссах.
  • Не умеет упрощать: если нетехнический слушатель теряет нить, работа со стейкхолдерами будет вечной борьбой.
  • Они чрезмерно усложняют, стремясь к максимальной сложности, когда проблема требует чего-то более простого.
  • Модные словечки без содержания, которые растворяются под парой уточняющих вопросов.
  • Не умеет сказать «не знаю»: блеф в архитекторе опаснее, чем честное признание пробела и попытка дойти до ответа рассуждением.

Частые ошибки найма

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

Частые вопросы

Чем занимается Solutions Architect?

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

Чем Solutions Architect отличается от Software Architect?

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

Какая квалификация нужна Solutions Architect?

Ищите сильный список проектирования и запуска систем на масштабе, широкие технические знания и реальный облачный опыт. Сертификаты вроде Microsoft Certified: Azure Solutions Architect Expert уведомляют о формальных знаниях, но практический опыт проектирования значит куда больше, чем любой сертификат сам по себе.

Должен ли Solutions Architect уметь программировать?

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

Сколько стоит нанять Solutions Architect?

Вознаграждение сильно зависит от региона, уровня и индустрии, и рынок движется быстро. Надёжнее всего сверяться со свежими локальными данными — наше исследование зарплат в ИТ — хорошая отправная точка, прежде чем закладывать бюджет или делать оффер.

Какие красные флаги главные на собеседовании Solutions Architect?

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

Как лучше всего оценивать Solutions Architect?

Используйте структурированный многоэтапный процесс: интервью по проектированию систем, реалистичный кейс или тестовое, оценку коммуникации на смешанной аудитории и поведенческие вопросы — и всё это по единой шкале. Облачные сертификаты вроде Google Cloud Professional Cloud Architect могут дополнить оценку, но никогда не заменят наблюдения за тем, как кандидат рассуждает над реальным дизайном.

Коротко о главном

Удачный нацм Solutions Architect сводится к трём шагам: определите, какой именно вариант роли вам нужен; проверяйте широту и умение переводить с бизнесового на технический, а не просто глубину в коде; и оценивайте кандидатов через структурированный процесс, который проверяет архитектурное мышление, коммуникацию и реальный опыт по единой шкале. Сделайте так — и вы заметно повысите шансы взять человека, с которым проекты идут быстрее, системы становятся надёжнее, а проект — предсказуемее.

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

Готовы к следующему найму? Свяжитесь с нами — и получите достоверные данные.