1. «У нас упала БД, бэкапов нет или они битые. Твои действия в первые 30 минут?»
- Зачем спрашивать: Проверка на стрессоустойчивость и понимание процессов Disaster Recovery.
- Плохой ответ: Паника или абстрактные рассуждения о том, что «бэкапы должны быть всегда».
- Хороший ответ: Архитектор начнет с изоляции инцидента и оценки масштаба бедствия. Он предложит варианты частичного восстановления (из логов транзакций, из кэша, из очередей сообщений) и сразу перейдет к плану коммуникации с бизнесом, чтобы минимизировать репутационный ущерб.
2. «Бизнес требует внедрить фичу «вчера», но это создаст огромный техдолг. Как будешь договариваться?»
- Зачем спрашивать: Проверка Soft Skills и умения балансировать между интересами компании и качеством кода.
- Плохой ответ: «Я просто запрещу это делать» или «Я сделаю, как просят, я же исполнитель».
- Хороший ответ: Профессионал предложит Trade-off (компромисс). Например: «Мы делаем «костыль» сейчас, чтобы успеть к релизу, но фиксируем это в бэклоге как техдолг с конкретным сроком рефакторинга в следующем спринте». Он объяснит бизнесу риски в цифрах (деньги/время), а не в эмоциях.
3. «Нарисуй схему взаимодействия сервисов, если один из них начинает «тормозить», но не падает совсем»
- Зачем спрашивать: Проверка знаний паттернов устойчивости (Resilience patterns).
- Плохой ответ: «Ну, будем ждать ответа от него» или «Перезагрузим его».
- Хороший ответ: Кандидат сразу нарисует Circuit Breaker (предохранитель), упомянет Timeouts, Retries с экспоненциальной задержкой и, возможно, Bulkhead для изоляции ресурсов. Он понимает, что «медленный» сервис опаснее «мертвого», так как он выедает потоки и память у всей системы.
Резюме для интервьюера:
Если на эти вопросы ты слышишь невнятное мычание про «надо почитать документацию» — перед тобой теоретик. Архитектор — это человек, который уже «горел» на продакшене и знает цену каждой ошибки.
Связаться со мной:
Telegram: @Windrun