Вопросы на собеседовании AWS

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

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

Повторяются три типа раундов: раунд по основам — сети, идентификация, хранилища и вычисления; ситуационный раунд или раунд проектирования, где вы строите архитектуру с учётом ограничений; и раунд по устранению неполадок, где вам дают симптом и спрашивают, что бы вы проверили. С ростом уровня требования к глубине растут, но форма остаётся прежней. Банки вопросов по другим ролям и темам — на хабе вопросов для собеседований.

Вот базовые вопросы, которые повторяются на собеседованиях по AWS, сгруппированные так, как обычно строятся раунды.

Сети и VPC

• Что такое VPC и чем публичные подсети отличаются от приватных?
• Когда нужен NAT-шлюз и во что он обходится?
• Чем группы безопасности отличаются от сетевых ACL?
• Как бы вы соединили два VPC и когда пиринг — неверный выбор?

Идентификация и безопасность

• Объясните роли, политики и пользователей IAM и когда что использовать.
• Как инстанс EC2 получает учётные данные без хранения ключа?
• Как принцип минимальных привилегий выглядит в реальной политике?
• Как вы ротируете и аудируете секреты в AWS?

Хранилища и базы данных

• Сравните классы хранения S3 и объясните, когда использовать каждый.
• В чём разница между EBS и instance store?
• Когда вы выбираете DynamoDB вместо RDS и чем при этом жертвуете?
• Чем реплики для чтения отличаются от развёртывания с несколькими AZ?

Вычисления и доступность

• Объясните группы автомасштабирования и метрики, по которым вы бы масштабировались.
• Когда Lambda — неверный ответ?
• В чём разница между зоной доступности и регионом?
• Как бы вы спроектировали систему на случай потери целой зоны доступности?

Ситуационные вопросы отличают кандидатов друг от друга, потому что заученного ответа для них не существует. Типичные формулировки:

• Наш месячный счёт удвоился, а трафик — нет. Как вы найдёте причину?
• Спроектируйте пайплайн загрузки файлов, который справляется с файлами, слишком большими для одного запроса.
• Сервис медленный только в одной зоне доступности. Что вы проверите в первую очередь?
• Перенесите локальную базу данных в AWS с минимальным простоем. Расскажите по шагам.
• Как сделать так, чтобы эта архитектура пережила отказ целого региона, и во что это обойдётся?

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

Бэкенд-инженер, проходящий собеседование на платформенную роль в компании среднего размера, получает задание спроектировать пайплайн загрузки. Вместо того чтобы сразу назвать S3, она спрашивает, обращены ли загрузки к пользователям и насколько велики файлы, затем выбирает presigned URL с многочастевой (multipart) загрузкой и объясняет, что отвергла маршрутизацию через серверы приложения, потому что это превратило бы пропускную способность в проблему масштабирования. Выбор сервиса был обычным; запомнилось именно рассуждение.

Прочитать список вопросов — это не тренировка. Типичная неудача на собеседованиях по AWS — знать ответ, но выдавать его в виде бесструктурного монолога, и это проявляется только тогда, когда вы говорите вслух.

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

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